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