On Sat, 2008-07-26 at 16:34 +0200, Guido Berhoerster wrote:
> > so, if you're seeing writes to that file you'll have to find the calls
> > to gtk_recent_manager_add_item() or gtk_recent_manager_add_full().
>
> $ grep gtk_recent vim71/src/*.c | wc -l
> 0
>
> There is no use of GtkRecentManager in the vim source.
>
> Yet using strace on vim reveals this
>
> [...]
> open("/home/gber/.recently-used.xbel.WBHYEU", O_RDWR|O_CREAT|O_EXCL, 0666) = 15
> fcntl(15, F_GETFL) = 0x8002 (flags O_RDWR|O_LARGEFILE)
> fstat(15, {st_mode=S_IFREG|0644, st_size=0, ...}) = 0
> mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fcbd288f000
> lseek(15, 0, SEEK_CUR) = 0
> write(15, "<?xml version=\"1.0\" encoding=\"UT"..., 218) = 218
> close(15) = 0
> munmap(0x7fcbd288f000, 4096) = 0
> rename("/home/gber/.recently-used.xbel.WBHYEU", "/home/gber/.recently-used.xbel") = 0
> stat("/home/gber/.recently-used.xbel", {st_mode=S_IFREG|0644, st_size=218, ...}) = 0
> [...]
>
> on every keypress, mouseclick etc.
I have no idea. the FileChooser only job is to read the file to get the
contents; I would expect to see a lot of read() operations.
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.
I wrote both the RecentManager and the FileChooser recently used files
list support, so I'm at loss here as much as you.
ciao,
Emmanuele.
--
Emmanuele Bassi,
W: http://www.emmanuelebassi.net
B: http://log.emmanuelebassi.net
_______________________________________________
gtk-list mailing list
gtk-list@xxxxxxxxx
http://mail.gnome.org/mailman/listinfo/gtk-list
