Web lists-archives.com

Re: Glade architecture change

On 04.03.2017 6:20, Michael Torrie wrote:
> On 03/03/2017 07:16 AM, LRN wrote:
>> Does this make sense? Was this already considered during previous Glade
>> rewrites? If yes, why was it discarded? Thoughts?
> I'm not sure GTK+'s architecture would even allow glade to operate in a
> manner like you suggest.
> Besides that, Glade's instability doesn't seem to have anything to do
> with how the preview process displays the actual widgets.

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). My hypothesis is that this wrapping is responsible for various
complications in Glade development (missing features) and performance (crashes).
The idea is to drop this and just have Glade use GTK normally, the way any
application would. I.e. create windows, boxes, pack stuff into them. Libgladeui
already knows how to do that from glade XML files. What's missing is for the
Glade host application to be able to control that process from outside. Kind of
like what GtkInspector does, but with an ability to create/destroy/relayout
widgets, and do so from a separate process, not from within the application.

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

O< ascii ribbon - stop html email! - www.asciiribbon.org

Attachment: 0x6759BA74.asc
Description: application/pgp-keys

Attachment: signature.asc
Description: OpenPGP digital signature

gtk-list mailing list