[Glade-devel] Glade architecture change

[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.

On Fri, Mar 3, 2017 at 11:16 AM, LRN <lrn1986 at gmail.com> wrote:
> 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
>
> _______________________________________________
> Glade-devel maillist  -  Glade-devel at lists.dot.net
> http://lists.dot.net/mailman/listinfo/glade-devel
>