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. -- I used to wonder about the meaning of life. But I looked it up in the dictionary under "L" and there it was - the meaning of life. It was less than I expected. - Dogbert /// Bram Moolenaar -- b...@moolenaar.net -- http://www.Moolenaar.net \\\ /// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\ \\\ download, build and distribute -- http://www.A-A-P.org /// \\\ help me help AIDS victims -- http://ICCF-Holland.org /// --~--~---------~--~----~------------~-------~--~----~ You received this message from the "vim_dev" maillist. For more information, visit http://www.vim.org/maillist.php -~----------~----~----~----~------~----~------~--~---
