Created attachment 126902 [details] [review]
Patch which introduces an optional new environment variable GTK_RECENTLY_USED_FILE

(In reply to comment #0)
> It would be very useful if there was some way to prevent the selection of a
> file
> via normal usage of GtkFileChooser from writing to the above file.

the GtkFileChooser *never* writes the recently used file. *ever*. if it does, it's a local patch or a bug, because the FileChooser has no idea how to register a recently used file.

the FileChooser only *reads* the .recently-used.xbel file; if the file is not present, no write is ever attempted.

> Almost every
> GTK location is configurable via an environment variable and it seems odd that
> recently-used.xbel is hardcoded.

because it's part of a spec (desktop-bookmark-spec on XDG) and because it might change the location to be more fitting with the XDG base-dir specification. actually, by using the XDG_DATA_DIR environment variable you could update the location of the file without having a specific environment variable. the only thing missing is the migration plan (on read check if $HOME/.recently-used.xbel exists and save it to $XDG_DATA_HOME/recently-used.xbel when writing to it)

> My concrete problem is that I have automated tests of a GTK app that need to
> run in parallel. Now they fail intermittently as one of them will be removing
> and recreating the above file simultaneous to another one reading it. This
> problem did not exist with GTK 2.10.

that's because gtk+ >= 2.12 forces the update of the recently used file at the end of the outmost main loop to ensure that the file is in a consistent state; this is a separate issue.

Thanks for the prompt response.

I gather from your first and third comments that GtkFileChooser does not directly update that file, but creates some sort of pending update that is done when the program exits. From automated test usage the effect is basically the same : a global file is written whose location cannot easily be configured.

I didn't really follow your second comment. You refer to two different environment variables, XDG_DATA_DIR (DIRS?) and XDG_DATA_HOME, was this intentional? Are you suggesting you would accept a patch that read and wrote one of these and fell back to reading the old location if the new one didn't exist? Or would some spec need to change first?

I see there have already been discussions about the file location moving to XDG_DATA_HOME, incidentally
(http://mail.gnome.org/archives/gtk-devel-list/2006-August/msg00017.html)

(In reply to comment #3)
> Thanks for the prompt response.
> 
> I gather from your first and third comments that GtkFileChooser does not
> directly update that file, but creates some sort of pending update that is done
> when the program exits.

no, it's something that every gtk+ program does. once the main loop level reaches the outmost main loop, gtk+ saves the clipboard and makes sure that the recently used file is updated.

> From automated test usage the effect is basically the
> same : a global file is written whose location cannot easily be configured.

automated tests that are run serially don't have any problem with that - I know because the Perl bindings test suite does not have any problem with it. if you run your tests concurrently, you might have issues because GTK+ does not do any file locking, since there is no portable API to do that. this does not only pertain the recently used files: the configuration file where the FileChooser saves its state is also not locked, so if you change the configuration from different tests you'll get the same issues you have here.

as for the ease of configuration, by moving the recently used files storage file to the XDG_DATA_HOME you would be able to configure the location of the file -- and, incidentally, set up an environment for your test purposes.

> I didn't really follow your second comment. You refer to two different
> environment variables, XDG_DATA_DIR (DIRS?) and XDG_DATA_HOME, was this
> intentional? Are you suggesting you would accept a patch that read and wrote
> one of these and fell back to reading the old location if the new one didn't
> exist? Or would some spec need to change first?

you should look at the base-dir XDG specification for the meaning of those environment variables:

  http://www.freedesktop.org/wiki/Specifications/basedir-spec

> I see there have already been discussions about the file location moving to
> XDG_DATA_HOME, incidentally
> (http://mail.gnome.org/archives/gtk-devel-list/2006-August/msg00017.html)

yes, and theres a bug open about that: bug 524304

I don't have any problems with the FileChooser configuration file, because that lives in XDG_CONFIG_HOME which I set to a test-dependent location. 

You say that I would be able to configure the location and set up an environment for test purposes as if this is possible today. But there isn't any XDG_* variable I can set with the GTK+ code as it is today, right?

As I understand it this request is in fact essentially a duplicate of bug 524304... I suggest you mark it as such unless I'm missing something.

(In reply to comment #5)
> I don't have any problems with the FileChooser configuration file, because that
> lives in XDG_CONFIG_HOME which I set to a test-dependent location. 
> 
> You say that I would be able to configure the location and set up an
> environment for test purposes as if this is possible today. But there isn't any
> XDG_* variable I can set with the GTK+ code as it is today, right?

exactly.

> As I understand it this request is in fact essentially a duplicate of bug
> 524304... I suggest you mark it as such unless I'm missing something.

yup, done.



*** This bug has been marked as a duplicate of 524304 ***