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
_______________________________________________ gtk-app-devel-list mailing list gtk-app-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/gtk-app-devel-list