Re: Our size allocation issues

[Michael Meeks <michael ximian com>]

Hi Owen,

	Thank you for your detailed reply;

On Tue, 2002-08-20 at 18:45, Owen Taylor wrote:
> > 	Well; I add the plug at socket realize time [ or when
> > the control is bound if the socket is already realized ].
> 
> I guess I should be happy that things work when you change
> the widget heirarchy in a ::realize handler, but it really
> isn't a terribly good idea.

	I'd like to know a better time to do the negotiation then - I can hook
any signal / virtual method on the GtkWidget, it doesn't concern me. I
have one requirement: that I be able to get a valid 'GdkScreen' for that
widget. It's not at all clear to me how I can trap the "got valid
screen" event - short of some bug riddled forest of add/remove signal
handlers on distant parents of the GtkSocket. Any better ideas ? realize
time seemed the obvious solution ?

> If I understand you, the reason why you are not getting
> the right allocation on initial map is because GtkWindow::show
> looks like:
> 
>  a) size_request the toplevel
>  b) allocate the toplevel to the requested size 
>  c) realize the toplevel
>  d) map the toplevel
>
> And the plug is being added at c). We may be able to fix some
> aspects of the problems from adding the socket at this point
> within GtkSocket, but we aren't going to be able to fix all of them.
> 
>  - We have to show _something_ where the plug appears until
>    the correct size gets figured out.

	Right; it'd be really nice to do the size_allocate on the Plug
(in-process at least) during c) before the widget is mapped - thus I'm
slightly suprised that:

gtk_socket_size_allocate ()'s flow is much like:

	if (!GTK_WIDGET_REALIZED (socket))
		return; /* do nothing */

	So it appears that even if the plug is in-place, in-proc, associated
with the socket, visible, but not realized by the time the toplevel is
shown - the plug doesn't get an immediate allocate.

	Why is it that we don't pass on the allocation to an in-proc GtkPlug ?
and so on down the chain ? [ not that that helps me of course, since the
size allocate happens before the realize & thus the insertion of the
plug widget ]. However - with this 'fixed' and forcing an immediate size
allocation on the socket as we add the plug would seem to get around the
problem in-proc.

>  - If the requisition of the socket affects the size of the
>    toplevel, then you'll see a size bounce

	Ok - this is obviated in BonoboSocket / Plug by using CORBA to do the
size requesting; otherwise you inevitably see a size bounce with out of
proc components AFAIR, simply because the Plug can't be added until the
GdkScreen is known which is realize time - and yet the requisition is
~independant of GdkScreen etc.
 
> I *think* it is probably possible to generically fix changing
> the size requisition at C.... I won't go into the details

	I got lost here, but - if you say so; I wonder who will do this work ?
I'd like to help - since the flicker annoys me and smells of a 'bonobo
issue' to people.

> > > 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 imagine it's intended that we pass the Xid of a mapped widget into
> > the socket - and it hides it's GdkWindow until the re-parenting sizing
> > is all sorted - such that the plug is mapped and it's XEMBED_MAPPED,
> > STATE_WITHDRAWN settings are set - although it is really un-mapped /
> > mapped by the Socket at least initially.
> 
> I'm having a little trouble following the above, but it seems that
> you are describing the way XEMBED works, yes. Do you mean by "intended"
> that there is a mismatch between intention and reality? What would
> that be?

	Oh - the problem is simply that if the GtkPlug is realized, but not
mapped: gtk_widget_realize (plug); gtk_plug_get_id (plug), that ID
passed to the socket - then the socket does a gdk_window_show on the
plug_window, and yet the plug's 'map' method was never called - thus the
Xembed stuff doesn't get setup correctly. [it also renders garbage].
That is, unless I misunderstand some process by which the plug is
notified that it has been mapped. Thus it (seems) neccessary to me to
assert that the GtkPlug IS_MAPPED when we get the XID from it; but this
seems horribly counter-intuitive - surely we want to only realize and
not show the GtkPlug before whacking it in the plug. I'm extremely
confused here as I'm sure you can see.

	Currently to get anything to work at all I have to 'gtk_widget_show'
the plug, immediately after setting the gdk_screen on it - at the tail
of step c) - before returning the plug's id to the parent. Doing a plain
realize results in an ugly mess out of proc [ presumably because there
is no way to notify the Plug's children when to be mapped (out of proc)
during embedding in the socket ].

> > 	*  doing a gtk_widget_show (socket) propagates quickly
> > 	   through socket realize to gtk_container_map on the socket
> > 	   which again maps the widget; got around this with a 
> > 	   gtk_socket_map handler that only maps if !need_map [
> > 	   need_map starts to be a inadequate name, perhaps we want
> > 	   delay_map_until_sized ]
> 
> Hmm, so, what you are doing is, for the in-process case, instead of
> delaying mapping the plug window, delaying mapping the socket
> window? 

	Um; well - I simply copied the delayed mapping of the plug's GdkWindow
- so in fact I was just delaying the mapping of the plug's window.

> Probably just less flicker? Since the parent window of the socket
> will show briefly before the socket window is mapped.

	Yes; quite right - although it's worse than that with the background -
we see the Socket's GdkWindow with no plug inside it which gives a grey
flash for the nautilus desktop background. By flicker I suppose I meant
"sizing mess" which was imprecise of me.

> > I imagine the flicker will still be nasty out of process - at least it's
...
> As I recall, the main point is so that the embedded client gets allocated
> to the right size before it starts getting expose events. 

	Sounds fair enough; I'm more interested in grappling with the
real-percieved in-proc problems than the more surreal unreported out of
proc issues I think.

	Anyhow - I'm rather confused as to how to proceed; where do you want
this to go ?

	Regards,

		Michael.

-- 
 mmeeks gnu org  <><, Pseudo Engineer, itinerant idiot