Re: Our size allocation issues

[Owen Taylor <otaylor redhat com>]

Hi Michael,

Let me see if I can describe how I expect things to work, and then
perhaps you can correlate your observations with this.

First, if I understand correctly, what we are discussing is the 
*in process* case of GtkPlug/GtkSocket?


For any GTK+ widget, showing the widget after the parent is 
visible will result in the widget first being mapped with a
bogus size (usually 1x1) and then moved to the new location
when the idle size pass hits.

The easiest, and best, way of getting around this is to
simply show your toplevels after all the widgets are in place;
doing anything else is going to result in some flashing.

For GtkSocket, you can tell when a child has been added 
to the socket using the ::plug-added signal.

So, this is the course I'd recommend. I don't see any reason
to show the desktop nautilus window until it is completely
ready.


But, say this isn't possible.... For normal widgets, the 
realization at the wrong side is fairly inconspicuous because 
that size is 1x1.

Here we have a window that isn't 1x1 because the GtkPlug
was allocated to it's requested size when it was mapped,
prior to being added into the GtkSocket.

I don't think trying to force the issue so that adding the plug 
to the socket forces an immediate size_allocate() on the socket 
is a good idea ... this is going to stress GTK+'s sizing system 
and could produce bad results when the size request of the plug
forces the socket to resize.


But what you might want to look at instead is what happens
for *out-of-process* Plug/Socket combos.

If you look at gtk_socket_add_window(), then in the out-of-process
case, it *doesn't* immediately map the plug; instead it 
sets the need_map flag, and when a size_allocate() is received,
actually goes ahead and maps the child. I don't see any reason
why we couldn't do the same thing in the in-process case.

Regards,
                                        Owen