Re: Glade architecture change

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

On Sat, 2017-03-04 at 07:11 +0300, LRN wrote:
> On 04.03.2017 6:20, Michael Torrie wrote:
[...]
> No, actually, forget preview. It was a mistake to bring it up, as
> people get
> the wrong idea.
> My limited understanding of how Glade currently works is that it does
> some OOP
> magic to fool GTK widgets (including toplevels) into drawing
> themselves into
> glade UI design surface, and to have them react to input in unusual
> ways (which
> allows the user to, for example, select widgets and call up context
> menus on
> them, but at the same time press buttons, check checkboxes and scroll
> scrollbars).

I dont think it's as bad as you perceive it to be, however as I
mentioned in my other mail, the tight coupling of widgets and the data
model makes things a bit hard to read and a bit spaghetti.

What is actually happening in the workspace however is correct and
pretty good, we rely on only one behind-the-scenes feature that is not
advertised as supported by the GTK+ API, which is the ability to
reparent toplevel GTK+ widgets (however this is supported in GTK+, but
only specifically for Glade).

Other than this, widgets are created in the normal way using normal
GTK+ supported API, similar to that which GtkBuilder internally
implements (using generic GtkContainer and GtkWidget and GObject
property APIs as much as possible, resorting to case specific hackery
only where generic APIs dont exist). We do however require something
beyond regular GtkBuilder usage which is we need to know at all times
that the widget's property values are syncrhonized with project state,
that is vital to ensure a consistent experience and support undo/redo
properly.

In the workspace, we _used_ to have a plethora of hacks to hijack
various signals (I think some of that remains), but this has been
conveniently replaced with the birth of GdkOffscreenWindow, which
allows us to:

  o Instantiate the hierarchy and redirect it's draws to an offscreen
    window

  o Draw to the workspace surface both below and above widgets rendered
    therein at will, providing a much more robust and potentially 
    powerful UX than we had before when we needed to draw selection
    directly on top of widgets.

  o Handle events on the workspace in one event handler, and marshal
    the user events to a specific widget so that Glade can decide to
    handle the event before a widget does, and can optionally never
    send the event to a widget (first click drives selection and next
    click is given to the widget, is an example of this).

[...]
> > > P.S. This proposal was not well-received on #gtk+, so there's
> > > that.
> >
> > How was it presented and why was it not well received?
> It was presented as a three messages sent by me to the channel while
> at least
> two GTK+ developers were present. I do not know why it was not well-
> received.
> No one replied (except for some guest who was asking unrelated
> questions about
> listview alternating row background colors, and thought that Glade
> had
> something to do with that).

Nobody saying anything is not really a sign of something not being well
received.

However, if you had led with "My organization-or-employer has decided
to commit to funding a 3 to 6 month project to solve these problems in
Glade", you might have sparked greater interest :)

Cheers,
    -Tristan