Re: Issue with vim and GtkFileChooser

[Emmanuele Bassi <ebassi gmail com>]

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