Francesco Montorsi wrote:
[...]
>>> My switch-page handler in fact performs some code which should be
>>> executed only on user-actions, not on selection changes by GTK.
>>
>>
>> from the docs about "switch-page":
>> "Emitted when the user or a function changes the current page"
>>
>> a.) "switch-page" maybe isnt exactly where all that logic belongs ?
>
> yes, I know; but which event handler can I put that logic, then ?
> There's a documented "select-page" signal but docs say almost nothing
> about it... so I don't know how it differs from "switch-page"
>
>
>> b.) maybe your code actually _knows_ that it is in the process of
>> manually
>> setting the page of the notebook and should just behave
>> accordingly ?
>
> the only thing I can think to is to set a flag just before calling
> gtk_notebook_set_current_page:
>
> bSkipNextSwitchEvent = true;
> gtk_notebook_set_current_page(...);
>
> static void my_page_change_callback(...)
> {
> if (bSkipNextSwitchEvent)
> return;
> }
>
> However I think that's rather unsafe as the user could interfere with
> that and I fear that some user-generated events could be lost that way...
>
Impossible:
{
bSkipNextSwitchEvent = TRUE;
gtk_notebook_set_current_page (<this will recurse into
my_page_change_callback>);
my_page_change_callback () { if (bSkipNextSwitchEvent) return; }
bSkipNextSwitchEvent = FALSE;
/* rest of your code... */
return;
/* Events can only be recieved by gtk+ after this line */
}
If you are executing code - you are not reading a socket from the X
server and you are not recieving events - once you return to the
mainloop another event or other GSource can be processed.
Cheers,
-Tristan
_______________________________________________
gtk-app-devel-list mailing list
gtk-app-devel-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-app-devel-list
