That does indeed mean it; it's what Emmanuele supposed and it turns out to be right. It's rather strange for a gtk+ app to do this, is there some kind of other non-glib-based main loop running?
2008/7/26 Guido Berhoerster <[EMAIL PROTECTED]> > * Emmanuele Bassi <[EMAIL PROTECTED]> [2008-07-26 17:56]: > > I have no idea. the FileChooser only job is to read the file to get the > > contents; I would expect to see a lot of read() operations. > > Yes, it gets only written, after the dialog is closed. > > > 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? > > -- > Guido Berhoerster > _______________________________________________ > gtk-list mailing list > [email protected] > http://mail.gnome.org/mailman/listinfo/gtk-list > -- ------------ Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.]
_______________________________________________ gtk-list mailing list [email protected] http://mail.gnome.org/mailman/listinfo/gtk-list
