Re: GtkSocket bug ? and patch
On Thu, 2005-03-24 at 18:43 +0800, KC wrote: Hi, Let me describe the problem first. I wrote a simple test program, gdk_socket_add_id.c, and try to steal a legacy X app., xeyes. I'm using Fedora Core 2 (with gtk+-2.4.14). The procedure is as following: xeyes CR xwininfo CR . then click on xeyes, I get WID, eg 0x2c7. gdk_socket_add_id 0x2c7 CR The result is two windows instead of one (xeyes embedded in embedder), but xeyes will resize if I resize the embedder. Looks like xeyes does been controlled by embedder ... but reparent is not working. plug/socket is not designed for stealing, which is impossible to get entirely right. It's designed for a pair of a cooperating embedder (GtkSocket, say) and client (GtkPlug) speaking the XEMBED protocol. Regards, Owen signature.asc Description: This is a digitally signed message part ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSocket bug ? and patch
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. That's why this usage isn't supported. 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. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSocket bug ? and patch
Hi, On Thu, 24 Mar 2005 15:51:21 +0100, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Quoting KC [EMAIL PROTECTED]: Hi, On Thu, 24 Mar 2005 07:49:23 -0500, Owen Taylor [EMAIL PROTECTED] wrote: On Thu, 2005-03-24 at 18:43 +0800, KC wrote: Hi, Let me describe the problem first. I wrote a simple test program, gdk_socket_add_id.c, and try to steal a legacy X app., xeyes. I'm using Fedora Core 2 (with gtk+-2.4.14). The procedure is as following: xeyes CR xwininfo CR . then click on xeyes, I get WID, eg 0x2c7. gdk_socket_add_id 0x2c7 CR The result is two windows instead of one (xeyes embedded in embedder), but xeyes will resize if I resize the embedder. Looks like xeyes does been controlled by embedder ... but reparent is not working. plug/socket is not designed for stealing, which is impossible to get entirely right. It's designed for a pair of a cooperating embedder (GtkSocket, say) and client (GtkPlug) speaking the XEMBED protocol. Regards, Owen I agree. As far as I know, GtkSocket/GtkPlug are been used a lot in Bonoboo and probably designed for Bonoboo (this I'm not sure). However, the problem I mentioned did not related to both GtkSocket/GtkPlug, 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. 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 :-) hi, you can look on the code from my program alltray (http://alltray.sourceforge.net/). version 0.1 uses gtksocket stuff, all others direct xlib calls. (focus works better with handmade reparent, drag n drop does not). Alltray waits till the window changed the state to withdrawn before it reparents. (http://tronche.com/gui/x/icccm/sec-4.html#s-4.2.1) regards jochen There are a lot of useful trick in alltray ... Thanks. Regards KC ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSocket bug ? and patch
Hi Havoc, On Thu, 24 Mar 2005 10:46:41 -0500, Havoc Pennington [EMAIL PROTECTED] 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-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSocket bug ? and patch
On Fri, 2005-03-25 at 13:50 +0800, KC wrote: 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 ... I prefer looking at the docs ;-) * gtk_socket_add_id: * @socket_: a #GtkSocket * @window_id: the window ID of a client participating in the XEMBED protocol. * * Adds an XEMBED client, such as a #GtkPlug, to the #GtkSocket. 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. The app is welcome to make the decision, but it's just like an app deciding to use a pie chart. GTK+ doesn't have a pie chart widget. GTK+ doesn't have an embed random window widget either. So you have to go somewhere other than GTK+ to find this code. GTK+ isn't going to stop you from doing so. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
Re: GtkSocket bug ? and patch
Hi, On Fri, 25 Mar 2005 01:34:44 -0500, Havoc Pennington [EMAIL PROTECTED] wrote: On Fri, 2005-03-25 at 13:50 +0800, KC wrote: 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 ... I prefer looking at the docs ;-) * gtk_socket_add_id: * @socket_: a #GtkSocket * @window_id: the window ID of a client participating in the XEMBED protocol. * * Adds an XEMBED client, such as a #GtkPlug, to the #GtkSocket. MMMmmm ... I think I forgot to look at that ... I trace the source code and found gtk_socket_add_id() is in fact identical to gtk_socket_steal() ... so I confuse myself ... what I'm talking SHOULD BE gtk_socket_steal() instead of gtk_socket_add_id() ... that's my fault. So my question should be replaced by: gtk_socket_steal() can't reparent xeyes properly ... Call XReparentWindown() couple times with XSync() might fix the problem ... as the patch I posted said. But gtk_socket_steal() was deprecated so bad. Regards KC 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. The app is welcome to make the decision, but it's just like an app deciding to use a pie chart. GTK+ doesn't have a pie chart widget. GTK+ doesn't have an embed random window widget either. So you have to go somewhere other than GTK+ to find this code. GTK+ isn't going to stop you from doing so. Havoc ___ gtk-devel-list mailing list gtk-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list
