Re: what should I do if I got "Stream has outstanding operation" error.
2017-03-02 2:29 GMT+08:00 KC <kcc1...@gmail.com>: > Hi, > > I use g_output_stream_printf() to send command to a server > and use g_data_input_stream_read_line() to read data back. > > Sometime I got error message "Stream has outstanding operation". > What should I do if I detect this error ? > Do I need to flush() the IO stream after g_output_stream_printf() ? > I believe I solved the issue. My app is multi-thread app. Lock/unlock around I/O commands solved the problem. KC > > Thanks > KC > ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
what should I do if I got "Stream has outstanding operation" error.
Hi, I use g_output_stream_printf() to send command to a server and use g_data_input_stream_read_line() to read data back. Sometime I got error message "Stream has outstanding operation". What should I do if I detect this error ? Do I need to flush() the IO stream after g_output_stream_printf() ? Thanks KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk/gtk+ win32 thread question, please help to explain
On Wed, Nov 23, 2011 at 4:16 PM, Emmanuel Thomas-Maurin manutm...@gmail.com wrote: On 11/23/2011 07:28 AM, KC wrote: On Wed, Nov 23, 2011 at 12:43 PM, Michael Cronenworth m...@cchtml.com wrote: On 11/22/2011 10:13 PM, KC wrote: So the Unfortunately ... statement only apply to GDK on WIN32 ? It's safe to call GTK+ APIs (if protected by gdk_threads_enter/leave) from multi-threads even on WIN32 backend ? Is this correct ? No. GTK2 (I can't say about GTK3, but I bet it is the same) most definitely does not work with threads even with gdk_threads_enter/leave under Win32. You can use threads in your app, but all GTK2 operations must be strictly done by the primary thread. So, the gtk-thread.c example from http://developer.gnome.org/gdk/stable/gdk-Threads.html works on WIN32 is just good luck ? In that case, it will be better if the document can add a NOTE for gtk-thread.c example to remind reader it's not guarantee to work on WIN32. It's actually well documented I knew it's well documented. I just want to point out that the example, gtk-thread.c, provided in http://developer.gnome.org/gdk/stable/gdk-Threads.html although works fine on WIN32, but it's not correct. And that should be mentioned to avoid confusion. on: http://www.gtk.org/documentation.php - Windows portability for gnome software (http://www.iki.fi/tml/fosdem-2006.pdf) I don't know this useful presentation before, Thanks. KC -- Emmanuel Thomas-Maurin manutm...@gmail.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
gdk/gtk+ win32 thread question, please help to explain
Hi, According to http://developer.gnome.org/gdk/stable/gdk-Threads.html ... Unfortunately the above holds with the X11 backend only. With the Win32 backend, GDK calls should not be attempted from multiple threads at all. ... The Unfortunately ... statement does not mention GTK+, only GDK. Does it only apply to GDK Win32 ? Or it applies to both GDK and GTK+ ? In my application, I call gtk_list_store_newv() from many non-main threads (not via idle, timeout callback) and I do protect the GTK call with gdk_threads_enter/leave(). It works fine even on Win32 !! Do I doing the right thing ? or just has good luck ? Best Regards, KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: gdk/gtk+ win32 thread question, please help to explain
On Wed, Nov 23, 2011 at 12:43 PM, Michael Cronenworth m...@cchtml.com wrote: On 11/22/2011 10:13 PM, KC wrote: So the Unfortunately ... statement only apply to GDK on WIN32 ? It's safe to call GTK+ APIs (if protected by gdk_threads_enter/leave) from multi-threads even on WIN32 backend ? Is this correct ? No. GTK2 (I can't say about GTK3, but I bet it is the same) most definitely does not work with threads even with gdk_threads_enter/leave under Win32. You can use threads in your app, but all GTK2 operations must be strictly done by the primary thread. So, the gtk-thread.c example from http://developer.gnome.org/gdk/stable/gdk-Threads.html works on WIN32 is just good luck ? In that case, it will be better if the document can add a NOTE for gtk-thread.c example to remind reader it's not guarantee to work on WIN32. Regards, KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
how to check the widget is really visible or not ?
Hi, I did a very simple test (see attachment). Create a window and add a timeout callback to check if the window is visible. When I run the example, the window popup and callback will print win .. VISIBLE, so far so good. Then, I deiconify the window; move the window to other desktop workspace; use other application to cover the window completely No matter what I do, I still got the window is visible What's wrong with my code ? Thanks a lot. Regards KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Gtk2 cause SIGTRAP under gdb 6.8
Hi, I'm using gtk+-bundle_2.22.1 (win32). And I found even a simple Hello World Gtk2 application will trigger SIGTRAP when run by gdb 6.8. The message is as below: Program received signal SIGTRAP, Trace/breakpoint trap. 0x7c92eb74 in ntdll@LdrAlternateResourcesEnabled () from C:\WINDOWS\system32\ntdll.dll If I replace gdb 6.8 by gdb 7.2 (both gdb comes from www.mingw.org), the SIGTRAP disappear ... but all Gtk2 application will be slow down a lot. Anyone has similar issue or solution ? Thanks a lot. Regards KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Change view of GtkCheckMenuItem without trigger the action
Hi,
Is it possible to change view (check/uncheck) of GtkCheckMenuItem without
trigger the connected ('toggled') callback function ?
I have a GUI application which also allow control from client (from network).
When user click on GtkCheckMenuItem, the application will do:
User click on GtkCheckMenuItem --- callback, update internal data
When user issue command from client:
update internal data --- change view of GtkCheckMenuItem without callback.
Is this possible ? Or any better approach ?
I believe this is related to MVC model for GtkWidget ...
TextView/TreeView offer MVC model, but how about other GtkWidget ?
Regards
KC
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
how to read Gtk signal document ?
Hi, Could someone explain more detail about the following document for GtkButton Signals activate : Run First / Action clicked: Run First / Action enter : Run First leave : Run First pressed: Run First released : Run First I can guess what these mean, but can't find any official document for them. Specially ... what does Run First mean ? All of the above signal are labeled as Run First, so what's the real order ? Thanks Regards, KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: GTK deadlock in gtk_main
2010/8/4 Tomas Soltys tomas.sol...@range-software.com: Hi, So what you suggest is to have gdk_threads_enter and gdk_threads_leave at the beginning and at the end of the idle function? Is this really intended? YES, check http://library.gnome.org/devel/gdk/unstable/gdk3-Threads.html Idles, timeouts, and input functions from GLib, such as g_idle_add(), are executed outside of the main GTK+ lock. So, if you need to call GTK+ inside of such a callback, you must surround the callback with a gdk_threads_enter()/gdk_threads_leave() pair or use gdk_threads_add_idle_full() which does this for you. However, event dispatching from the mainloop is still executed within the main GTK+ lock, so callback functions connected to event signals like GtkWidget::button-press-event, do not need thread protection. Regards KC Anyway, thanks for your help. Regards, Tomas Hi. You're having troubles because gtk_main_iteration_do() does it's own unlock/lock cycle. When your idle callback is executed, your mutex is unlocked. gtk_main_iteration_do() unlocks it again, executes whatever is there to be executed and locks it. Now control returns back to main loop, which tries to lock mutex and here you have your lock. Tadej -- Tadej Borovšak tadeboro.blogspot.com tadeb...@gmail.com tadej.borov...@gmail.com ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: How to change color of GtkCellRendererProgress ?
On Mon, Aug 2, 2010 at 2:46 AM, Jaroslav Šmíd jardas...@gmail.com wrote: You can't. The only way to change this is to modify theme you use. That's bad news to me. I were planned to use it for a simple histogram application but color is required feature ... Thanks anyway. Regards KC On Sat, Jul 31, 2010 at 6:33 AM, Kuang-Chun Cheng kcch...@linuxdaq-labs.com wrote: Hi, As subject said, how to change color of GtkCellRendererProgress ? Either color of text or bar is OK. This looks like a simple question, but I can't find anything from Google yet. Thanks a lot. Regards, KC ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list -- Jaroslav Šmíd ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list ___ 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
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
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
