GNOME Bugzilla – Bug 546691
do not save the recently used files list on main_loop_level = 0
Last modified: 2014-12-22 23:53:05 UTC
With GTK > 2.10.0, specifically since revision 18184 (http://svn.gnome.org/viewvc/gtk%2B/trunk/gtk/gtkmain.c?r1=18141&r2=18184) the list of recently used files is written to disk when the last GTK main loop level is quit. There seems to be an assumption that the application will exit. The above mentioned change in behavior now introduces problems for applications which quit the GTK main loop without exiting (e.g. the GTK GUI of vim spinning its own internal main loop which does not use GTK/Glib). While this may not be the intended use of the GTK main loop, there appears to be no specification disallowing such use or even describing the consequences. The reference manual only states the following about the GTK main loop: [...] gtk_main () [...] Runs the main loop until gtk_main_quit() is called. You can nest calls to gtk_main(). In that case gtk_main_quit() will make the innermost invocation of the main loop return. [...] gtk_main_quit () [...] Makes the innermost invocation of the main loop return when it regains control. [...] (see http://library.gnome.org/devel/gtk/stable/gtk-General.html#gtk-main-quit) For applications relying on the initial behavior this may cause problems (e.g. excessive I/O). gtk_main() quitting the last GTK main loop should revert to its previous behavior and not assume that the application will exit, at the very least it should be possible for applications to disable GTK recent manager and thereby work around the problem.
just to add full reference, here's the thread on gtk-list: http://mail.gnome.org/archives/gtk-list/2008-July/msg00115.html I maintain what I wrote here: http://mail.gnome.org/archives/gtk-list/2008-July/msg00131.html that is: is gvim really calling gtk_main_quit() at each button/key press or motion event? in which case gvim is completely bonkers. gvim is clearly abusing gtk+, when it should implement a GSource and have the main loop spin the low-level main loop. the RecentManager saves the recently used files list at the end of the main loop because it needs to ensure that the file is always in a consistent state - especially if gtk_recent_manager_add_item() is called and GIO is still sniffing the MIME type, or if the recently used files are added from an idle handler like some application do (e.g. eog). if the main loop quits and the changes are not written then we might have data loss. while it's true that there is no documentation reguarding what happens at the end of the main loop it is assumed that once the main loop is stopped the application is either quitting or the main loop is going to be restarted at a later point. gvim is restarting the main loop at every motion, key and button event, which is utterly brain damaged. having made my point, I can remove the dumping of the recently used files list after I checked that no data loss is going to happen.
retitling / reassigning to the right component
not worth keeping open any longer