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 do the background work, not change
the cursor. and you instantiate this thread from within the callback, not
as part of your main routine.
so, the sequence of events might be:
in your callback:
1) modify the cursor as necessary
2) create a thread to do the background work
3) quit
in your thread:
1) do your work
2) call g_idle_add() invoking a function that understands you are
returning from your background thread, i.e., render the results back to
the user
basic guidelines to follow:
1) have your callback do as little work as possible.
2) do any work requiring time in a separate thread, returning to the
mainloop via g_idle_add()
following this model, you will gain the following:
1) user interface will always be responsive since mainloop() will remain
free to process events
2) cursor will change in a timely fashion
3) multiple cpu's will be utilized to their best advantage
if this isn't what you want, then perhaps you could restate your goals?
cheers,
richard
On Sat, Dec 20, 2008 at 11:37 AM, haitao_yang@xxxxxxxxxxxxxxxxx
<haitao_yang@xxxxxxxxxxxxxxxxx> wrote:
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, or just using the
term "thread" in a way that nobody else does. g_idle_add() and
g_timeout_add() do *not* "launch" any threads. The callback functions
passed as parameters to these functions run in the same thread that
runs the main loop in question. (That might of course be a different
thread than the one where you called g_idle_add() or g_timeout_add(),
but anyway, no new thread creation is involved.)
> > nevertheless, this new thread can
> > not run with your main thread simultaneously.
>
"can not" or "should not"? threads that can not run simultaneously
would be rather pointless, I think;) Anyway, if your following text
is based on the wrong belief that g_idle_add() or g_timeout_add()
create new threads, it is pointless to try to understand what you try
to say.
--tml
===========================================
Thanks for your reply. I think I make a mistake about the concept.
Following is my summary:
1) g_idle_add() or g_timeout_add() is not related to "thread", but
related to "event-loop".
2) When you call the sleep() function in the callback function of
g_idle_add or g_time_add, your whole program will wait;
When you call the sleep() in other "thread", the whole program will
not wait.
3) Would the callback function be called till gtk_main() being called?
(you can examine the example below )
--------------------
#include <glib.h>
static gpointer cursor_change(gpointer data_pass)//2
//static gboolean cursor_change(gpointer data_pass)//1
{
//1 ---
/*fprintf(stderr, "In cursor_change\n");
sleep(10);
return TRUE;*/
//2 ---
gint i=0;
while(1)
{
gdk_threads_enter();
fprintf(stderr, "thread:%d\n", i++);
sleep(10);
gdk_threads_leave();
}
}
void callback (GtkButton* pbtn, gpointer data)
{
fprintf(stderr, "In Button Callback\n");
}
int main( int argc, char *argv[] )
{
gtk_init (&argc, &argv);
if (!g_thread_supported ())
{
g_thread_init(NULL);
gdk_threads_init();
}
//1 ---
//g_idle_add( cursor_change, NULL);
//2 ---
//g_timeout_add(1, cursor_change, NULL);
//3 ---
g_thread_create ( cursor_change, NULL, FALSE, NULL);
//5 ---
//sleep(100);
//6
GtkWidget *window = gtk_window_new (GTK_WINDOW_TOPLEVEL);
GtkWidget *button = gtk_button_new_with_mnemonic ("button");
g_signal_connect (G_OBJECT (button), "clicked", G_CALLBACK
(callback), NULL);
gtk_widget_show (button);
gtk_container_add (GTK_CONTAINER (window), button);
gtk_widget_show (window);
gtk_main ();
return 0;
}
--
Sincerely,
Alfred Young
R&D, Application Architectures
www.foxitsoftware.com
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
