Re: Our size allocation issues

[Michael Meeks <michael ximian com>]

Hi Owen,

On Wed, 2002-08-21 at 13:34, Owen Taylor wrote:
> It's not that hard to do ... tracking getting *a* valid screen
> is simply tracking when the widget has been added to a toplevel ...
> that is, the ::hierarchy-changed signal. Tracking the current
> screen requires connecting to notify::screen on the current
> toplevel; gtkfontsel and gtktoolbar do this.

	Ok - sounds excellent.

> But can you hook up a plug/socket before the socket is realized?

	Nope; GtkSocket forces a realize as you do the add_id, which is fair
enough for simplicity's sake.

> It might be able to be made work in the in-process case,
> but the in-process case is basically just a short-circuiting
> of the out-of-process case, so I don't think it's necessarily
> a good idea to support that:

	Agreed.

> I wasn't suggesting that you hook up the socket
> prior to realize, I was suggesting that you realize prior
> to showing the toplevel, and wait for your plug/sockets to
> get connected before you show the toplevel.

	Well; since I'm currently doing my size_allocate outside of a
size_allocate hack - would it be less evil to listen for the
'hierarchy-changed' signal, and inside that realize the socket [ and
everything above it ] and then associate the plug with the socket ?

	ie. switch from the 'realize' slot to the 'hierarchy changed' slot for
adding the plug etc. Presumably that would ensure that the negotiations
are done earlier - before the size_request/allocate/realize/map process
invoked by 'show', thus avoiding the need for any further custom bits.

> (Hard to do generically for Bonobo, but shouldn't be hard
> for a specific case like the Nautilus desktop window.)

	So - hard to do generically, does that mean that mapping improperly
allocated windows is one of thing that XEmbed doesn't help with ?
Surely, mapping the remote window at the tail of the plug's
"size_allocate" would be one approach to fixing this ?

> > 	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.
> 
> Only if the socket isn't realized and the plug is; and that's
> definitely a borderline case....

	The plug is always realized by the time the socket gets a sniff of it.
And it's not borderline, since the steps in the 'show' operation are
size_request/size_allocate/realize - so most of the time if everything
is setup before 'show' we have an unrealized GtkSocket associated with
an (incidentally) realized GtkPlug. Is that borderline ?

> The *only* time non-core GTK+ code is allowed to call size_allocate()
> is in a size_allocate() handler. While it may be possible to 
> do safely in some other circumstances, with the current core
> GTK+ code, I really couldn't guarantee that it would continue
> working in the future.

	Interesting; I imagine this has to be fairly robust for a Plug as a
sub-class of GtkWidget, since it might get a ConfigureEvent at any time,
so perhaps it's not such a bad workaround ?
 
> The requisition is most certainly not independent of the GdkScreen.
> The theme and fonts depend on the GdkScreen.

	Bother; not obvious what to do about that; sigh - I need to do some
detailed tests of out of proc controls.

> > 	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 ].
> 
> No, it's all supposed to work if you don't show an out-of-process
> plug and add it to it's parent, then show later. I took considerable
> care in the XEMBED protocol getting that right.

	Extraordinary; I can't see by what mechanism that should happen - and I
know that if I change:

bonobo-control.c (impl_Bonobo_Control_getWindowId):
...
-	gtk_widget_show (control->priv->plug);
+	gtk_widget_realize (control->priv->plug);

	x11_id = gtk_plug_get_id (GTK_PLUG (control->priv->plug));
		
	return bonobo_control_window_id_from_x11 (x11_id);
}

	Then suddenly - everything stops working; but possibly only in-proc;
hmm.

	Are you saying that the mapping should work out of process such that if
you just realize the GtkPlug in testsocket_common.c (create_child_plug)
instead of doing a gtk_widget_show_all [ ie. by appending a
gtk_widget_unmap ] we should see stuff ?

	If I add a gtk_widget_unmap () testsocket_common.c at that point I see
nothing (1 out of 4) when I run test_socket - is that the intention ?
 
> I don't understand your changes to gtk_socket_show() at all
> then.

	Hmm, it's entirely likely that I don't either, so I'm looking at other
ways around the problem.

>  A) Nautilus specific hacks so that Nautilus doesn't stress
>     out the GTK+ system so much. This is definitely going
>     to give the best performance and appearance for Nautilus.
>     Anything else pretty much inevitably means gray flashes,
>     etc.

	I'd prefer to fix the problem more generically in a way that doesn't
involve lots of hacks / container specific stuff / extra steps in
setting up a Control [ new API etc. ].

>  B) Making GtkWindow work better when the requisition of the
>     window changes at realization time.

	Interesting indeed - what do you have in mind ?

>  C) Specific changes to GtkSocket/GtkPlug to make it do
>     "delay map until the allocation is received" for
>     in-process rather than out-of-process.
> 
> I'd be happy to discuss any or all of these (preferably separately).
> I think C) is, to some extent, the least interesting.

	Agreed - bin my previous patch, it sucks rocks.

>  All you
> can get with it is things appearing less bad rather than
> appearing good.

	:-)

	Thanks again for all your input,

	Regards,

		Michael.

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