Re: [Sawfish] Re: High IO while config is open.

["Robert 'Bobby' Zenz" <Robert.Zenz@xxxxxxxxxxxxxx>]

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 <nano@xxxxxxxxxxxxx> 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