On Sat, 2008-07-26 at 23:35 +0200, Guido Berhoerster wrote: > > the only time when a gtk+ application writes to the recently used files > > storage and it's not calling the GtkRecentManager API directly is when > > the gtk+ main loop level reaches 0 - which is to say after the first > > gtk_main() call in the whole application returns (this is needed to > > ensure that the file is not left in an inconsistent state); all other > > writes are definitely explicit. I seriously doubt that vim spins the > > main loop and the stops it at every key press - it would be quite > > insane. > > Thanks for the explanation, I'm not sure if I got it right, in > the eventhandlers there is often code like: > [...] > if (gtk_main_level() > 0) > gtk_main_quit(); > [...] > If gtk_main_level() returns 1 and gtk_main_quit() is called, does > that mean that the recently used files list gets written? yes, if the main loop level is 1 and main_quit() is called, the main loop level reaches 0 and 1. the clipboard is saved 2. the recently used files list is saved - the rationale being: usually a main loop level of 0 means that the application is quitting. is gvim really calling gtk_main_quit() at each button/key press or motion event? in which case gvim is completely bonkers. why is it doing that? is there another main loop running? why can't gvim use the GLib main loop to spin the other main loop? the GLib main loop is pretty extensible - even QT supports the GLib main loop by default. as it is, gvim is pretty much abusing gtk+. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net _______________________________________________ gtk-list mailing list gtk-list@xxxxxxxxx http://mail.gnome.org/mailman/listinfo/gtk-list
