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
Attachment:
0x6759BA74.asc
Description: application/pgp-keys
Attachment:
signature.asc
Description: OpenPGP digital signature