Re: GtkPlug / GtkSocket ...

[Owen Taylor <otaylor redhat com>]

Michael Meeks <michael ximian com> writes:

> Hi Owen,
> 
> 	Oh dear, by the time I start using this it's nearly frozen and
> I have to start doing evil things (again) :-) Anyway - a wibni and a
> bug.
> 
> 	My wibni for the plug / socket ( and I can work around this,
> by overriding every one of the GtkWidget methods (again) in
> BonoboSocket and conditionaly forwarding them ). Anyway - my wish is
> this.
> 
> 	Currently if we have an in-proc control, then although the
> CORBA layer knows about this well in advance of the GtkSocket getting
> realized, the GtkSocket / GtkPlug have to wait until they are realized
> to do even the most basic size negotiation (eg).
> 
> 	Thus; even if a widget is in-proc, it resizes inelegantly
> after a the realize at some stage. This is because the plug / socket
> rely on the X resources in several places. However - once the socket /
> plug have detected that they are in-proc, they avoid doing obscure X
> traffic and just forward events to each other in every case.
> 
> 	So my request is this: can I have a clean way of constructing
> a GtkPlug and pass it a GtkSocket window ? this would amount in some
> sense to exposing _gtk_plug_add_to_socket in some form, and perhaps
> being a bit more careful to ensure that the socket_window resources
> arn't needed / are setup on realize if neccessary.
> 
> 	Currently I have some evil hacks - libbonoboui/bonobo/
> bonobo-control-frame.c (bonobo_control_frame_set_inproc_widget) which
> do evil things inside the plug / socket to try and achieve this effect
> with who knows how much success. NB. the bonobo 'Control' code is
> undergoing a substantial re-write.

Would it from an API standpoint to support:
 
 gtk_container_add (GTK_CONTAINER (socket), plug);

? I haven't really explored what it would take to implement this,
but my guess is that would be only a few lines of changes.

On the other hand, I don't quite understand why you should be
seeing this sort of "inelegance", if you order things correctly.

Are you using the old gtk_plug_new(), or the new preferred
gtk_plug_new (0); gtk_socket_add_id (gtk_plug_get_id (plug))?

> 	In other news - I get a bunch of warnings since it appears I'm
> re-entering inside gtk_socket_unrealize -> gtk_widget_unrealize_real.
> The sequence is a little like this:
> 
> 	socket's grandparent destroy ->
> 	gtk_widget_unrealize on socket -> <-----------.
> 	gtk_socket_unrealze ->                        | gtksocket.c:345
> 	_gtk_plug_remove_from_socket ->               | gtkplug.c:274
> 	gtk_widget_destroy of socket ->               |
> 	gtk_container_remove of socket from parent -> |
> 	gtk_widget_unrealize on the socket -----------'
> 
> 	I imagine it doesn't infinitely recurse because of the
> trickery in gtk_widget_destroy to stop double destroys ( or sim. ).
> Either way - one 'obvious' fix, might be to mark the widget unrealized
> before doing the _gtk_plug_remove_from_socket; indeed I've added
> something like this to BonoboSocket temporarily.
 
Clearing the UNREALIZED flag at the beginning of gtk_socket_unrealize();
if that tests to fix the problem, please commit the fix.

(I don't actually see any warnings trying this out with testsocket,
but the above sequence looks like a plausible problem.)

Regards,
                                        Owen