that bit of documentation is a bit confusing and definitely misleading.
what it essentially says is that if you make calls to gtk_ or gdk_ then
the thread calls are required.
but if all calls to gtk_ and gdk_ are executed within routines executing
as part of the main loop, thread calls are not re
dow), i.e., do
not call gtk_widget_show() as you make each widget.
cheers,
richard
Hello all:
Firstly, Thanks Richard for his valuable infomation and thanks all who
reply me.
I still follow the thread "A problem about programming with
Gtk+(gtk-list Digest, Vol
On Tue, 23 Dec 2008 04:42:09 +0300, haitao_y...@foxitsoftware.com
wrote:
I followed the step of Richard's guide, everything run well, but I can
not exit from the callback of g_idle_add correctly. Why?
From gnome help:
"Idles, timeouts, and input functions from GLib, such as g_idle_add(),
Hello all:
Firstly, Thanks Richard for his valuable infomation and thanks all who
reply me.
I still follow the thread "A problem about programming with
Gtk+(gtk-list Digest, Vol 56, Issue 22)". Maybe I unintentionally
changed the subject in my code:)
I followed the step of Richa
what exactly are you trying to do? cause your program's not gonna do much
as it is, and it's not obvious to me what exactly you're trying to achieve
here.
if it's related to modifying the cursor as a result of user interaction,
you should try another model.
that is, set up a different thread to
As nobody else seems to want to follow up on this, I'll try to...
(Please, no *personal* replies to me. Follow up to the list.)
> > Maybe there is a reason that can explain this phenomenon. You can launch a
> > thread with g_idle_add or g_time_out_add,
>
Sorry, either you are misunderstanding
As nobody else seems to want to follow up on this, I'll try to...
(Please, no *personal* replies to me. Follow up to the list.)
> Maybe there is a reason that can explain this phenomenon. You can launch a
> thread with g_idle_add or g_time_out_add,
Sorry, either you are misunderstanding seriously
ot;Re: Contents of gtk-list digest..."
Today's Topics:
1. A problem about programming with Gtk+ ( ??? )
2. A problem about programming with Gtk+ (gordon)
3. Application development using GTK and GLADE3 (Harinandan S)
-
On Mon, 15 Dec 2008 12:07:38 +0800
"gordon" wrote:
>Dear Gnome.
> I got a prablem about programming in Gtk+. The following program creat
> a 'Button'.But
>there is a problem with the 'static void callback( GtkWidget *widget,
>gpointer data )'.
>In this part of the program ,i want to c
Dear Gnome.
I got a prablem about programming in Gtk+. The following program creat a
'Button'.But
there is a problem with the 'static void callback( GtkWidget *widget, gpointer
data )'.
In this part of the program ,i want to change the cursor before the program
executing the for-loop.
Dear Gnome.
I got a prablem about programming in Gtk+. The following program
creat a 'Button'.But
there is a problem with the 'static void callback( GtkWidget *widget,
gpointer data )'.
In this part of the program ,i want to change the cursor before the program
executing the for-loop.
Her
On Sun, 16 Dec 2001 11:45:41 EST, Paul Davis said:
> we need to make it more clear that after fork(2), the child should never
> access GTK structures or functions unless the parent never does so
> again. can we add something to the FAQ about this?
What you *need* to do is as follows:
1) Have a
> You can't use a child process to directly update a progress bar widget
> in the parent. End of story. It won't work. You have to do something
> like have the child send progress information to the parent via a
> pipe.
>
Hy Havoc,
Thank you for your explanation about the fork. I understand it b
>The rule to follow is:
> - You may not touch GTK widgets created in the parent in the child,
> in any way, it will not work
I believe that if we are to be completely rigourous:
You may not touch GTK widgets created in the parent in the child,
if the parent ever accesses them or any G
"Jean-Christophe Berthon" <[EMAIL PROTECTED]> writes:
> So in the case the child is doing computation while the father show progress
> information and allow the user to stop the computation. I'm modifying the
> memory of Gtk --> updating the value of progress bar and some labels and
> status bar
t; <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Monday, December 17, 2001 10:39 AM
Subject: Re: A problem about programming with gtk+ in multiprocess.
Hi Jean-Christophe,
Freeing memory in the child process is not normally necessary since most
kernels (including Linux) employ the "
L PROTECTED]>
Sent: Sunday, December 16, 2001 5:45 PM
Subject: Re: A problem about programming with gtk+ in multiprocess.
> >hello all,
> >I have a problem when programming with gtk+ in multiprocess.
> >please look follow codes :
>
> wh
ROTECTED]>
To: <[EMAIL PROTECTED]>
Cc: <[EMAIL PROTECTED]>
Sent: Sunday, December 16, 2001 5:45 PM
Subject: Re: A problem about programming with gtk+ in multiprocess.
> >hello all,
> >I have a problem when programming with gtk+ in multiprocess.
> >please look follow co
>hello all,
>I have a problem when programming with gtk+ in multiprocess.
>please look follow codes :
what is is that has made some people think that this "fork, then have
the parent and the child continue to use GTK+" will work?
you cannot do this (reliably). X Window is inherently multithread
ÀîÓê <[EMAIL PROTECTED]> writes:
> case 0:
> {
> /* in child process , i change text of GtkLabel, and update it */
> time_t t;
> char* chartime;
> gchar* text, *newtext;
> time(&t);
> chartime = g_strdup(ctime(&t)) ;
> gtk_label_get(GTK_LABEL(cb_dat
hello all,
I have a problem when programming with gtk+ in multiprocess.
please look follow codes :
/* runcmd.c */
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
#include
/* for callback func's argument */
typedef struct cb_data_t_ {
21 matches
Mail list logo
