Re: GtkSocket bug ? and patch

[KC <kcc1967 gmail com>]

Hi Havoc,


On Thu, 24 Mar 2005 10:46:41 -0500, Havoc Pennington <hp redhat com> wrote:
> On Thu, 2005-03-24 at 22:22 +0800, KC wrote:
> > it's X reparent problem.  I just want to know if the patch I posted worthy to
> > apply or does XReparentWindow() do have such problem for some window
> > managers.
> 
> The problem is that without XEMBED you're doing something totally
> undefined/heuristic/race-condition-ridden, so yes it has a problem, but
> no there's no reasonable way to fix it.

Agree.
 
> That's why this usage isn't supported.

This I don't quite agree.  Look at the function prototype, it's

   void gtk_socket_add_id (GtkSocket *socket_, GdkNativeWidnow XID);

It implies all GdkNativeWindow should work ... IMHO, that's the reason Gtk
must support and fix the problem.  Of course you should warn user about
the potential problem if client (or plug) does not speak XEMBED.  But that's
the decision application should make, not a toolkit.

> 
> > And IMHO, although GtkSocket/GtkPlug may not design for kidnapping legacy
> > X applications ... it does work fine for such purpose.   Specially, when using
> > such trick for text based interactive utilities such as gnuplot, GNU
> > Octave, Maxima ... etc
> > most of them don't know what's XEmbed protocal ... but they do worth
> > to kidnap :-)
> 
> They may "work" but not reliably or via any specified mechanism, so this
> isn't something gtk wants to start trying to fix bugs in.

It works perfectly for gnuplot (and xeyes ^.^).  Since communication between
embedder (socket) and gnuplot is goes through pipe or pseudo tty, not XEMBED.
So, again it's the decision application should make, not toolkit.

I agree new programs should use XEMBED, in fact, I do have fun playing with
GtkSocket and GtkPlug.  But if gtk_socket_add_id() can't even successfully
embed trivial app. like xeyes, well, I will say it's a bug and someone should
deal with it.


Regards
KC