On Fri, Nov 13, 2009 at 10:39:29PM +0100, Bram Moolenaar wrote: > > > Tim Starling wrote: > > > GtkFileChooser is disabled in gvim, because gvim exits gtk_main() level > > 1 every time an event is received, causing GTK to write to the disk > > excessively. > > > > gtk_main() has always stored the clipboard on the same trigger, so it's > > fair to say that exiting gtk_main() constantly is not the way the GTK > > developers expected an application to work. People who know stuff about > > GTK agree: > > > > http://mail.gnome.org/archives/gtk-list/2008-July/msg00131.html > > > > My interest in this started when I discovered that GtkFileChooser had > > been disabled. I missed it: > > > > https://bugs.launchpad.net/ubuntu/+source/vim/+bug/365860 > > > > It's been 7 months now since that plaintive cry, so I gave up waiting > > and wrote a patch. This is my first GTK project but it looks pretty > > straightforward. I read the source code for gtk_main() and some other > > things. > > > > Emmanuele Bassi's advice was to create a separate GMainLoop: > > > > http://mail.gnome.org/archives/gtk-list/2008-July/msg00146.html > > > > That turns out to be unnecessary, since all GMainLoop does is calls > > g_main_context_iteration() repeatedly, until it's time to exit. The > > actual task of registering event sources and calling select() is done by > > GMainContext, which exists whether or not a GMainLoop has been created. > > Thus by calling g_main_context_iteration() at the relevant places, vim > > can leave main_loop() unmodified. > > > > My patch does this, and removes all calls to gtk_main_quit() except the > > ones in modal dialogs. Modal dialogs are now implemented by calling > > gtk_main() once only, and allowing the button handlers to call > > gtk_main_quit(), just like in a regular GTK application. > > > > We don't seem to be missing anything substantial by never calling > > gtk_main(). You can register callbacks to be called when gtk_main() > > exits, but luckily vim isn't doing that or else they'd be called on the > > first keypress and then never again. Of course we miss out on that final > > sync of recently-used.xbel, but it seems that it's already synced every > > time it's changed, via the "changed" signal (see > > gtk_recent_manager_changed() and its callers in gtk/gtkrecentmanager.c). > > > > I haven't done cross-version tests on this patch, but > > g_main_context_iteration() exists back to at least GLib 1.3.9 (September > > 2001). > > > > Attached and online at: > > http://tstarling.com/stuff/fix-gtk-main.patch > > I'm very glad to see someone is picking up a GTK problem. Hardly any > work was done on GTK for a long time. > > I would appreciate it if a few people try this out and report any > problems they notice.
The bug Tim fixed was something I had been planning on taking a look at, so I'll definitely try out the patch soon and report back. Thanks for the patch, Tim! -- James GPG Key: 1024D/61326D40 2003-09-02 James Vega <james...@debian.org>
signature.asc
Description: Digital signature
