Re: Idle Function Not Getting Called
I tried G_PRIORITY_HIGH_IDLE with similar results ... the idle
function is called only with the following code:
g_idle_add_full (G_PRIORITY_HIGH_IDLE, (GSourceFunc) idlefunc, NULL, NULL);
while (gtk_events_pending ())
gtk_main_iteration ();
If the while loop is not part of the coding then the idle function
(idlefunc) is not called.
The difference with using G_PRIORITY_HIGH_IDLE is that some of the
buttons inside the dialogs drawn in the idle function are not
displayed. But they still react to user clicks if clicked in the right
area. I expect this is linked to your "GDK drawing functions"
statement above.
Then you must have some function blocking between your call to
g_idle_add_full() and control returning to the main loop.
Anything in a GTK+ signal or event handler must not block. This means
in practice that nothing should block after your call to gtk_main().
After spending more time with my code I'm just not seeing it. Below is
the pertinent code.
AddName() is called from a drop-down menu item.
Via debug code I've seen that the program flow is as it should be ... all
functions are exited. The first idle function (PlayNetGame()) is added,
executed, and exited as it should be. The second idle function
(PlayTheGame()) is added but is never called.
Does anyone see what might be blocking the call of PlayTheGame() or have
any other suggestions?
void
AddName (gpointer callback_data, guint callback_action, GtkWidget *widget) {
/* listen on another socket for challenges */
if (!g_thread_create (Wait4Challenge, NULL, FALSE, NULL))
syslog (LOG_INFO, "error trying to create new thread");
}
char challenger[50];
/* wait for a gameplay challenge from another user */
void *
Wait4Challenge () {
int x, port = 0, listensock, connected;
char buffer[5000], *msg[5];
listensock = -1;
for (x = 0; x < 5; x++)
msg[x] = NULL;
wsock = get_connection_nofork (SOCK_STREAM, port, &listensock);
connected = 1;
while (connected) {
/* get communication */
if (sock_gets (wsock, &buffer[0], sizeof (buffer)) < 0) {
msg[0] = "There is a problem with the server.\n\n";
outMessage (msg);
connected = 0;
}
if (buffer[0] == 'R')
/* this user removed his ID from the waiting pool so end this
thread and close the socket */
connected = 0;
if (buffer[0] != 'C')
continue;
strcpy (&challenger[0], &buffer[1]);
/* add idle function to process requests to play from challengers */
g_mutex_lock (data_mutex);
FromThread = 0;
g_idle_add ((GSourceFunc) PlayChallenger, NULL);
/* wait for PlayChallenger() to finish */
while (!FromThread)
g_cond_wait (data_cond, data_mutex);
g_mutex_unlock (data_mutex);
if (!ShallWeContinue4Thread) {
/* this challengee does not want to play this challenger */
sock_puts (wsock, "NO\n");
for (x = 0; x < 5; x++)
msg[x] = NULL;
continue;
}
else {
/* this challengee wants to play */
char work[50], cport[50], *blank;
/* tell server to open a port for receiving communications from the
challenger (the challengee server
process will control gameplay) */
sock_puts (sock, "O\n");
sock_puts (wsock, "OK \n");
g_idle_add ((GSourceFunc) PlayNetGame, NULL);
/* no longer need this thread */
connected = 0;
}
}
shutdown (wsock, SHUT_RDWR);
close (wsock);
return (NULL);
}
GtkWidget *dlgFile;
/* display a dialog which calls for a user response */
gboolean
PlayChallenger () {
gchar labeltext[500];
GtkWidget *label = NULL, *hbox, *separator, *okbutton, *disbutton;
dlgFile = gtk_dialog_new ();
gtk_window_set_title (GTK_WINDOW (dlgFile), "Play Challenger?");
gtk_signal_connect (GTK_OBJECT (dlgFile), "delete_event", GTK_SIGNAL_FUNC
(donot_delete_event), 0);
gtk_window_set_modal (GTK_WINDOW (dlgFile), TRUE);
strcpy (&labeltext[0], &challenger[0]);
strcat (&labeltext[0], " challenges you to a game. Do you accept?\n\n");
label = gtk_label_new (labeltext);
gtk_label_set_line_wrap (GTK_LABEL (label), TRUE);
gtk_box_pack_start (GTK_BOX (GTK_DIALOG (dlgFile)->vbox), label, TRUE,
TRUE, 0);
separator = gtk_hseparator_new ();
gtk_box_pack_start (GTK_BOX (GTK_DIALOG (dlgFile)->vbox), separator, FALSE,
TRUE, 0);
hbox = gtk_hbutton_box_new ();
gtk_box_pack_start (GTK_BOX (GTK_DIALOG (dlgFile)->vbox), hbox, FALSE,
FALSE, 0);
okbutton = gtk_button_new_with_label ("ACCEPT");
g_signal_connect (G_OBJECT (okbutton), "clicked", G_CALLBACK (PlayOK),
dlgFile);
disbutton = gtk_button_new_with_label ("Decline");
g_signal_connect (G_OBJECT (disbutton), "clicked", G_CA
Re: why do constructors return GtkWidget?
Tristan Van Berkom wrote: On Wed, Sep 9, 2009 at 2:53 AM, Emmanuel Touzery wrote: Hi, [...] You know what I'm thinking... I think that this is from times where people used to build GUIs in the code... When they were writing all the container embedding and all, in C, building their dialogs. At that time that convention surely helped, you were constantly adding widgets to containers and so on. Today this is done in gtkbuilder and so what we have left is code not doing so much embedding in code (though obviously it happens) but Yes I would say its a historical thing, and I certainly hope that using GtkBuilder can be the standard in the end (I guess we still have lots of ground to cover). Only over my dead body ;-) Carlos Cheers, -Tristan ___ 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: GtkTextView copy-paste default handler problem
Matthew Talbert wrote: >> I want to restrict copy and paste to just text format. For this I've >> connected to "copy-clipboard", "cut-clipboard" and "paste-clipboard" >> signals. Unfortunately this doesn't stop default handlers from being >> called so everything gets copied twice. I added >> g_signal_stop_emission_by_name() calls to my signal handlers but it >> didn't seem to have any effect. I even wrote function that unregisters >> all GtkTextBuffer serialize and unserialize formats but that didn't help >> either. > > Are your signal handlers returning TRUE or FALSE? FALSE allows the > event to keep propagating, while TRUE prevents it. Also, which > function are you using to connect your signal handlers? > g_signal_connect? > > Matthew Yes I'm using g_signal_connect to connect the signal handlers. Returning TRUE or FALSE is a good suggestion but unfortunately they are signals not events so the return type is void. - Tuukka ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
On Wed, Sep 9, 2009 at 2:53 AM, Emmanuel Touzery wrote: > Hi, [...] > You know what I'm thinking... I think that this is from times where people > used to build GUIs in the code... When they were writing all the container > embedding and all, in C, building their dialogs. At that time that > convention surely helped, you were constantly adding widgets to containers > and so on. Today this is done in gtkbuilder and so what we have left is code > not doing so much embedding in code (though obviously it happens) but Yes I would say its a historical thing, and I certainly hope that using GtkBuilder can be the standard in the end (I guess we still have lots of ground to cover). Cheers, -Tristan ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
> I think that this is from times where people > used to build GUIs in the code... When they were writing all the container > embedding and all, in C, building their dialogs. Those times are still very much here. For instance in the application that gave GTK+ the "G" in its name. --tml ___ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
Re: why do constructors return GtkWidget?
I'm also using the real types in my declarations, though I'm paying
the price with casts.
And here I mean:
GtkMenuItem *dir_or_not = GTK_MENU_ITEM
(gtk_menu_item_new_with_label ("Or not"));
gtk_menu_shell_append (GTK_MENU_SHELL (directory_filter_menu),
GTK_WIDGET (dir_or_not));
The price I'm paying here is GTK_MENU_ITEM and GTK_WIDGET. Which would
both go away with another convention.
As I said, I believe if the convention was changed to return the real
types most of the GTK programs would not have an increase in the number
of casts (now that GUIs are built with GtkBuilder). But who knows.
I guess this wouldn't even change the ABI (??) it would just cause old
code to compile with warnings (except those who build with -Werr ;-) ).
Well in any case let's forget it, I guess it's impossible to change this
by now, so this is all just rhetorical. But thanks for the clarifications.
emmanuel
___
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
