Re: [gtk-list] Widgets Vs Gadgets (Was : map/unmap optimization)

[julian gosnell nomura co uk]

OK Guys - here's my humble opinion :

Why have Gadgets at all ?

Assumption: They are lighter than Widgets

I would like to see some figures that prove this true. A Window is a Server-side
 abstraction, and will be implemented as efficiently as the X Server implementer
 can do it on a given hardware platform - why do writers of widget sets think
 they can do it faster ?

Introducing gadgets into a toolkit complicates the event model, making it less
 consistent - how can you simulate mouse-enter/leave events on a gadget.

It also complicates redraw code, slows down unmapping code (since bottommost
 gadgets must be undrawn) etc...

As soon as you make the background color of a gadget different from it's parent
 it becomes less efficient than a widget, since every refresh necessitates round
 trips between client and server.

A Widget set that relies on windows as it's basic abstraction, and where
 possible tiles pixmaps (another Server-side resource) on these windows, instead
 of making round trips to requesting redraws will refresh instantly, be simpler
 to write, use etc.

As for gadgets as containers. I can see why someone might want to do this, but
 for the reasons above I still think it is the wrong idea. What I would really
 consider worthwhile would be to abstract the layout algorithm out of a
 container widget completely and package it in another object (Strategy
 Pattern). These Strategies might be nestable and certainly very lightweight.
 Then I can have a single generic layoutWidget which can change it's behaviour
 dynamically, without having to worry about the overhead of drawing anything -
 it simply reconfigures its children.


I suppose all this becomes insignificant faced with the demand to port GTK to
 Windoze which no doubt (I don't know) has no built in optimisation for a window
 abstraction, and is so slow that the toolkit writer can do it faster. These are
 things that need to be weighed up (if they have not already been so). But with
 GTK maturing quickly, and no working Windoze port on the horizon (as far as I
 know) I ask myself why GTK insists on making life harder than it already is by
 using Gadgets.


So - Does anyone out there have any hard figures comparing widgets and gadgets -
 I would be interested to know.

If Gadgets do prove to be lighter in certain situations (I think in Motif the
 idea was to use them in menus), then my solution would be for those widgets
 involved to dynamically chose whether or not to use a window (perhaps the
 programmer could supply a hint before initial realisation), but revert to using
 windows as soon as e.g. enter/leave signal handlers where attached, or e.g.
 their background colour became different from their parents.


Anyone interested ?




Jules