Glade architecture change



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]