Re: Issue with vim and GtkFileChooser
Hello, is there any workaround to prevent GTK from saving the recently used files list on leaving the GTK main loop? Or is there a possibility to disable this functionality on a per-application basis (I've learned that it will be possible to do so globally with GTK 2.14)? Thanks, -- Guido Berhoerster ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
On Tue, 2008-07-29 at 17:37 +0200, Guido Berhoerster wrote: Hello, is there any workaround to prevent GTK from saving the recently used files list on leaving the GTK main loop? Or is there a possibility to disable this functionality on a per-application basis (I've learned that it will be possible to do so globally with GTK 2.14)? you are trying to get around gtk+ to abuse it - I wouldn't expect gtk+ to accomodate the use coming from an application that's clearly abusing how gtk+ works. the GTK+ 2.x GUI for vim should really create a GMainLoop source that's spinning the low-level main loop - or go the other way around, and spin the main loop from within the low-level main loop, it's not really important - instead of starting/spinning/stopping the main loop inside the event handling code. as I said, that is abusing how gtk+ is supposed to work. there is a reason why gtk+ saves the recently used file and the clipboard when the main loop level reaches zero: leaving the application data in a consistent state. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
On Sat, 2008-07-26 at 23:35 +0200, Guido Berhoerster wrote: 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. Thanks for the explanation, I'm not sure if I got it right, in the eventhandlers there is often code like: [...] if (gtk_main_level() 0) gtk_main_quit(); [...] If gtk_main_level() returns 1 and gtk_main_quit() is called, does that mean that the recently used files list gets written? yes, if the main loop level is 1 and main_quit() is called, the main loop level reaches 0 and 1. the clipboard is saved 2. the recently used files list is saved - the rationale being: usually a main loop level of 0 means that the application is quitting. is gvim really calling gtk_main_quit() at each button/key press or motion event? in which case gvim is completely bonkers. why is it doing that? is there another main loop running? why can't gvim use the GLib main loop to spin the other main loop? the GLib main loop is pretty extensible - even QT supports the GLib main loop by default. as it is, gvim is pretty much abusing gtk+. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
* Milosz Derezynski [EMAIL PROTECTED] [2008-07-27 01:39]: That does indeed mean it; it's what Emmanuele supposed and it turns out to be right. It's rather strange for a gtk+ app to do this, is there some kind of other non-glib-based main loop running? The main vim engine. It's not a native GTK application, the GTK2 UI is just an exchangable GUI layer, it also has Athena, Motif, and GTK1 UIs. And you can do facy stuff like switching from the terminal to the X UI while running. -- Guido Berhoerster ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
* Emmanuele Bassi [EMAIL PROTECTED] [2008-07-27 11:06]: yes, if the main loop level is 1 and main_quit() is called, the main loop level reaches 0 and 1. the clipboard is saved 2. the recently used files list is saved - the rationale being: usually a main loop level of 0 means that the application is quitting. Thanks for the clarification. is gvim really calling gtk_main_quit() at each button/key press or motion event? in which case gvim is completely bonkers. why is it doing Yes, it's all over the place in the event handlers in http://vim.svn.sourceforge.net/viewvc/vim/vim7/src/gui_gtk_x11.c?view=markup that? is there another main loop running? why can't gvim use the GLib main loop to spin the other main loop? the GLib main loop is pretty extensible - even QT supports the GLib main loop by default. as it is, gvim is pretty much abusing gtk+. Well, I cannot really answer this, but as I wrote in the other mail, vim is not a native GTK2 application. It has several optional and interchangable GUIs such as GTK1, GTK2, Athena or Motif. Its core does not use GLib. I've already gotten back to Bram with this. -- Guido Berhoerster ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Issue with vim and GtkFileChooser
Hello, I'm trying to debug an issue with the GTK2 version of vim which has bothered me for a long time. After the first invocation of GtkFileChooser in vim, GTK's list of recently used files (~/.recently-used.xbel) gets written on events such as every single keypress, mouseclick or the mouse entering/leaving the window. This bug occurs with vim (at least) 7.0 and 7.1 built against GTK 2.10 (at least) on Linux. I assume that this is a bug in GTK, from what I can see it uses GtkFileChooser as in the reference manual and does not use GTK's recently used files list functionality directly. However I saw that the recently used files functionality was added to the GtkFileChooser in GTK 2.11. I've spoken with Bram Moolenaar about this and he also believes this to be a bug in GTK. This is as far as I can get with my knowledge, could someone with more insight on the inner workings of GTK comment on what might be going on here? If needed the relevant parts of the GTK UI are in http://vim.svn.sourceforge.net/viewvc/vim/vim7/src/gui_gtk.c?view=markup -- Guido Berhoerster ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
On Sat, 2008-07-26 at 13:45 +0200, Guido Berhoerster wrote: Hello, I'm trying to debug an issue with the GTK2 version of vim which has bothered me for a long time. After the first invocation of GtkFileChooser in vim, GTK's list of recently used files (~/.recently-used.xbel) gets written on events such as every single keypress, mouseclick or the mouse entering/leaving the window. This bug occurs with vim (at least) 7.0 and 7.1 built against GTK 2.10 (at least) on Linux. I assume that this is a bug in GTK, no, it's not. the list of recently used files is not written by the file selector widget: it's entirely up to the application to do that, by calling the GtkRecentManager API. from what I can see it uses GtkFileChooser as in the reference manual and does not use GTK's recently used files list functionality directly. However I saw that the recently used files functionality was added to the GtkFileChooser in GTK 2.11. yes, but the FileChooser widget *reads* that file to generate the recently used file list. 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(). This is as far as I can get with my knowledge, could someone with more insight on the inner workings of GTK comment on what might be going on here? If needed the relevant parts of the GTK UI are in http://vim.svn.sourceforge.net/viewvc/vim/vim7/src/gui_gtk.c?view=markup I don't see any call to GtkRecentManager. ciao, Emmanuele. -- Emmanuele Bassi, W: http://www.emmanuelebassi.net B: http://log.emmanuelebassi.net ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
* Emmanuele Bassi [EMAIL PROTECTED] [2008-07-26 15:16]:
the list of recently used files is not written by the file selector
widget: it's entirely up to the application to do that, by calling the
GtkRecentManager API.
from what I can see it uses GtkFileChooser as in the
reference manual and does not use GTK's recently used files list
functionality directly. However I saw that the recently used
files functionality was added to the GtkFileChooser in GTK 2.11.
yes, but the FileChooser widget *reads* that file to generate the
recently used file list.
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.
This is as far as I can get with my knowledge, could someone with
more insight on the inner workings of GTK comment on what might
be going on here? If needed the relevant parts of the GTK UI are
in
http://vim.svn.sourceforge.net/viewvc/vim/vim7/src/gui_gtk.c?view=markup
I don't see any call to GtkRecentManager.
Me neither, so what is happening here?
--
Guido Berhoerster
___
gtk-list mailing list
gtk-list@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
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@gnome.org
http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
* Emmanuele Bassi [EMAIL PROTECTED] [2008-07-26 17:56]: 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. Yes, it gets only written, after the dialog is closed. 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. Thanks for the explanation, I'm not sure if I got it right, in the eventhandlers there is often code like: [...] if (gtk_main_level() 0) gtk_main_quit(); [...] If gtk_main_level() returns 1 and gtk_main_quit() is called, does that mean that the recently used files list gets written? -- Guido Berhoerster ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
That does indeed mean it; it's what Emmanuele supposed and it turns out to be right. It's rather strange for a gtk+ app to do this, is there some kind of other non-glib-based main loop running? 2008/7/26 Guido Berhoerster [EMAIL PROTECTED] * Emmanuele Bassi [EMAIL PROTECTED] [2008-07-26 17:56]: 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. Yes, it gets only written, after the dialog is closed. 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. Thanks for the explanation, I'm not sure if I got it right, in the eventhandlers there is often code like: [...] if (gtk_main_level() 0) gtk_main_quit(); [...] If gtk_main_level() returns 1 and gtk_main_quit() is called, does that mean that the recently used files list gets written? -- Guido Berhoerster ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
Re: Issue with vim and GtkFileChooser
Oh yeah, 1:0 for Occam ;) 2008/7/27 Milosz Derezynski [EMAIL PROTECTED] That does indeed mean it; it's what Emmanuele supposed and it turns out to be right. It's rather strange for a gtk+ app to do this, is there some kind of other non-glib-based main loop running? 2008/7/26 Guido Berhoerster [EMAIL PROTECTED] * Emmanuele Bassi [EMAIL PROTECTED] [2008-07-26 17:56]: 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. Yes, it gets only written, after the dialog is closed. 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. Thanks for the explanation, I'm not sure if I got it right, in the eventhandlers there is often code like: [...] if (gtk_main_level() 0) gtk_main_quit(); [...] If gtk_main_level() returns 1 and gtk_main_quit() is called, does that mean that the recently used files list gets written? -- Guido Berhoerster ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] -- Please note that according to the German law on data retention, information on every electronic information exchange with me is retained for a period of six months. [Bitte beachten Sie, dass dem Gesetz zur Vorratsdatenspeicherung zufolge jeder elektronische Kontakt mit mir sechs Monate lang gespeichert wird.] ___ gtk-list mailing list gtk-list@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-list
