Re: Glade architecture change

[Tristan Van Berkom <tristan vanberkom codethink co uk>]

Hi,

Before getting into detail I should lead with the fact that on one
hand, a program like Glade is complex, more so than most would expect,
on the other hand; Glade has never really been a funded project, we've
had a couple of brief sponsorships mostly thanks to Murray and
Openismus but the bulk of the work has been done years ago in my
downtime between contracts.

There is still huge potential for Glade to become better and there are
also some really nasty bits which desperately need refactoring & re-
architecture, this is all however very expensive.

On to your proposal...

On Fri, 2017-03-03 at 17:16 +0300, LRN 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.

The instability of Glade is mostly due to two things:

a.) Glade's data model is tied to GTK+, which is wrong. This is the
    single point which is most desperately in need of a refactor.

    To clarify: Glade has forever relied on GTK+ for the widget
    hierarchy, while wrapping GladeWidgets around a GtkWidget instance,
    this means that whenever we do gtk_container_add(parent, child),
    we have always relied on "gtk_widget_get_parent(child) == parent"
    to be a TRUE statement. GTK+ is no longer abiding by this rule.

    Another source of bugs tied to this design problem relates to
    cut/copy and paste, especially when these copy/paste activities
    happen on a cross project level (You might have 2 different glade
    files open and when copying a hierarchy over, we need to make sure
    that it does not have object property references referring back
    to the source project you copied from).

    This design flaw also makes things tightly coupled in a nasty way,
    untangling this will open the door to better stability and to
    doing workspace features more cleanly and independently of the
    data model.

b.) As you mention, there is a huge vector of non-mitigable crashes
    which stem from GTK+ bugs which would never occur under normal
    usage of GTK+.

    This include crashes where widgets end up crashing when their
    properties are explicitly set to their default values, also some
    side effects generally occur due to GTK+ failing to report
    properly introspectable default values (often this is the case
    for derived widgets which do property settings at _init() time
    without ever overriding the corresponding GParamSpec for their
    class).

So, yes; after years of suffering (b) it has always been desirable to
me to run the workspace out of process, pretty much as you suggest, but
without gutting the workspace and it's features or potential features;
the way a user can interact with widgets in the workspace, aside from
the editor widgets, is Glades greatest opportunity to shine and be
useful to the user (we should by now, at _least_ have workspace support
for editing text labels directly in the workspace, without ever making
the arduous journey all the way to the property editor).

I'm pretty certain that reconstructing the workspace UI on every change
is a bad idea, though, because then we add some huge complexity in
maintaining superfluous UI state between rebuilds (if it were even
found to be performant enough). I.e. one example is the size of a
widget that is toplevel in the workspace is usually not encoded into
the data model, bits and pieces like this would have to be recorded and
restored across reconstructions.

Now, before we even start considering running an out of process
workspace with which we can at least (1) try to reconstruct in the case
that the process crashes and (2) forcefully revert the project to the
last known working state in cases where (1) fails, we _have_ to address
the tight coupling mentioned in (a) above.

Doing (a) is not a big deal in the scope of things. I would hazard a
guess that as the primary author of Glade, it might take me 2 or 3
weeks of full time work to refactor and hopefully have something more
stable and without regressions as a result, perhaps 4 weeks for a
competent and driven developer that is already intimately familiar with
GObject and GTK+. As I said, in the scope of things this is what I
would call "not very much work".

On to the next challenge, so we dont want to break the one window UX,
back in 2004 when I started working on Glade it had a gimp-like
interface with a palette, "widget tree" and workspace all in separate
windows, Vincent Geddes spent a lot of work making Glade a one window
UX which was a huge improvement (even though we still keep to this day
an option to undock things in the 'View' menu).

So, running the workspace out of process points back to GtkPlug and
GtkSocket, which unfortunately have never gained the required support
for Windows and Quarts native OSX platforms. Seeing as there is
certainly some prior art, I think firefox is/was able to recover from a
crashed browser tab (not sure that's the case anymore as today a
browser tab seems to hang the whole app) - there should be a way to
implement GtkPlug/GtkSocket in a cross platform way, and an uphill
battle to get that functionality upstream into GTK+ proper (seems there
has never been much interest in improving those, and considerable
desire to even deprecate them). Alternatively, Glade could maintain a
dual code path for platforms which do not support GtkPlug/GtkSocket by
allowing the workspace to pop up as a separate window on those, or
perhaps a half way compromise would be to maintain our own homegrown
GtkPlug/GtkSocket in Glade if we can solve the problem on win32 and
Quartz, in the absence of willingness to maintain this in GTK+.


So yes, in closing, out of process workspace is very interesting for
Glade, and the required refactoring in Glade to get there is also very
desirable to make Glade more manageable and pay some technical debt, it
can be done and the work required to reach the end goal is not much...

... all things told, it's probably _only_ going to take around 3 or 4
months of full time development, assuming you have an expert doing all
of this.

It's overall the right direction, and a great cost/benefit ratio, it's
also a pretty small project: only a hand full of months of full time
dedication.

Cheers,
    -Tristan


Another thought here is that with an advertised shorter life span for
GTK+ major point versions, the project outlined above may also open the
door to supporting multiple GTK+ versions in the same application, we
would only have to maintain one Glade for GTK+ 2, 3 and 4... so long as
we can decouple the data model from GTK+ widgets and run the workspace
process against the target GTK+ API/ABI version.

> 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.
>
> _______________________________________________
> gtk-list mailing list
> gtk-list gnome org
> https://mail.gnome.org/mailman/listinfo/gtk-list