gtk_main() at level 0 and gtk_file_chooser_dialog_new
- From: Alan <alan layec cermics enpc fr>
- To: gtk-app-devel-list gnome org
- Subject: gtk_main() at level 0 and gtk_file_chooser_dialog_new
- Date: Wed, 19 Sep 2012 17:32:31 +0200
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]