Re: [gtk-list] More on realize

[Raph Levien <raph acm org>]

On Sun, 9 Nov 1997, Lauri Alanko wrote:

> 
> Hello there.
> 
> Still concerning the widget showing signals... As I see, the signals go
> like this:
> 
> "show"
> 
> Does what?
> If unmapped, calls
> 
> "map"
> 
> Maps the widget, ie. makes sure it can actually be seen. Usually this
> means showing its X(Gdk)Window. If none has been created yet, calls
> 
> "realize"
> 
> Creates the actual windows and other graphical elements that correspond to
> the widgets current logical state, normally this means creating the
> widget's X window(s) and miscellaneous other init stuff..

   As far as I can see, you've got this exactly right. Not sure why 
you're confused.

> Now firstly I'm not quite sure what the "show" signal is supposed to do...
> okay, it sets GTK_WIDGET_VISIBLE, while "map" sets GTK_WIDGET_MAPPED..
> what exactly is the conceptual difference between these?

   The way I see it, VISIBLE has to do with the internal state of the 
widget, while MAPPED has to do with its relation to the X window state.
For example, if you create a widget tree without ever doing a show on the 
toplevel widget, you can toggle with VISIBLE flags at will without any 
effect on the X window system. Then, when you map the toplevel widget, 
(only) the widgets with VISIBLE will get mapped.

   I think it's true in general that MAPPED is never set if the widget is 
not VISIBLE, but it may be that with the queued resize it is possible for 
a widget to be MAPPED and not visible for the brief period until the idle 
function actually performs the resize. I haven't checked into it.

> Secondly I'm a little befuddled by the order in which the signals are
> passed down in the container hierarchy. It seems like _something_ is out
> of order somewhere, if the first "realize" signal reaches a widget before
> the first allocation, so then the widget has the initial allocation of
> -1,-1... And this usually requires an explicit check in the realize
> handler.

   Ok, this is something I'm unclear on too. As far as I can tell, before
970925 (when the queued resize was added), widgets could count on being
size allocated before being mapped and realized. However, the queued
resize broke this invariant, and some containers do realize and map before
size allocation (gtk_box_pack_start () in gtkbox.c shows this ordering
explicitly). 

   My feeling is that this is wrong. The queued resize logic should be
fixed to always map a widget if it is visible and the parent is mapped
(and similarly for realizing), after doing size negotiation. That way, the
containers no longer have to be responsible for mapping and realizing the
child widget, and the invariant would be maintained.

   In practice, this doesn't seem to be a matter of urgency. The initial 
allocation at (-1,-1) doesn't seem to hurt much. When the widget gets its 
real size allocation, the size_allocate method generally moves the window 
to its real position and size. Thus, you don't tend to see bad artifacts 
in the display process. I do think that it would be cleaner to have this 
fixed, as well as making display slightly faster becuase windows get 
allocated into their correct position, rather than being allocated as 
one-pixel windows then getting moved into position.

> So am I missing something or is this a bug? It really seems to me to be
> pointless that a widget that hasn't been allocated any space is asked to
> realize.

   I vote for bug. What's _really_ needed, though, I think, is a precise
definition of what the various signals do, what order they might be called
in, and what invariants in the widget flags and data structures are
maintained. I haven't volunteered to do this, though, because I haven't
heard any input from the creators of gtk+, and I'm also not sure if there
will be any more changes to the size negotiation code. For one, I'm
working on extensions to size negotiation in Gzilla (to get around the
32kpixel limitation, allow word wrapped widgets, and baseline alignment
for HTML tables). I'm developing this in a different framework (Gzw,
Gzilla Widgets) but it's possible some of that work will get folded back
into gtk+. 

Raph