The rationale for this is explained here:

http://live.gnome.org/DocumentCentricGnome/Help%20the%20user%20choose%20a%20place%20to%20put%20a%20new%20file

The live.gnome.org wiki is down at the moment, but you can see an explanation here as well:

http://people.gnome.org/~federico/news-2011-07.html#01

That discussion is for Save mode.  For Open mode, the rationale is that you want to help with the user's workflow:  he may save a file in one application, and then need to use that file again in another app - thus we show the recently-used list, to make the file easy to find.

(In reply to comment #1)
> The rationale for this is explained here:
> 
> http://live.gnome.org/DocumentCentricGnome/Help%20the%20user%20choose%20a%20place%20to%20put%20a%20new%20file
> 
> The live.gnome.org wiki is down at the moment, but you can see an explanation
> here as well:
> 
> http://people.gnome.org/~federico/news-2011-07.html#01
> 
> That discussion is for Save mode.  For Open mode, the rationale is that you

Yes, it makes sense for Save, you don't use that many folders.

> want to help with the user's workflow:  he may save a file in one application,
> and then need to use that file again in another app - thus we show the

Except that app is not GTK so it does not help me there, and when I open something in a GTK app it presents me with a list of files I am done with already.

> recently-used list, to make the file easy to find.

It makes them harder to find for me.

~/.local/share/recently-used.xbel is a freedesktop.org standard, so that app should in principle use it.

Oh, xbel. At least Mozilla could use that, it seems they started it.

Anyway, with the 2.24.6 patched so that filechooser works again it's not so bad.

BTW, I started a patch for Mozilla to make it log downloaded files in GtkRecentManager: https://bugzilla.mozilla.org/show_bug.cgi?id=670275

It's not finished yet... help is appreciated :)

It would be much more useful for Mozilla to use the recent documents GTK saves when opening a file (such as for sending it in a form or viewing it as a web page). For me at least. Mozilla is quite capable of opening the downloaded files by itself so it should not clutter my recent documents with downloads.

Anyway, typing in a location (or pasting for that matter) is very difficult.

The location bar is pretty much inaccessible when the default is to show recent documents. 

You need to know that there is an obscure button for this purpose and hit it with your mouse or know that selecting your home directory opens the location entry. 

This is quite non-obvious and quite awkward if you are going to type - which you are because by the time you get to an entry GTK would most likely wipe the X selection that can be pasted by mouse.

*** Bug 665297 has been marked as a duplicate of this bug. ***

See, it's a problem.

Opening files is very difficult because it's hard to get to the location bar where you enter which file  you want to open and saving is very difficult because you can't just save, you have to pick a directory first.

For GTK only desktop the recent files might be useful but it's definitely a barrier for people using applications based on how well they do the job, possibly on multiple systems with different ~ rather than on them using the same toolkit.

Recent save folders get in my way all the time.

Maybe a nice idea which helps some people but it should definitely be possible to have file dialog that does not get in the way of choosing files.

btw if you are for making things easy for the users then 

1) make it possible to present whatevet the user prefers - location bar, a particular bookmark (eg. ~), recent files or folders, ..

2) make it configurable *persistently* from the dialog itself

I can see that for the novice computer user it _might_ be helpful to display the Recently Used list. 

But for anyone else that folder is not very useful. 

Use case:

Open several files from directories named 'lib'. Create a new file and go to save it in one of the lib directories. Unless you've saved files in the one you want it's not in the recently used list, and even if it is you have to go down the list looking at the tooltips to see which one you want. 

This sort of thing happens all the time and seriously disrupts my workflow.

Why isn't this behaviour configurable? There's even a configuration file already, albeit with a starnge name (filechooser.ini) though it's totally undocumented.

*** Bug 665919 has been marked as a duplicate of this bug. ***

Just take a look at KDE's save dialogue. There you will see all the missing thing's of GtkFileChooser. Where are the settings? 

If the Gnome developers like to move the novice Gnome user in to a direction, they can do it. But there are many no Gnome users, how do depend on the GTK novice settings for Gnome as well. The "workflow" of none Gnome user do not flow the Gnome-workflow at all. May zeitgeist doesn't work for them at all. 

If there would be a setting to get the "old" behaver of GtkFileChooser, it would be possible to fix this discrepance.

For a long time, the file chooser would show $cwd from the application if no folder was explicitly set.  Since most of the time that folder is $HOME (as applications are normally launched from the menus), that $cwd = $HOME is not very useful.

Then, I made the file chooser remember the last folder used and use it for the next invocation (again, only if no folder is set explicitly).

Then, I switched the file chooser to start in recently-used mode in the scenario above.

The commit that changed this is 252ace66 - and the part that changed *this* in particular is this patch in gtk+/gtk/gtkfilechooserdefault.c:

@@ -5687,17 +5693,10 @@ gtk_file_chooser_default_map (GtkWidget *widget)
 
   if (impl->operation_mode == OPERATION_MODE_BROWSE)
     {
-      GFile *folder;
-
       switch (impl->reload_state)
         {
         case RELOAD_EMPTY:
-          /* The user didn't explicitly give us a folder to display, so we'll
-           * use the saved one from the last invocation of the file chooser
-           */
-         folder = get_file_for_last_folder_opened (impl);
-          gtk_file_chooser_set_current_folder_file (GTK_FILE_CHOOSER (impl), folder, NULL);
-         g_object_unref (folder);
+         recent_shortcut_handler (impl);
           break;
         
         case RELOAD_HAS_FOLDER:

Can you try "unapplying" that patch (even by hand) and seeing if you like the behavior?  If that seems comfortable, we can have a hidden option that you can set to make the file chooser start up in recently-used mode vs. "use the last folder" mode.

No more hidden options, please.

Make the options visible, thanks.

tldr; me too :)

Making this a default is going to cause some pain for many applications, those  which will be getting bug reports and having to find where they should've set a default folder manually, even though it doesn't seem to be documented that they should do this (going by the unstable API docs on gnome.org last time I checked).  This is also going to cause a lot of applications to use weird defaults rather than some standard one; some will set it to $HOME, maybe some $HOME/Documents, and lots I'm sure will leave the new default Recent "view".

Just as an example, consider a cross-platform/desktop application that opens a wide array of a general type of file, and can even open ones it might not know about and just might not filter to be able to show all file types.  The changes make it, by default, show a specific view of files which may have no relevance to the application and many of which aren't even able to be opened, and additionally may all have the exact same basename, causing the user to move with their mouse and hover the tooltip to see the full path.  This seems non-intuitive and highly confusing (at least to me). 

In one program I went to open a file and `/usr/bin/firefox` (actually just the word `firefox` since it's just the basename) showed up in the list.  It's probably going to confuse the heck out of regular users who have no idea that that's a binary file containing executable program code to be opened in the current application rather than meaning "open a new instance of firefox" or something. It's also kind of weird to remove the Location box causing the whole UI of the dialog to look different depending on which thing is chosen in the sidebar.

I don't think there's a solution you could possibly come up with to solve this "problem" - of user's not caring enough to understand files - in a generic enough way to fit into GTK+.  The only really sane default is to show the users where all their files are ($HOME) or maybe to save the last directory that was opened in that *specific* application.

I do think it's interesting to have the recent files view, but not by default.  Maybe there could be a new function called `gtk_file_chooser(_dialog)_new_with_recent()` that can possibly take an application-specific context object, which if NULL would use the system-wide/global recent files or something like this.

Just my two cents.

I will second the default of $HOME.

I, like many people, like to watch pornography on my computer. Lots of pornography. Pornography that pushes the boundaries of what is physically, morally, and socially acceptable. Contemptuous, despicable, regrettable pornography.

I think it would be great if the GtkFileChooser did not try to announce this fact to everyone who uses my computer to save a spreadsheet.

Thanks!

Why can't we just make it configurable ?
By default use the "recent file". If the user don't want it, use the user's folder, or $HOME, or whatever folder. 
Thanks

(In reply to comment #5)
> BTW, I started a patch for Mozilla to make it log downloaded files in
> GtkRecentManager: https://bugzilla.mozilla.org/show_bug.cgi?id=670275
> 
> It's not finished yet... help is appreciated :)

Federico,

Looking at that one right now. I'll see if I can get the reworked version reviewed to commit it.

Maybe it is possible to switch to the last folder opened if no recent items are found (possible better anyway). If people don't like the file choosers' recent-items default, they can set gtk-recent-files-limit=0

If Gnome does not feel comfortable with the switching if no items are found because this might feel inconsistent, the default can also watch gtk-recent-files-limit like this in gtk_file_chooser_default_map:

case RELOAD_EMPTY:
  if (get_recent_files_limit (widget) == 0)
    {
      /* user disabled recent file, switch to the last used folder */
      folder = get_file_for_last_folder_opened (impl);
      gtk_file_chooser_set_current_folder_file (GTK_FILE_CHOOSER (impl),
folder, NULL);
      g_object_unref (folder);
    }
  else
    {
      recent_shortcut_handler (impl);
    }
  break;

IMHO this is a fix that does not break the current behavior and gives people who don't care about recent items an option to disable this all together.

*** Bug 674600 has been marked as a duplicate of this bug. ***

The behavior of defaulting to a list of recently-used folders to save into is a complete workflow breakage. It's very common that when using Evolution I need to save attachments from several different emails into a common folder. Being forced to re-navigate the save dialog every time is unacceptable. The old behavior of having the save dialog open to the last folder I saved into was much preferable.

The recently used magic folder should be available as an option I can take advantage of, but you should not be interrupting my workflow.

The above posted coed is not really useful. I don't like to fix Gnome, because I don't use it! I don't care about the Gnome-workflow at all. But I depend on GTK in Firefox or GIMP.

Just take a look at KDE's save dialogue. There you will see all the missing
thing's of GtkFileChooser. Where are all the settings? 

If there would be a general setting (not hidden!) to get the "old" behaver of GtkFileChooser, it would work for Gnome-users and others.

What's the matter with settings and Gnome about? Just a small piece more pragmatism would be really wonderful.

Please, make it default to $PWD (or at least $HOME) somehow.

(In reply to comment #12)
> For a long time, the file chooser would show $cwd from the application if no
> folder was explicitly set.  Since most of the time that folder is $HOME (as
> applications are normally launched from the menus),

This is where the rationale start to diverge from the reality.

My applications are practically *NEVER* launched from menus.  They are launched from the terminal and always have a meaningful cwd.

I understand that there is a number WIMP users that lanuch everything using icons and menus.  But that should not be a reason to frustrate everyone else.  Just showing cwd initially if cwd != $HOME would fix 99.9% of the problem immediately (serious work is rarely done directly in $HOME).

(In reply to comment #21)
> Just take a look at KDE's save dialogue. There you will see all the missing
> thing's of GtkFileChooser. Where are all the settings? 

I don't use KDE, but I think you can even rename files in KDE's save dialog, same under MS Windows, a long click on the file name permits to rename it, very useful if you want to save "test.file" but you already have it in the destination folder, then you can rename "test.file" to "test.file.old" from the save dialog and save your new file to "test.file". The File/Folder popup menu permits to do any file operation in the file list.

Windows 98 was able to do this :
http://pix.toile-libre.org/upload/original/1335360006.png
http://pix.toile-libre.org/upload/original/1335360044.png

Even creating a new file/folder from the Save As dialog :
http://pix.toile-libre.org/upload/original/1335360075.png

In Gtk Desktops of 2012, you're not very lucky... you can only show hidden files... or hide size column... nothing very exciting...
http://pix.toile-libre.org/upload/original/1335360185.png

:)

Well, perhaps the recent changes in gtk filechooser are intended to push developers into rolling their own filechoosers.

Unfortunately, all existing applications written in the times when GTK filechooser was somewhat usable will have to be updated to not rely on it anymore.

GtkFileChooser is really an example of very pure development. (Win89 was it to.) But I don't need to rename or create files. (Yes it work in kde!) 

I just cant use the recent documents at all. Before the changes in GtkFileChooser the
last folder was opened. I just would like to get this behaviour back. 

The developers may think, the current solution is more useful in the Gnome-workflow. No problem, if there would be a general setting in the GtkFileChooser-window to change its behaviour.

Please stick to the recent documents behaviour please. One bugreport per issue/request. Your comments are actually read :P

I think the problem here is that everyone has a different idea of what the default behavior should be. The only thing we all seem to be able to agree on is that the current behavior is wrong.

Is it really so difficult to add a configuration option somewhere that allows us to select from:

* Default to the recently used folder
* Default to the CWD
* Default to $HOME
* Default to the last directory that was used by the file browser

For the record, the last on that list is the old behavior which I always considered to be highly advantageous and would like to see restored. The current behavior (the first option) is unusable in any workflow I can perceive.

AFAIK this even depends on the current workflow. Consider:

 1) if I'm working with the console in a particular directory and then open some program (let's say word processor) and I want to change the file and save (e.g.) it using another format I would expect the filechooser to open in that directory.

 2) if I have some larger number of documents of which I need each to open in a particular application (which I run from menus) and those documents reside in a particular directory → I want the filechoosser to open in the lastly used directory (depending on the particular workflow - when saving the data one should use either the same or another directory as when loading the document!)

 3) if I open in the morning my text-editor I'd like to choose one of the recetnly opened (i.e. yesterday) files ;-)

So I think that all possibilities should be available to the user since even a single user chooses to use different workflows for different tasks. It would be best if there was some additional element (e.g. drop-down menu) where one could choose which workflow will be followed. (The workflow would, of course, remain consistent among multiple instances of the application...)

Adding yet another opinion to the long list.

Generally, I'm patient with behavioural changes in a system, because I consider there are many people who are more intelligent and practical than I am.

The 'Recently used' "feature" is one exception. I have never found a single occasion where I found that 'Recently used' was useful when saving work. Not with images, docs,  or any other program. In fact, in many cases it just gets annoyingly in the way (probably because some programs don't set the path on repeated calls to Filechooser).

On 'Open', only sporadically do I get suggestions which are appropiate. I'm not sure how the 'Recently used' system works internally, or maybe I just use to many different programs regularly...

Anyway, I'd rather have 'last used directory' (which seems to make up for programs not initializing the path). 

Maybe a better solution: remember a last used directory for each executable?

(In reply to comment #30)

> Anyway, I'd rather have 'last used directory' (which seems to make up for
> programs not initializing the path). 
> 
> Maybe a better solution: remember a last used directory for each executable?

Personally I would take that approach as a default.

If I want to open a recent document, I click File -> Recent files -> filename (or just File -> filename, depending on program).

When I bother opening the Open dialog, I do not want to open a recent document - I want to open something unrelated, and I normally type the path to that file - or at least I would, if the dialog let me do that. Instead, I first have to Shift+Tab twice, press down before I can even start entering the path/filename, because the GTK+ developers really really hate the filename entry textbox, and are always looking for new ways to keep it hidden.

For me I most often want "recently used folders", e.g. to save a new file alongside another one, or to open something I was working on in another application.

Recent files lets me overwrite documents I've recently opened or saved, but does not help me to save as a new file with a different name in the same folder as a previous document.

The case where you open a file in one folder, process it, save it in another, and then repeat, would be greatly facilitated, and I think this not so unusual a workflow.

*** Bug 680248 has been marked as a duplicate of this bug. ***

I'll transcribe that here for clarity...

Bug 680248 - Regression in [evolution] 'save as mbox' usability

In Evolution 3.2 I could hit Ctrl-S, type a filename (to which '.mbox' was
appended automatically), and hit 'enter' to save it.

Now, that no longer works. When I hit 'enter', it simply says 'select a folder
below'. And it doesn't *remember* the folder I select, when I save the next
file.

I don't even understand the navigation of this dialog box. I don't seem to be
able to *get* to the bit where I choose a folder, by using the tab key as I
normally would. I seem to have to use the down cursor key to select one of the
existing 'Recently Used' files, then the left cursor key to move to the list of
directories. Keyboard navigation seems entirely broken here, so I have to use
the mouse.

So... I've hit Ctrl-S, I enter the filename, hit enter, see the 'you have to
select a directory because I hate you and refuse to remember the one you chose
last time' warning, swear, use the mouse to select a directory, hit 'enter'
again.... AND THE F$CKING THING STILL FAILS TO SAVE!. Apparently I have to use
the mouse to select the text box into which I typed the filename, because
otherwise it ignores what I've typed.

----

If this dialog box is just going to get progressively more unusable, Evolution needs to stop using it.

(In reply to comment #35)
> If this dialog box is just going to get progressively more unusable, Evolution
> needs to stop using it.

https://mail.gnome.org/archives/evolution-hackers/2012-July/msg00000.html

Presumably you can back out the recent changes to make the dialog usable at least on RedHat/Fedora.

Expect an inrush of new users then :>

Alternatively the dialog can be made more usable or an extra gtk extension that implements an usable file open dialog could be written.

As for making the dialog usable - it has way too many options already, and needs some way to choose which are the deafults.

For this I would suggest 'pin' interface - all the parts that can be shown/hidden would have a pin hole in a corner or somewhere which when clicked would 'pin' the element to be shown by default, and clicking a pin would make the part hidden by default. This can be extended to bookmarks - both the ususal bookmarks that specify a particular folder as well as these 'meta' bookmarks that specify 'recently used' or 'last used'. Bookmark pinning should be separate for open and save because these work differently wrt the 'meta' bookamrks.

As for making an extra component I guess this is quite a bit of work given the amount of stuff the current file dialog has:

- entry field with completion
- filesystem browser
- preview pane
- bookmarks
- recently used history

However, not all needs to exist to make a usable file open dialog. Actually, the inability to hide bookmarks harms usability of the dialog in some use cases.
Also the interaction between all these components is quite intricate and buggy so leaving out some might lead to a more useful dialog and file chooser that can be actually embedded in orther windows without breaking them.

GtkFileChooser is a pain since years now. There are all ready some GTK based projects how did write their own file dialogue. Sad, sad...

Many other desktop environments/tool kits offers a much more user-friendly file dialogue. This is true for TCL/TK, JFileChooser, KDE, Aqua, Windows.... (The only worse i knew is the file dialogue of Open-/LibreOffice) Pleas look around, other did successful join easiness and many functions. 

And pleas remember, not all users how depend on the GtkFileChooser are Gnome-user. Not every body works in the Gome-Workflow.

If there is no progress in flexibly, I'll ask may other projects to write their own file open dialogue. The pain rises with each new change...

All the missing functions are above discussed all ready.

Is there any way to completely disable ‘Recently Used’ in the GtkFileChooser dialog box? I use KDE and I  tried setting 
'gtk-recent-files-max-age=0' 
in
/home/user/.config/gtk-3.0/settings.ini
and in 
/home/user/.kde/share/config/gtkrc-3.0
/home/user/.kde/share/config/gtkrc-2.0

but it doesn't work.

I previously commented on bug 667252, which looks like another duplicate of this. +1 to the requests for a configurable option for the default, and +1 to having the last directory used as one of the options.  I think it would be nice if it were a visible option rather than a secret dconf ritual to appease power users, but since I plan to change it exactly once I don't personally mind.

This may be getting too ambitious, but it would be really awesome if there were an option for the location to be set to the output of a custom command.  Then power users could tailor this behaviour as precisely and elaborately as they wanted using their own bash scripts, and everyone would be happy, for ever.

I have never opened a file from the recently-used files list, among other reasons because it's impossible for me to guess the actual contents of a file only from its base name.  I tend to remember where files are, not what their names are, so to me a list of file names is practically meaningless.

Please, at least provide an option to change the default. In the meantime, here's a temporary fix: http://confluence.za.net/blog/?p=293

I'm afraid my temporary fix doesn't work -- the custom file gets overwritten by apps.  It's possible that setting the owner to root will help.

It's possible to set a file as immutable (not by mode but by attribute). Setting owner to root definitely does not prevent the usual way files are updated:

old file is read

new temporary file written

temporary renamed to old

(In reply to comment #41)
> Please, at least provide an option to change the default. In the meantime,
> here's a temporary fix: http://confluence.za.net/blog/?p=293

Inspired by this blog post, I chmodded 0 the recently-used.xbel file, resulting in empty list in filechooser (and a g_warning). Can we agree on not showing empty 'Recently Used' pane and offer user something more useful in this case?

Sorry but the rationale for this "feature" is entirely wrong. It causes far more problems than it theoretically should solve.

At the very least, this should be configurable. It is leading developers to stop using the GTK+ dialog, resulting in a different look and feel for each application.

Please reverse this decision. It was a bad mistake.

*** Bug 684964 has been marked as a duplicate of this bug. ***

I know I preferred the GTK2 approach - and certainly preferred $HOME to Recently Used as the default. In fact, I never used "Recently Used" before this unwanted change in behaviour!

Even if it were just some obscure option in dconf-editor, I really think this needs to be configurable in some way that doesn't require the user to sacrifice Places -> Recent Documents.

"don't let the user confirm the Save action until she has picked a folder". I understand the motivation but the solution disturbs the work process of users that use the home folder as a basis for orientation in the filesystem.

I suggest that the file chooser should be easily configurable to have a different default location. I attack a mockup of how that default would be visualized (bold font) and how it could be configured (right click on bookmark bar location, "set default").

This would require to use recent files as a fallback in case the default location is not available (if, for example, an unmounted flash drive was set as the default location)

The visualization of the default location could be completely different, for example by having the characters " (default place)" behind the name of the default place or by having an additional icon placed next to or above the default location's icon.

Created attachment 227210 [details]
Mockup: setting the default location in the file chooser

> Mockup: setting the default location in the file chooser

Adding another $.02:

One option - which seems practical to me - is not available in the
bookmark bar: The working directory. I frequently work in different
'modes', and, as such don't have one default location.

What I'd like, could maybe be implemented as an extra 'location'
in the left column, which represents the current working directory.

So, if today I'm programming in one of my python projects, and
start a file dialog, I'd generally like it to be in the current
project directory. If tomorrow I want to work on a C++ project,
I would not want it to start in a Python project (which I understand
would happen with the 'set as default' method, wouldn't it?)

John

*** Bug 667252 has been marked as a duplicate of this bug. ***

(In reply to comment #48)

> I suggest that the file chooser should be easily configurable to have a
> different default location. I attack a mockup of how that default would be
> visualized (bold font) and how it could be configured (right click on bookmark
> bar location, "set default").

Hey, that's an interesting approach.

Writing a patch to do that should be simple.  The key point is to modify gtk_file_chooser_default_map() to use the saved default folder when it hits the RELOAD_EMPTY case.

Created attachment 229178 [details] [review]
filechooser-default-folder.diff

Attached is a patch-in-progress to do the following.

This lets you select whether you want the file chooser to behave in one of three ways:

1. The original behavior; a file chooser without a pre-set folder will start up in $CWD.

2. A behavior that was in the master branch for a little while, but sadly it didn't make it into a stable release.  The file chooser remembers the last folder you used, and will use it again the next time.  This is shared across applications (and of course only happens without a pre-set folder).

3. The curent behavior; without a pre-set folder, the file chooser will appear in recently-used mode.

To change the preference, you tweak ~/.config/gtk-2.0/gtkfilechooser.ini to have this:

[Filechooser Settings]
DefaultFolder=XXXX

where XXXX is "cwd", "last", or "recent".

I'm really interested to know if this kind of patch makes things better for groups of people who like either behavior.

*** Bug 687247 has been marked as a duplicate of this bug. ***

*** Bug 676636 has been marked as a duplicate of this bug. ***

*** Bug 670875 has been marked as a duplicate of this bug. ***

Great! What is your paypal address?

This 'feature' structurally introduces extra steps to my user experience that
aren't otherwise necessary, and could therefor be described as contrary to
nature, reason, or common sense. So I don't understand the rationale.

Also, we usually press Ctrl+L (location) to enter a different path manually, but in "Recent mode" Ctrl+L doesn't work, turning something that should be simple into a tab-party or forcing you to use the mouse.

+1 to patch proposal. If this will provide an option to restore the previous behaviour, I'm happy.

Created attachment 229198 [details]
GtkFileChooser sows to folders with the same name. Which one is the rigth oune? 

GtkFileChooser should really offer options to pre-set its default location. The recent-files are really useless. 

(Gimp-File dielaog, running on Fedora 16 in KDE 4.8.5)

Created attachment 229200 [details]
A god example of a file dialog! May KDE does inspire the GTK/GOME developers. 

In KDE there is a menu for settings. If the would be an similar menu in GtkFileChooser to per-set the behaver, bug Bug 658280 would be fixed. The options could be:
1) "open last folder open in this dialog"
2) "Users Home"
3) "Recent files" (Zeitgeist)
4) ...

Is it really impossible to add options to pre-set the behavier of GtkFileChooser?

KDE does ofer a settings menu to its file dialog. (Attachment #229198 [details]) If there would be an similar menu in GtkFileChooser, everbody could per-set heis favrite behaver. Bug 658280 would be fixed. The options could be:

1) "open the last folder opende in this dialog"
2) "Users Home"
3) "Recent files" (Zeitgeist)
4) ...

And, pleas, no hidden opetions. 

And, no, I don't like to add any code to my GTK/Gome installtion. I (and many others) need theis options out of the box. 

Redsandro wrote: 
> Also, we usually press Ctrl+L (location) to enter a different 
> path manually, but in "Recent mode" Ctrl+L doesn't work, turning something 
> that should be simple into a tab-party or forcing you to use the mouse.

Ctrl-L does not work at all on Fedora 16...

(In reply to comment #53)

> To change the preference, you tweak ~/.config/gtk-2.0/gtkfilechooser.ini to
> have this:
> 
> [Filechooser Settings]
> DefaultFolder=XXXX
> 
> where XXXX is "cwd", "last", or "recent".
> 
> I'm really interested to know if this kind of patch makes things better for
> groups of people who like either behavior.

That sounds nice. Now like maybe two dozens of people who have reported the issue and had that issue marked as duplicate of this can use filechooser to choose files.

What about the bazzilons of users staring at the file chooser that removed the ability to choose files in their GTK applications without any explanation whatsoever?

Sure it is not self-explanatory that if you want a GTK dialog to work you edit some random file somewhere.

This is true. I am curious what solar flare caused the disturbance in the ionosphere that makes developers around the world drop everything and start developing for retards.

Microsoft drops everything and implements the candy interface not only for Windows 8 Home, but also for Windows 8 _Professional_ and above.

Apple drops everything and filters anything that makes you use common sense. Final Cut _Pro_ is now nicknamed iMovie by the industry because of this degradation.

And GNOME, we were so proud of GNOME for sticking it to the better man and it's versatility, until they too decided to drop everything and focus any and all rationale for change on the thought process of retards.

It's okay to keep differences in UX in mind. But to _explicitly choose_ to hide, remove, or simply not implement any customizability, is truely inexplicable to me.

And with me many others, I think this summarizes why many people are so frustrated about this. 

Anyway, I think those settings should be in System settings or Nautilus settings.

thomas meier wrote:
> Redsandro wrote: 
> > Also, we usually press Ctrl+L (location) to enter a different 
> > path manually, but in "Recent mode" Ctrl+L doesn't work, turning something 
> > that should be simple into a tab-party or forcing you to use the mouse.
> 
> Ctrl-L does not work at all on Fedora 16...

Works on Ubuntu and Xubuntu. Same as most file managers. Only time it doesn't work is in 'recent files'. In some places Alt+D also works, maybe that's the key for Fedora, idk.

@Federico, couldn't you just make the default $HOME[1], and then have a GNOME-specific widget/lib/envvar/setting/guideline that enables the recent files view by default when people are using (document-centric) GNOME apps?

Also, there are a number of issues with the Recent Files view reported/linked here that should IMO be addressed (probably in separate bug reports) before this feature should be/remain a default value, if it must be so.

Here's a partial summary in no particular order:

* If the app don't have file filters set, it "recommends" the user the option to try to open files the app can't even handle.

* Sensitive files (accounting files, porn) show up which is a privacy concern for environments where multiple people share the same login or use their computer in public.

* Listing only the basenames of the files makes it really confusing if you have recently opened files/directories all with the same name.

* Ctrl+L to open the entry that allows you to type a specific location doesn't work.

* It causes problems for people who want to save files (I didn't really understand this one so leave it general).

* It doesn't integrate with the other GTK+ platforms supported (namely Win32 and MacOS) that don't follow freedesktop.org specs.

* It's redundant/conflicts with many application's "File->Open Recent" (or similar) feature.

* There's no easy (ie. GUI) way to turn it off/change it globally by users, distros or on specific platforms.


----

[1] or back to CWD, which you said was the old way that usually ended up being $HOME. CWD and $HOME seem like much more useful default values and applications can (already) trivially override it where it makes sense for them, like a video player using ~/Videos or a picture viewer using ~/Pictures or a GNOME-app using Recent Files.

Matthew,

That is quite a good summary. Don't forget that when an app doesn't
set the filename for the save dialog, the 'Recent files' also comes
up, suggesting the use of existing files - which is quite dangerous!

John

(In reply to comment #65)
> * It causes problems for people who want to save files (I didn't really
> understand this one so leave it general).

I tried to describe it here: bug 670875.

Brief summary: You start working on something and want to save a new file to $CWD (or a directory closely related to CWD).  But $CWD is not among the recent directories.  Of course, you have not used $CWD *recently*; you are just using it *right bloody now* -- which not good enough for GtkFileChooser to offer it.

Problems saving files - an example is you want to save a copy of a document alongside one you saved yesterday. So you want to navigate to the folder, but you don't want to overwrite yesterday's file. So you can't use the list of recent files.

And yes, it would be helpful if $CWD was there when it's not the same as $HOME.

Or if I navigate to a folder and open it, shouldn't that folder then be shown as a recent location in a "save as" file chooser too, even if I've been saving elsewhere?

I eventually decided on being able to select between starting in recent-files, and starting in $CWD.

This is implemented in the bgo658280-filechooser-recently-used-2-24 branch for GTK+ 2.24.x, and in the places-sidebar branch for GTK+ master.

I'll merge the first branch into gtk-2-24 within a few days.  The second one is the completely reworked places sidebar, so that this code can be shared with Nautilus.

Both have context menu items to let you select the startup mode.  This works pretty well, and is also pretty unobtrusive.

I decided not to implement comment #48 as-is for the following reason.  You can already bookmark a folder, put it first in the list of bookmarks, and access it instantly with Alt-1.  (And the second bookmark with Alt-2, etc.)

I had no idea about alt-1, alt-2 etc; how would anyone discover this hidden secret feature? It would be clearer if the entries were numbered and the numbers had underlines, perhaps, or at least if the hover text mentioned the shortcuts!

(In reply to comment #71)
> I had no idea about alt-1, alt-2 etc; how would anyone discover this hidden
> secret feature? It would be clearer if the entries were numbered and the
> numbers had underlines, perhaps, or at least if the hover text mentioned the
> shortcuts!

Bad excuse: it's in the documentation if you look really hard!  http://developer.gnome.org/gtk3/stable/GtkFileChooser.html#gtkfilechooser-key-bindings

I agree that the shortcuts should be visible somewhere.  Perhaps in the tooltip for bookmarks?  I'd be glad to review a patch for gtkfilechooserdefault.c:shortcuts_query_tooltip_cb() - that's the function that creates those tooltips.

Nice shortcuts! I didn't know about them either. And I generally know stuff that non-technical users - for whom GNOME3 is clearly designed - don't. :P

+1 on tooltips!

> You can
> already bookmark a folder, 
> put it first in the list of 
> bookmarks, and access it
> instantly with Alt-1.  
>(And the second bookmark with Alt-2, etc.)

It's in  Fedora 16 (running KDE) not working at all.

All the shortcuts are nice, but you have do guide the user to know them. Some of our user will never use it anyway. Why not adding a menu like KDE? see comment 61...

(In reply to comment #65)
> * There's no easy (ie. GUI) way to turn it off/change it globally by users,
> distros or on specific platforms.

Minor correction here: It appears that this is not just a matter of no *easy* way to change it globally, there is actually no way to change it globally at all. No hidden options, No config files you can edit, no command line method. Nothing short of patching it yourself and recompiling from source can change this behavior globally. :(

*** Bug 690854 has been marked as a duplicate of this bug. ***

Is here any work in progress?
i dont want this feature too. Its just annoying

Is there a suggestion that the inability of the file chooser to show e.g. your home directory, or your Documents folder, but to leave you stuck in "recent documents" with no obvious way out, is intended? E.g. if I try to add an attachment in evolution, I first open a terminal (I'm using ROXTerm for the time being) and then I use gnome-open on the file, then I close the file, now it's in the list of recent files for attaching. Awesome. Or I open a File window and drag.

(In reply to comment #69)
> I eventually decided on being able to select between starting in recent-files,
> and starting in $CWD.
> 
> This is implemented in the bgo658280-filechooser-recently-used-2-24 branch for
> GTK+ 2.24.x, and in the places-sidebar branch for GTK+ master.
> 
> I'll merge the first branch into gtk-2-24 within a few days.  The second one is
> the completely reworked places sidebar, so that this code can be shared with
> Nautilus.
> 
> Both have context menu items to let you select the startup mode.  This works
> pretty well, and is also pretty unobtrusive.

I'm using ubuntu 13.04 and after two years i can't configure the file chooser behaviour.
Federico, you said that now the user is being able to select where to start.
Well, my question is: how?
I tried in gtkfilechooser.ini both "Startup-mode" and "Default-Folder" options, but none of them seems to work: gedit opens recent anyway, file-roller opens $home even when the default behaviour is "recent".
Could you please tell us how to change this behaviour?
Thank you very much, your work is appreciated.

The 'recently used' "Folder" is conceptually wrong and violates an important contract with the user. When I get the file chooser dialog, I expect two things to be presented, folders and files. This was the case for many years until an entirely new paradigm was created - recently used. It looks like a folder but its not a folder at all! In a save operation, what on earth does the recently used folder mean? Its not a logical choice. Also when reading files I usually want to see the folder I selected last, not a quasi-folder with a list of files that are not in the same directory. I'd love to be able to turn off this misfeature.

(In reply to comment #80)
> The 'recently used' "Folder" is conceptually wrong and violates an important
> contract with the user. When I get the file chooser dialog, I expect two things
> to be presented, folders and files. This was the case for many years until an
> entirely new paradigm was created - recently used. It looks like a folder but
> its not a folder at all! In a save operation, what on earth does the recently
> used folder mean? Its not a logical choice. Also when reading files I usually
> want to see the folder I selected last, not a quasi-folder with a list of files
> that are not in the same directory. I'd love to be able to turn off this
> misfeature.

Unfortunately, gnome people fail to see the difference between desktop-environment independent libraries like glib, gtk on one side, and "Gnome Desktop" on the other. They automatically assume you're working in gnome, using THE ONLY RIGHT WAY(tm). I was really angry about this few years ago, because I had to rewrite every piece of our company's SW which was using gtk and also to recompile some other, normally prepackaged sw. Just because some "genius" forgot why so many "geeks" started using gnu/linux - becaous of the freedom to use whichever tool or workflow they wanted.

For us, it's mostly commandline, but for some things, we need GUI to manually process the files (bitmaps) created by the commandline utilities, so imagine the "fun" I'm having when I suddenly had only these options:

1) for EVERY file, click "Home", and then click, scroll, click, scroll, scroll, click, scroll, scroll, scroll and select next file, which incidently is in the SAME directory as the previous file I've opened in the GUI.. yea.. I'm pretty sure Win3.11 was more user friently than this.

2) slowly recreate my multilevel filesystem structure in gtk-open dialog flat "favourites" list. Wow! Much liste! So scroll!
 
3) for every file, start GUI program with the file as cmdline arg, exit the GUI and repeat for next file. Cool. Welcome to 1980s and our good friend MSDOS.

4) rewrite all the file-open dialog calls in our GUI applications using GTK+, then download sources for all other GTK-applications we happen to use (gimp, mozilla, ..). Cool, like.. who likes some stupid "sudo apt-get install.." packaging nonsense anyway, right?

5) Switch to Qt or html+js (and rewrite ALL our GUI applications COMPLETELY). Yeah! My employer really loves to pay me to do this!

6) Kill myself!!


I was foolish in 2008 to choose GTK+ as a GUI library. It backfired soon and now we try to move everyting which needs GUI to either html and in some cases Qt. I'm not happy with this, I allways found GTK+ much easier to work with.. but then Gnome people decided, that everything "old" is wrong, and forced me to use "The New Way".


Let's make things nice and sparkly clean: I don't mind if there is "recently used" pseudofolder by default or not. I just wanted to have a way to revert to old default - current working directory (or other options, which some people may find useful) - to HAVE A CHOICE.

I don't hate Gnome people because they see things differently, I hate them because they've taken away the freedom of choice.

Sorry for this rant, but what else can I do? Gnome people have only "One answer to rule them all": "blah blah blah.. this is better, and users love it, so shut up and love it too"

Rewriting the applications' GtkFileChooserDialog usage may not suffice.

https://developer.gnome.org/gtk3/3.0/GtkFileChooserDialog.html says the choose-default-folder functionality is deprecated and there are reports of it not functioning properly. As such, you'd need to patch GTK+ to resurrect/reimplement/fix that and *then* update your applications.

Actually, it looks like this might be something you're interested in: https://mail.gnome.org/archives/commits-list/2012-November/msg05423.html

I don't have a recent enough GTK+ to test it at the moment, though, so I'm not sure if this helps.

While I agree that the "Recent documents" folder is the worst invention in many years, it pales in comparison with the UI atrocity perpetrated against Evince.  What once was a fine PDF reader now is an unusable piece of junk.

Anyway in recent versions of GTK 2 the GtkFileChooser issue can be fixed by adding an option to a config file:

$ cat ~/.config/gtk-2.0/gtkfilechooser.ini
[Filechooser Settings]
StartupMode=cwd

Here 'cwd' means to open the current working directory by default. There are other options.

> Anyway in recent versions of GTK 2 the GtkFileChooser issue can be fixed by
> adding an option to a config file:

In which version was this implemented, and is there some way to set it globally (not just per-user)?

The problems I see with Recent mode are

(1) there's no obvious way to enter a different location and browse the file system,

(2) there's no obvious way to get the listing sorted by how recently you used the document,

(3) it's more common for me at least to want to process several files in the same directory... er, several documents in the same folder.. so "recent containing folders" would be more useful. E.g. if I use "save as" I almost certainly do *not* want to overwrite a recent document. So the Recent Documents behaviour encourages errors and data loss.

(In reply to comment #85)
> > Anyway in recent versions of GTK 2 the GtkFileChooser issue can be fixed by
> > adding an option to a config file:
> 
> In which version was this implemented, and is there some way to set it globally
> (not just per-user)?

It works here with version 2.24.22.

The system wide settings directory is /etc/gtk-2.0/.

Jan Spurny: This bug report is about the GtkFileChooser behavior. If you want to discuss general GNOME stuff, feel free to publish it somewhere else, but not in this Bugzilla. Stay on-topic, or your Bugzilla account will be disabled.

(In reply to comment #88)
> Jan Spurny: This bug report is about the GtkFileChooser behavior. If you want
> to discuss general GNOME stuff, feel free to publish it somewhere else, but not
> in this Bugzilla. Stay on-topic, or your Bugzilla account will be disabled.

To be fair, Jan's comment, while overly ranting, is actually pointing out the root cause of bug reports such as this. For proof, see the rationale link in Comment #1.

If any other project besides GNOME wanted to change the way their users worked, they'd *extend* GTK+ widgets in their own project-specific way/library, rather than reaching up through the stack and modifying the cross platform GIMP toolkit directly to suit their very specific and controversial needs, which is the fundamental reason this type of bug report exists in the first place.

I think I don't understand how to configure this. I just compiled 2.24.22 (and installed), but I don't see how to set this option globally. 

1) Do I add a gtkfilechooser.ini to the /etc/gtk2.0 directory with the above lines? (doesn't seem to work)

2) Do I add to the gtkrc file?

3) Do I edit gconf settings?

The Changelog doesn't seem to mention the 'cwd' value.

BTW, I tend to agree with Matthew - Maybe Jan's expressions are a little colorful, but he does express feelings which are more prevalent than is probably realized by the developers. The 'Recently used' feature is the first time I have really thought seriously about switching to another toolkit (after 15-odd years). I hope I can make this 'cwd' option work...

This change to the file chooser has broken my experience also.

As others have said, adding attachments in evolution makes no sense. If it showed recently used directories there might be _some_ value.

Please can it be reverted to how it was for the last many years - it used to work well, now it is unusable.

I do not understand how it can help anyone.

The requirement to press ~ or / to get a type in address bar is illogical also, particularly that the first keypress is ignored. i.e. to get to /tmp I must type //tmp

Note, I recently discovered you can right-click on the "recent" entries to copy the location or to open a file chooser there - which makes it much less of a problem.

I don't know how long that feature has existed - since right-clicking on lists of files doesn't generally do things I had no idea it would here. A tool-tip or status bar suggesting that the options are available might help, as would a button to press...

(In reply to comment #90)

> I think I don't understand how to configure this. I just compiled 2.24.22 (and
> installed), but I don't see how to set this option globally. 

This is a per-user option; you can't set it globally in GTK+ 2.x.  In GTK+ 3.x, you can set it globally through dconf.
 
> 1) Do I add a gtkfilechooser.ini to the /etc/gtk2.0 directory with the above
> lines? (doesn't seem to work)
> 
> 2) Do I add to the gtkrc file?
> 
> 3) Do I edit gconf settings?
> 
> The Changelog doesn't seem to mention the 'cwd' value.

Sorry, I thought I had documented the configuration options somewhere, but in fact I didn't.  They are documented now, and should appear with the normal reference documentation in GTK+ 2.24.23.  The relevant commit is https://git.gnome.org/browse/gtk+/commit/?h=gtk-2-24&id=a0a005def7d2c37e350ad494cd020107548cd248

In summary, to set the startup mode, change your ~/.config/gtk-2.0/gtkfilechooser.ini to have this:

[Filechooser Settings]
StartupMode=recent

You can use "recent" or "cwd" for the StartupMode key.

The next thing is to add this to gnome-tweak-tool; I'll look into it.

"Recently Used" (RU) tries to solve the problem "People often save files to the wrong place."

Whether or not RU does solve this, it has the cost of breaking the workflow by creating a view that diverts from the default:
1. RU visualizes a list of files that are not located in the same directory in a way that indicates that they located in the same directory. This creates inconsistency. I don't know if this helps, but Applications have "Open Recent" menus which are part of menus, see GIMP ( http://i.imgur.com/ZtGoGlS.png ) and Inkscape.

2. RU hides the location path. It is the only view in the GtkFileChooser that does so except for the search, which at least has the search bar selected by default. This breaks workflow when you use they keyboard to quickly select the location or filename, when you *do* know where your file browser is located and where you want to go.

3. Two files with the same file name or two directories with the same name can create extreme confusion. The hover tool tip only means that the workflow is slowed down even more.

"People often save files to the wrong place." does not appear to be a valid reason to disturb the default work process of users who do not have that problem. To solve the problem, instead the focus should be to allow users to find their files easily. Applications solve the problem by implementing "Open Recent" menus. File browsers can solve this by having a RU list. File selectors can solve this by having a RU list but this should not be the default option though, as it is not reasonable to assume that the default user story is "the user is not organized and has lost their files". The default should probably be cwd or $HOME.

As to investigating other defaults, I have two questions:

1. Is there a way to set StartupMode to my home directory or to a static path?

2. Can I use the last used location as default? When I start GIMP and chose to open a file, cwd will be the default location ($HOME) with my StartupMode setting. If I then navigate to $HOME/foo/ to open $HOME/foo/bar.xcf, close the file and chose the open file option again, it will default to $HOME/foo/. If I close GIMP and start it again, it will default to cwd again. Can I preserve the last used location of any application's file GtkFileChooser?

(In reply to comment #93)
> (In reply to comment #90)
> 
> > I think I don't understand how to configure this. I just compiled 2.24.22 (and
> > installed), but I don't see how to set this option globally. 
> 
> This is a per-user option; you can't set it globally in GTK+ 2.x.  In GTK+ 3.x,
> you can set it globally through dconf.

a hint for dconf documentation would be welcome. I found org->gtk->settings->file-chooser in the dconf-editor, but no key like startup-mode, from which version on is this in the 3 branch?

There seems to be some progress on this issue finally, that is great, thanks

> This is a per-user option; you can't set it globally in GTK+ 2.x.

That's a bug then. Should I open a new bug report/feature request for it?