gtk_main() at level 0 and gtk_file_chooser_dialog_new



Hi,

I use a GTK+ application where we mainly enter (with gtk_main()) and leave 
(with gtk_main_quit()) the gtk main event loop at level 0. That means that 
most of time we don't increase the gtk main loop level by calling recursively 
gtk_main(). We use gui between calls of gtk_main()/gtk_main_quit() and we do 
other things between gtk_main_quit() and gtk_main().

In that application we use "gtk_file_chooser_dialog_new" to display some gui 
for files opening/saving and etc. But after running such a gui, one can see 
that the gtk_main() function becomes slower than the first times we have called 
it -if we stay at the gtk main level 0 of course-.

Please find in attachment an example to compile that shows this behavior.

This is surely because gtk_file_chooser_dialog_new lets some "idle things" 
(threads in background for i.e) even if the gui using that function was 
destroyed.

After debugging a little bit the gtk+ lib (I use gtk+-2.24.12), the time 
consumption comes from the line 1311 (gtk_main function) of the file 
gtk/gtkmain.c :

1305  if (gtk_main_loop_level == 0)
1306    {
1307      /* Try storing all clipboard data we have */
1308      _gtk_clipboard_store_all ();
1309
1310      /* Synchronize the recent manager singleton */
1311      _gtk_recent_manager_sync ();
1312    }

Is there a way to entirely destroy the "idle things" of the 
gtk_file_chooser_dialog_new widget to do not lost time any more with the 
_gtk_recent_manager_sync function each time we use gtk_main() at 
gtk_main_loop_level 0 ?

Regards,
Alan



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]