RE: Which widget can I use for play a video file in GTK
Thanks keith, I have couple of questions here, I have codec, it just decode the mp4 file as YUV file or It can directly display it on frame buffer (whare x-server is not come into picture). Here I need to write a GTK application so that it take the YUV file and start playing or it can grab directly from framebuffer while playing. If it is the first, bacon-video-widget is the best choice. else What is the way to grab the display from framebuffer and display it by GTK widget. Suggest me here. Let me know your thoughts. Thanks Vishwa -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Keith Sharp Sent: Tuesday, March 22, 2005 5:32 PM To: gtk-app-devel-list@gnome.org Subject: Re: Which widget can I use for play a video file in GTK On Tue, 2005-03-22 at 17:01 +0530, vishwahg wrote: Hi, I have a video(mp4) file and I want it to play using GTK based application. My question is which widget(Gtkpixmap/GTkimage) is fit for play a video file in GTK?. Let me your thoughts. You want to look at the bacon-video-widget that is part of totem: http://cvs.gnome.org/viewcvs/totem/ There are plans to create a standalone video widget: http://live.gnome.org/RoadMap#developer Keith. PS. You should start a new thread by composing a completely new message rather replying to a different thread and changing the subject - this breaks threading on most people mail client! ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list SASKEN RATED THE BEST EMPLOYER IN THE COUNTRY by the BUSINESS TODAY Mercer Survey 2004 SASKEN BUSINESS DISCLAIMER This message may contain confidential, proprietary or legally Privileged information. In case you are not the original intended Recipient of the message, you must not, directly or indirectly, use, Disclose, distribute, print, or copy any part of this message and you are requested to delete it and inform the sender. Any views expressed in this message are those of the individual sender unless otherwise stated. Nothing contained in this message shall be construed as an offer or acceptance of any offer by Sasken Communication Technologies Limited (Sasken) unless sent with that express intent and with due authority of Sasken. Sasken has taken enough precautions to prevent the spread of viruses. However the company accepts no liability for any damage caused by any virus transmitted by this email ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gtk-app-devel-list Digest, Vol 11, Issue 35
--
Message: 4
Date: Thu, 24 Mar 2005 07:27:31 +0100 (CET)
From: Hubert Sokolowski [EMAIL PROTECTED]
Subject: Re: Change color of widgets
To: gtk-app-devel-list@gnome.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain;charset=iso-8859-2
HI,
On Wed, 23 Mar 2005 18:16:36 +0100, Hubert Sokoowski
[EMAIL PROTECTED] wrote:
http://developer.gnome.org/doc/API/2.0/gtk/GtkWidget.html#gtk-widget-modify-bg
another way would be to use themes and two different gtkrc files.
Can you point me any sample source code? Probably any (preferably
small) project which uses this technique?
try this code to change the background of all widgets
gtk_rc_parse_string(style \background\\n
{\n
bg[NORMAL] = \#646464\\n
}
widget_class \*\ style \background\);
hs
--
Hi,
Thanks for all of your input and the examples.
I look all over the gtk manual but I can't find gtk_rc_parse_string. I may
have overlook. Could you point me to the documentation and which *.h file
contains the declaration of gtk_rc_parse_string?
How can I read the widgets' default color settings? I need to save the
original values so that I can change the widgets' colors back to its
original.
Thanks.
--
Simplicity is the ultimate sophistication. - Leonardo DaVinci.
Complexity is simplicity that has failed. - Adrian Hoe, June 23 2004.
http://adrianhoe.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: Change color of widgets (Santhosh)
--
Message: 4
Date: Thu, 24 Mar 2005 07:27:31 +0100 (CET)
From: Hubert Sokolowski [EMAIL PROTECTED]
Subject: Re: Change color of widgets
To: gtk-app-devel-list@gnome.org
Message-ID: [EMAIL PROTECTED]
Content-Type: text/plain;charset=iso-8859-2
HI,
On Wed, 23 Mar 2005 18:16:36 +0100, Hubert Sokoowski
[EMAIL PROTECTED] wrote:
http://developer.gnome.org/doc/API/2.0/gtk/GtkWidget.html#gtk-widget-modify-bg
another way would be to use themes and two different gtkrc files.
Can you point me any sample source code? Probably any (preferably
small) project which uses this technique?
try this code to change the background of all widgets
gtk_rc_parse_string(style \background\\n
{\n
bg[NORMAL] = \#646464\\n
}
widget_class \*\ style \background\);
hs
--
I called gtk_rc_parse_string with #00 for background color but nothing
has happended. What am I missing here?
Thanks.
--
Simplicity is the ultimate sophistication. - Leonardo DaVinci.
Complexity is simplicity that has failed. - Adrian Hoe, June 23 2004.
http://adrianhoe.com
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Mouse position
How do I control the location of the mouse pointer? I need to prevent the mouse from exiting a square region within a window, by resetting the location everytime it tries to move outside of the square. (This isn't related to wanting to grab the window border). Save your bad GUI design comments. This isn't bad design: my application specifically needs this functionality. Which function do I call to move the mouse pointer to position x,y? Best wishes, Rob Send instant messages to your online friends http://uk.messenger.yahoo.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
GtkSocket bug ? and patch
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.
I then trace gtk's source code (and also look at the source code of
a Tcl/Tk package called TkSteal). I found the problem could be the
gdk_window_reparent() defined in gtk+-2.4.14/gdk/x11/gdkwindows-x11.c.
In TkSteal (TkSteal4.0c.tar.gz), the author said:
file: TkSteal/libTkSteal/tkXAccess.c
...
...
/*
I do not know why, but several window managers require multiple
reparent events. Right now a value of 25 should be enough.
*/
#define REPARENT_LOOPS 25
...
...
for (counter1 = 0; counter1 REPARENT_LOOPS; counter1++) {
XReparentWindow(Tk_Display(tkrootwin), window, parent, 0, 0);
XSync(Tk_Display(tkrootwin), False);
}
...
...
Accounding to this info, I modify gtk+-2.4.14/gdk/x11/gdkwindows-x11.c
but only use REPARENT_LOOPS = 5 (check patch-gtk+-2.4.14 at the end of this
email) and it do solve the problem.
Any comment ?
Regards
KC
/* file: gdk_socket_add_id.c */
#include stdio.h
#include stdlib.h
#include unistd.h
#include gtk/gtk.h
#include gdk/gdk.h
int main (int argc, char *argv[])
{
int exWID;
GtkWidget *win = NULL;
GtkWidget *vbox = NULL;
GtkWidget *label = NULL;
GtkWidget *socket = NULL;
switch (argc) {
case 2:
exWID = strtol(argv[1], NULL, 0);
break;
default:
fprintf(stderr, usage: %s exWID\n, argv[0]);
exit(1);
}
gtk_init(argc, argv);
win = gtk_window_new(GTK_WINDOW_TOPLEVEL);
g_signal_connect(G_OBJECT(win), delete_event,
G_CALLBACK(gtk_main_quit), NULL);
g_signal_connect(G_OBJECT(win), destroy,
G_CALLBACK(gtk_main_quit), NULL);
gtk_container_set_border_width(GTK_CONTAINER(win), 2);
gtk_window_set_title(GTK_WINDOW(win), HELLO RE-PARENT);
gtk_window_set_default_size(GTK_WINDOW(win), 640, 480);
gtk_widget_set_size_request(GTK_WIDGET(win), 100, 100);
vbox = gtk_vbox_new (FALSE, 0);
gtk_container_add(GTK_CONTAINER (win), vbox);
label = gtk_label_new (Xlib window);
gtk_box_pack_start (GTK_BOX (vbox), label, FALSE, FALSE, 0);
socket = gtk_socket_new();
gtk_box_pack_start (GTK_BOX (vbox), socket, TRUE, TRUE, 0);
gtk_widget_show (socket);
gtk_socket_add_id(GTK_SOCKET(socket), exWID);
gtk_widget_show (socket);
gtk_widget_show_all(win);
gtk_main();
exit(0);
}
- begin of
patch-gtk+-2.4.14
--- gtk+-2.4.14/gdk/x11/gdkwindow-x11.c 2004-10-19 04:55:17.0 +0800
+++ gtk+-2.4.14.kc/gdk/x11/gdkwindow-x11.c 2005-03-24
18:35:28.348561144 +0800
@@ -1534,6 +1534,7 @@
gint x,
gint y)
{
+ int i, max_reparent_count = 5;
GdkDisplay *display;
GdkWindowObject *window_private;
GdkWindowObject *parent_private;
@@ -1561,11 +1562,25 @@
old_parent_private = (GdkWindowObject*)window_private-parent;
parent_private = (GdkWindowObject*) new_parent;
impl = GDK_WINDOW_IMPL_X11 (window_private-impl);
-
- XReparentWindow (GDK_WINDOW_XDISPLAY (window),
- GDK_WINDOW_XID (window),
- GDK_WINDOW_XID (new_parent),
- x, y);
+
+ /* 2005/03/24 Kuang-Chun Cheng [EMAIL PROTECTED]
+ *
+ * According to the comment of source code of package TkSteal (by
Sven Delmas)
+ * some window managers require multiple reparent events. I do
found this problem
+ * when I try to use gtk_socket_add_id() to kidnap a legacy X app.,
xeyes, under
+ * Fedora Core 2.
+ * The xeyes will remain a separate toplevel windows instead of a
child of embedder.
+ *
+ * The following loop do fix the problem:
+ */
+ for (i=0; imax_reparent_count; ++i) {
+ XSync(GDK_WINDOW_XDISPLAY (window), False);
+ XReparentWindow (GDK_WINDOW_XDISPLAY (window),
+GDK_WINDOW_XID (window),
+GDK_WINDOW_XID (new_parent),
+x, y);
+ usleep(100);
+ }
window_private-x = x;
window_private-y = y;
- end of
patch-gtk+-2.4.14
--
/\__/\ OpenATE INC
. /`'\ http://www.openate.com/
=== 0 0 ===TEL: 886-2-27607832 FAX: 886-2-27694542
\ __ /
/\ Kuang-Chun Cheng
/ \http://www.openate.com/~kccheng
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
Run-time debugging printout change for gmain.c
Would it be OK to commit this? This does:
- Drop the compile-time G_MAIN_POLL_DEBUG setting from gmain.c.
- Instead, if G_EMABLE_DEBUG is on, you can turn on the debugging
printout at run-time through an environment variable called
(surprise...) G_MAIN_POLL_DEBUG.
- Use g_printerr() and not g_print(). Debugging printout is more
suitable for stderr, isn't it?
- Change the output format in g_main_context_poll() a bit.
It's mostly the Win32 implementation of g_poll() that has much
debugging spew.
Actually, I would like to overhaul all of the debug printout stuff in
GLib and GTK+ (i.e. GDK_NOTE() and GTK_NOTE()). Especially on Win32
staring at debugging printouts is essential when hacking on new and
weird stuff (think gtkplug/socket, gconf, libbonoboui, etc). Required
features would be:
- Optional run-time redirection of debugging printout to per-process
files or syslog/OutputDebugString.
- If one file shared between several processes, maybe some locking not
to get output from different processes mixed on the same line, but one
output line from one process only.
- Timestamps?
etc. Comments, please?
--tml
Index: glib/gmain.c
===
RCS file: /cvs/gnome/glib/glib/gmain.c,v
retrieving revision 1.126
diff -u -2 -r1.126 gmain.c
--- glib/gmain.c14 Mar 2005 04:26:57 - 1.126
+++ glib/gmain.c24 Mar 2005 15:14:27 -
@@ -34,7 +34,4 @@
#include config.h
-/* uncomment the next line to get poll() debugging info */
-/* #define G_MAIN_POLL_DEBUG */
-
#include glib.h
#include gthreadinit.h
@@ -79,4 +76,10 @@
#include galias.h
+#ifdef G_OS_WIN32
+#define FD_FORMAT %#x
+#else
+#define FD_FORMAT %d
+#endif
+
/* Types */
@@ -299,4 +302,10 @@
};
+#ifdef G_ENABLE_DEBUG
+static gboolean g_main_poll_debug = FALSE;
+#else
+#define g_main_poll_debug 0
+#endif
+
#ifdef HAVE_POLL
/* SunOS has poll, but doesn't provide a prototype. */
@@ -333,7 +342,7 @@
else
{
-#ifdef G_MAIN_POLL_DEBUG
- g_print (g_poll: waiting for %#x\n, f-fd);
-#endif
+ if (g_main_poll_debug)
+ g_printerr (g_poll: waiting for %#x\n, f-fd);
+
handles[nhandles++] = (HANDLE) f-fd;
}
@@ -348,7 +357,7 @@
* - First PeekMessage
*/
-#ifdef G_MAIN_POLL_DEBUG
- g_print (PeekMessage\n);
-#endif
+ if (g_main_poll_debug)
+ g_printerr (PeekMessage\n);
+
if (PeekMessage (msg, NULL, 0, 0, PM_NOREMOVE))
ready = WAIT_OBJECT_0 + nhandles;
@@ -363,7 +372,7 @@
* - WaitMessage
*/
-#ifdef G_MAIN_POLL_DEBUG
- g_print (WaitMessage\n);
-#endif
+ if (g_main_poll_debug)
+ g_printerr (WaitMessage\n);
+
if (!WaitMessage ())
{
@@ -397,12 +406,12 @@
else
{
-#ifdef G_MAIN_POLL_DEBUG
- g_print (WaitMessage\n);
-#endif
+ if (g_main_poll_debug)
+ g_printerr (WaitMessage\n);
+
WaitMessage ();
KillTimer (NULL, timer);
-#ifdef G_MAIN_POLL_DEBUG
- g_print (PeekMessage\n);
-#endif
+ if (g_main_poll_debug)
+ g_printerr (PeekMessage\n);
+
if (PeekMessage (msg, NULL, 0, 0, PM_NOREMOVE)
msg.message != WM_TIMER)
@@ -418,7 +427,7 @@
* - Use MsgWaitForMultipleObjects
*/
-#ifdef G_MAIN_POLL_DEBUG
- g_print (MsgWaitForMultipleObjects(%d, %d)\n, nhandles,
timeout);
-#endif
+ if (g_main_poll_debug)
+ g_printerr (MsgWaitForMultipleObjects(%d, %d)\n, nhandles,
timeout);
+
ready = MsgWaitForMultipleObjects (nhandles, handles, FALSE,
timeout, QS_ALLINPUT);
@@ -443,7 +452,7 @@
* - Use WaitForMultipleObjects
*/
-#ifdef G_MAIN_POLL_DEBUG
- g_print (WaitForMultipleObjects(%d, %d)\n, nhandles, timeout);
-#endif
+ if (g_main_poll_debug)
+ g_printerr (WaitForMultipleObjects(%d, %d)\n, nhandles, timeout);
+
ready = WaitForMultipleObjects (nhandles, handles, FALSE, timeout);
if (ready == WAIT_FAILED)
@@ -455,11 +464,11 @@
}
-#ifdef G_MAIN_POLL_DEBUG
- g_print (wait returns %ld%s\n,
- ready,
- (ready == WAIT_FAILED ? (WAIT_FAILED) :
- (ready == WAIT_TIMEOUT ? (WAIT_TIMEOUT) :
-(poll_msgs ready == WAIT_OBJECT_0 + nhandles ? (msg) :
;
-#endif
+ if (g_main_poll_debug)
+g_printerr (wait returns %ld%s\n,
+ ready,
+ (ready == WAIT_FAILED ? (WAIT_FAILED) :
+(ready == WAIT_TIMEOUT ? (WAIT_TIMEOUT) :
+ (poll_msgs ready == WAIT_OBJECT_0 + nhandles ? (msg) :
;
+
for (f = fds; f fds[nfds]; ++f)
f-revents = 0;
@@ -483,4
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
Slightly lacking documentation (was: Re: Problems with GtkPaned)
On Thu, 24 Mar 2005 07:58:19 -0500, Owen Taylor [EMAIL PROTECTED] wrote: On Thu, 2005-03-24 at 13:09 +0100, Miroslav Rajcic wrote: On Thu, 24 Mar 2005 11:40:35 +0100, Miroslav Rajcic [EMAIL PROTECTED] You can listen for changes to the position property on GtkPaned: http://developer.gnome.org/doc/API/2.0/gtk/GtkPaned.html#GtkPaned--position Thanks for the tip, unfortunately position is a property, not the event. [...] Try notify::position I think 'notify' is one of the less obvious aspects of GObjects for one reason or another. Would it make sense to add a short blurb like 'See GtkWidget::notify and g_signal_connect' below the 'Properties' header in the API docs? Similarly for child properties and style properties (is anything else but lack of convenient API suggesting that maybe they're not meant for application developers to fiddle with?) Just a thought... -- Tommi Komulainen [EMAIL PROTECTED] ___ 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
introspection and broken API
Hi, Back in the day when I was working on the Inti C++ bindings, one of the objectives was to clean up the cruft from the GTK+ C API. Some examples of cleanups one might do: - put the main loop only in the GLib layer, no gtk_main visible - hide color allocation, just always use the GdkRGB stuff - fix some of the other examples of weird X features leaking through - gdk_drawable_get_size() replaced by get_width()/get_height() accessors - omit deprecated APIs - omit non-multihead-correct APIs I'm thinking about this because in looking at Java-GNOME it doesn't do these cleanups, I would guess because it isn't always obvious what to clean up. Should these sort of cleanups be in some way shared between language bindings (e.g. by including them in the introspection layer)? 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 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: introspection and broken API
On Fri, 2005-03-25 at 00:45 -0500, Havoc Pennington wrote: - put the main loop only in the GLib layer, no gtk_main visible - hide color allocation, just always use the GdkRGB stuff - fix some of the other examples of weird X features leaking through - gdk_drawable_get_size() replaced by get_width()/get_height() accessors - omit deprecated APIs - omit non-multihead-correct APIs A couple other good ones I remembered: - dumping GtkObject out of the class hierarchy - killing off the argument to gtk_window_new I know there are more. 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
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
