Hi Havoc, On Thu, 24 Mar 2005 10:46:41 -0500, Havoc Pennington <hp@xxxxxxxxxx> 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 _______________________________________________ gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
