[Glade-devel] Glade architecture change

[LRN]

Yet another report of Glade crashing prompted me to think about a way to fix
this, as i've experienced something similar. I've also looked at Glade source
code, and didn't really understand it all that well (which prevented me from
fixing a bug that i wanted to fix).

Here's my pitch: take the "preview" functionality (where Glade runs a separate
process that constructs the UI based on current project) and take it up to 11.
Base the whole Glade around that idea, and instead of running a live preview
manually, on request, just have a slave process running all the time, and have
it do everything with the widgets, the same way a real GTK application would.
Obviously, it will have to render that into some kind of buffer owned by Glade,
and there will have to be a protocol to communicate with it, to make it capable
of receiving input, for example. This would probably require to use GI more
than it is used already, and baking some of the formerly-Glade functionality
either into GTK itself, or into the slave process.

I think that crashes will be easier to deal with that way, as Glade won't have
to juggle both widgets and their meta-structure at the same time. Also,
extending Glade to support new GTK widgets will be easier.

Also, this might or might not bring some benefits to GtkInspector, depending on
how much of that code goes into GTK, making it available to Inspector.

Does this make sense? Was this already considered during previous Glade
rewrites? If yes, why was it discarded? Thoughts?

P.S. This proposal was not well-received on #gtk+, so there's that.

[Marco Diego Aurélio Mesquita]

Hi LRN!

Although I'm no longer an active contributor, I was the developer of
the original glade-preview app. I'd really love see it get advanced
features but I'm not willing to do it myself. If you found a
reproducible crash on glade, I'd recommend you to file a bug on
gnome's bugzilla; also, try to talk to Juan Pablo Ugarte and Tristan
about new ideas involving glade.

A long time ago, I worked on the integration between glade and Anjuta.
It worked pretty fine for a time but, currently, it crashes. The
workflow was very good while it worked. Anjuta development has been
stagnant recently and gnome-builder seems to be the gnome IDE where
development is happening. I talked to Christian Hergert (gnome-builder
main developer) about glade integration on gnome-builder and he seemed
supportive of it. So, if you're interested in doing something really
great for glade, I'd recommend you to start integrating it on
gnome-builder.

I don't think changing glade architecture around glade-previewer would
make it easier to debug.

Post by LRN
Yet another report of Glade crashing prompted me to think about a way to fix
this, as i've experienced something similar. I've also looked at Glade source
code, and didn't really understand it all that well (which prevented me from
fixing a bug that i wanted to fix).
Here's my pitch: take the "preview" functionality (where Glade runs a separate
process that constructs the UI based on current project) and take it up to 11.
Base the whole Glade around that idea, and instead of running a live preview
manually, on request, just have a slave process running all the time, and have
it do everything with the widgets, the same way a real GTK application would.
Obviously, it will have to render that into some kind of buffer owned by Glade,
and there will have to be a protocol to communicate with it, to make it capable
of receiving input, for example. This would probably require to use GI more
than it is used already, and baking some of the formerly-Glade functionality
either into GTK itself, or into the slave process.
I think that crashes will be easier to deal with that way, as Glade won't have
to juggle both widgets and their meta-structure at the same time. Also,
extending Glade to support new GTK widgets will be easier.
Also, this might or might not bring some benefits to GtkInspector, depending on
how much of that code goes into GTK, making it available to Inspector.
Does this make sense? Was this already considered during previous Glade
rewrites? If yes, why was it discarded? Thoughts?
P.S. This proposal was not well-received on #gtk+, so there's that.
--
O< ascii ribbon - stop html email! - www.asciiribbon.org
_______________________________________________
http://lists.dot.net/mailman/listinfo/glade-devel

_______________________________________________
Glade-devel maillist - Glade-***@lists.dot.net
http://lists.dot.net/mailman/