I also agree that it has something to do with the inner workings of GTK+ in this case. ".local/share/recently-used.xbel" seems to feed the "Recent Documents" menu (and others) and it being written (over and over again) seems to be documented throughout the internet. Most of the times it is recommended to make it a directory to prevent its creation. But the problem in this case is that GTK+ writes its changes first to a temporary file and then tries to merge them into the main recently-used file. In my case it was so excessive because it had grown to 600kb+ and was written every second or so.
So much for the background. Yes, I agree that this is most likely due to that control. This discussion might be of interest to you: http://vim.1045645.n5.nabble.com/patch-GtkFileChooser-and-gvim-s-odd-use-of-gtk-main-td1210531.html it seems to describe that exact phenomenon and boils down to this bug report: https://bugs.launchpad.net/ubuntu/+source/vim/+bug/251122 and https://bugzilla.gnome.org/show_bug.cgi?id=546691 I'm not sure if that helps you. It seems to be mostly about the fact that gvim uses it's own main loop, and exits the GTK-Mainloop via gtk_main_quit() which leads to the recently-used file to be flushed to disk. Not sure how rep-gtk works and if something similar could be the case. Hope that helps, Bobby On Thu, 13 Sep 2012 22:03:06 +0200 Christopher Roy Bratusek <[email protected]> wrote: > After messing around with sawfish.wm.ext.wallpaper I suddenly got an > idea what causes this. I'm almost sure it is GTK+. SawfishConfig in > recent versions uses a new GTK+ widget for selecting files > GtkFileChooserButton rather than it's ancient and deprecated > predecessor. > > GtkFileChooserButton seems to use GIO to poll? > > Regards, > Chris -- Sawfish ML
