Reparenting a GtkSocket to another GtkContainer loses its GtkPlug



I have two GTK programs (i.e. two separate processes), S and P, and I
want a GtkSocket running in S to hold a GtkPlug running in P.  I've
followed the docs, and that's straightforward to get working.

Now, in S, the GtkSocket actually lives in one GtkVBox, and after the
GtkSocket and GtkPlug have found each other, I would like to move it
to another GtkVBox, e.g. in response to a button click.  I write code
like:
  gtk_container_remove (GTK_CONTAINER (vbox1), socket);
  gtk_container_add (GTK_CONTAINER (vbox2), socket);
since that's how I move a GtkLabel from one vbox to another.

However, the removal causes the GtkSocket to unrealize itself (IIUC),
which makes the GtkPlug reparent to the root window, which triggers a
delete-event on the GtkPlug.  Thus, when I re-add the GtkSocket to the
second GtkVBox, it is empty.

So, I can work around this by connecting to the delete-event signal on
the GtkPlug, in P, and in the signal handler, return TRUE to stop the
GtkPlug being destroyed.  In program S, it turns out that, rather than
re-using the existing GtkSocket, I have to create a new GtkSocket, add
it to vbox2, realize the new GtkSocket (e.g. show() it), and finally
add_id the GtkPlug's ID to the new GtkSocket.  After all that, it
"works", in that I can move the hosted GtkPlug from one VBox to the
other.

The workaround is imperfect, though, since in P, the GtkPlug now
basically ignores any delete-events, and hence doesn't actually
destroy itself when S quits (destroying the hosting GtkSocket).

I suppose that I could arrange some sort of IPC between S and P to
distinguish between (1) a GtkSocket moving from one GtkContainer to
another (and thus being merely temporarily unrealized), and (2) being
permanently unrealized (e.g. the GtkSocket being destroyed).  But
before I try that, I was wondering if anyone here had an easier,
just-GTK solution.  For example, can I just somehow re-parent the
GtkSocket to vbox2 from vbox1?

And if I was to use IPC, not knowing any better I was thinking of just
slapping a "temporarily moving, back in 5 minutes" X property on the
GtkPlug's X11 Window in S, XSync'ing in S, doing the
gtk_container_remove + gtk_container_add dance in S, and finally (in
S's view) removing that X property and XSync'ing, whilst in P,
checking for that X property in the delete-event handler.  Is that
reasonable?  It's not bulletproof (e.g. if S crashes between the
remove and the add then we're left with a zombie GtkPlug), but I can't
think of anything better ATM...



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]