GNOME Bugzilla – Bug 781819
The 'Save' dialog is missing Recent
Last modified: 2018-12-23 21:49:06 UTC
The 'Save' dialog has been missing an option to pick recent folders (and files) since 3.18. It was removed to fix the bug #751653. It was pointed to me that it was used by many users as a shortcut to folders they save files to. The dialog remembers the last used path, but it's not very useful if you save files to several locations.
[ Adding the ui-review keyword. ] If we want to bring the Recent Files view back into the Save dialog, then we need to answer the issues raised in bug 751653.
Hmm, what "issues"? That someone gets confused by a "recent" entry in the sidebar when saving a file (but not when loading a file)? No one is really forced to click on "recent", so why would it matter if it's there or not? The arguments in that bug aren't very convincing. Of course directories are nested and you usually travel down through them. But when you save your downloads in Firefox in ~/Downloads/ while scientific PDFs should go to ~/Documents/work/research/papers/pdf/, it's very (!!!) helpful to have that "pdf" entry in recent. And this is just the simplest possible example. Even if the logic behind the way the list is built might not be perfect, it just works for those of us who use it. Many people are just starting to recognize the option has gone because gtk versions slowly get into main distributions and programs like Firefox. We also just realized it because FF was upgraded to ver. 52 and before we didn't use many GTK3 programs (at least not to save any kind of files). Couldn't you consider making the "recent" entry a configurable option via settings.ini? Just removing a feature that many people are used to is a very bad idea. There will surely be more bug reports in the next weeks and months like these: https://bugzilla.mozilla.org/show_bug.cgi?id=1368501 https://unix.stackexchange.com/questions/382975/enable-recently-used-on-gtk3-file-chooser https://bugs.launchpad.net/ubuntu/+source/firefox/+bug/1694284 cu, Frank
I second that the 'Recent' option should be put back in to the Save dialog. Having directories selected recently in that list improves usability and efficiency a lot. I often have 10s of research papers open in different instances of the PDF viewer. To save those I want to keep, I use the 'Save a Copy' option. I navigate once from the pre-selected directory to the folder I want to save my files. Note that these folders are often at least 5 levels deep, i.e., require a lot of clicks. With the 'Recent' option in the File Dialog, all other instances of the PDF viewer will have that folder in their recent file list, and I can get there with two clicks. Without the 'Recent' option, I have to click my way through the directory tree for every single file. For, say, 20 files this is easily an added 3 minutes of time lost clicking through directory trees. )Especially so since the recent '1-click/2-click "improvement" to enter a folder requires quite some thinking...but that's a different story.) I have looked at the 'bug' that caused removal. It seems that one person was confused by the entries in 'Recent'. I agree that indeed it may be a bit confusing to see only the 'leaf' directory name there, but clicking it will reveal the full path and one can go back to the recent folder and pick another folder if necessary. Or one doesn't have to use the Recent entry if it is too confusing. Considering the improvement (one person less confused) versus the functionality lost (tens of seconds wasted by people who save several files in a short timespan), I suggest to put the option back. An option would be completely fine; it could even be off by default, and regular users who know and like the feature can turn it back on.
(In reply to barnoid from comment #3) > I navigate once from the pre-selected directory to the folder > I want to save my files. Note that these folders are often at least 5 levels > deep, i.e., require a lot of clicks. > > With the 'Recent' option in the File Dialog, all other instances of the PDF > viewer will have that folder in their recent file list, and I can get there > with two clicks. Can't bookmarking that folder help, in the meantime? > I have looked at the 'bug' that caused removal. It seems that one person was > confused by the entries in 'Recent'. Well, that one person is one of the main designers, so... It was also pointed out that apparently the current metric of access time wouldn't work or make sense for sorting directories in the saved list, though it's wasn't expounded why that would be an issue - but I'm not certain of all the FS details around that. > An option would be > completely fine; it could even be off by default, and regular users who know > and like the feature can turn it back on. I don't know how likely another FileChooser setting is, but I guess it's worth raising the idea. :)
Can we do sth. to support that? I tried to write a patch, but the logic isn't that easy and I've no experience in either GTK nor C programming :-) Currently, gtk-recent-files-enabled only changes settings for the load-file-dialog. So first I added another option gtk-recent-files-enabled-on-save that would change the setting only for the save-file-dialog, but that could be confusing. One would need to change gtk-recent-files-enabled to "gtk-recent-files-enabled-on-load" to make option names somehow consistent. So I tried to to make gtk-recent-files-enabled-on-save a "sub-option", being considered only if gtk-recent-files-enabled is true. But then I didn't know how to handle "recent_files_setting_is_enabled" in gtkplacessidebar.c (ib my first try it could just do sth. like "return ( enabled || enabled_on_save );"), because I couldn't even see where/how it is called. What do you think would be the better way? Two independent options or a sub-option? And in both cases I didn't know what to do with gtk_recent_manager_init as I don't understand that g_signal_connect_swapped call. For my personal use, I currently just change if (priv->action == GTK_FILE_CHOOSER_ACTION_SAVE || priv->action == GTK_FILE_CHOOSER_ACTION_CREATE_FOLDER) { save_widgets_create (impl); gtk_places_sidebar_set_show_recent (GTK_PLACES_SIDEBAR (priv->places_sidebar), FALSE); to ... gtk_places_sidebar_set_show_recent (GTK_PLACES_SIDEBAR (priv->places_sidebar), recent_files_setting_is_enabled (impl)); and recompile the gtk.rpm, but that doesn't help anybody else...
Oh, and btw: bookmarking does help for some standard places (e.g. always returning to the "ftp" folder when downloading patches etc.). But there are too many folders that I use often but maybe only once a month. Having the recent list with 20-30 entries at the first glance is fine for that, but I couldn't add 20 entries as bookmarks. And the recently used save places really change, depending on what part of work you are concentrating on currently. Sometimes I just need to fetch many things from the web for several days and sort them into different folders for papers, software, research addons etc. Then there might be days where I just download photos or graphics for the next bunch of web pages, or clean up my emails trying to sort attachments to the correct folders for storing them, and so on. In all these scenarios (there are way more) I'm using a bunch of save folders for some days, but for every scenario it's a different one :-) So I'd had to change the bookmarks all the time. So, really, the recent list in the save dialog is a very nice helper for some of us!
(In reply to Daniel Boles from comment #4) > Can't bookmarking that folder help, in the meantime? Yes, it can, and I do that when I really have a large number of files I need to save into the same folder, but this is really just a temporary bookmark and on one of the next occasions I realize that I still have stale bookmarks I have to delete them. So that, in fact, sounds like a perfect use case for something like a recent list... > > I have looked at the 'bug' that caused removal. It seems that one person was > > confused by the entries in 'Recent'. > > Well, that one person is one of the main designers, so... I didn't know who Allan Day was, but even if he is one of the main UI designers, a project like Gnome/gtk certainly isn't adding or removing functionality simply because one person, be that a main designer or not, likes or dislikes a feature, is it? We have decades of UI usability studies to learn from, and I would expect that every feature change follows some established protocol such as a usability study among users, a vote by the user community, or at least a vote on the issue by a UI design committee. > I don't know how likely another FileChooser setting is, but I guess it's > worth raising the idea. :) Sorry, I also do not know what your role is in the Gnome community, but if you can raise the issue, please do so. Will be much appreciated.
(In reply to barnoid from comment #7) > I didn't know who Allan Day was, but even if he is one of the main UI > designers, a project like Gnome/gtk certainly isn't adding or removing > functionality simply because one person, be that a main designer or not, > likes or dislikes a feature, is it? > We have decades of UI usability studies to learn from, and I would expect > that every feature change follows some established protocol such as a > usability study among users, a vote by the user community, or at least a > vote on the issue by a UI design committee. It wasn't removed just because one person said; at least one developer agreed. Where is this voting populace or committee that you speak of? People sure like to have opinions, but I'm not sure how many of them would be willing to sit on it and vote on every little proposal that came through the door. I'm not saying it's an inherently bad idea, just likely not all that practical. > > I don't know how likely another FileChooser setting is, but I guess it's > > worth raising the idea. :) > > Sorry, I also do not know what your role is in the Gnome community, but if > you can raise the issue, please do so. Will be much appreciated. You raised the idea by suggesting it above; that's what I meant.
I'd like to express support for bringing back the Recent Files view. Regarding the issues in the original bug, in Cinnamon you can get rid of this item using a setting in the Privacy system setting. I assume there are probably similar options in the other desktops. I also notice that there is a setting org.gtk.Settings.FileChooser that lets you choose which is the default location for the dialog, so you can stop the Recent Files view from being selected by default. This feature was extremely useful, losing it has been extremely annoying. When searching for solutions I came across posts by many people trying to get it to work. At the very least there should be an option to turn it on and off.
I also would like at least to have an option for bringing it back. I upgraded Firefox and now it's kinda crippled for me. This is really bad UX!
Comment #1 still applies.
No, it doesn't. If there was an option for this feature (just like it is for the load dialogue) and it its default was "false", then people who get "confused" by the recent view will never see it and thus be happy. I still don't see why nobody should be allowed to use this feature just because one person isn't able to handle it. Hide it by default, but don't delete it! And it really doesn't matter if Allan doesn't understand how the list of directories is determined and if it's mtime or ctime or whatever. A lot of people have been happy with the way it worked before and they would just like to continue using it.
I tried reverse-applying the patch from https://github.com/GNOME/gtk/commit/fe128b5b4d198a39c74a1a81b7a3e27f12262ff8 but unfortunately it's way too old it seems. Really a pity, maybe someone wanna take a try in "unfixing" it? And I totally agree with Frank Steiner. Hide it, if it really confuses that much. I would be perfectly happy with a setting in settings.ini or so to unhide it afterwards.
Obviously, this is not technically a bug, but marking it resolved is also not correct. The feature is useful & used by many - only very few users bother to find the bug and voice their concern in Gnome's bugzilla. I agree with Comments #12 and #13. The recent option should be brought back. If it is too confusing for some, then make an option to hide/unhide it.
I don't care how the list is determined. I had a list of folders with very meaningful names as I have an organized tree. It's usually 5-6 levels deep. Now I have to click through every time I need a different folder. On the "Recent" list it was only one. Just to maybe help describe the problem at hand. And bookmarking does not help. The list is pretty big and also quite dynamic (about 10 items, changing on a semi-daily basis)
Until now I was so confused as to why/how I lost the "Recent" selection in the Save dialogues in all of my apps! I am happy to have found this bug, at least to provide some explanation as to why this happened. I love using Gnome, and I can not easily imagine a world where I don't use it every single day. I am grateful for the all of the hard work and development that goes into FOSS , and so I enter this comment here just to add my voice to the others in this thread. The removal of the "Recent" items from the save dialogue's sidebar is small but constant frustration, every time I would like to save a file. It is particularly confusing, given that the Open dialogue still has the entry in its sidebar, and nautilus has a "Recent" selection in its sidebar at all times. I would be very pleased if there was a way to turn this feature back on, either through the Tweaks app, or as a general privacy setting. Thanks!
I searched for a while the reason i couldn't no more find the "Recent" entry, until i found this post. I agree with many others here : this functionality is very useful and there was no reason at all to delete it, just to please a few people who find the entry not clear enough for themselves. For me, the shortcut was perfectly placed. When you have to use 10 to 20 directories a day, with old and new ones every day, the "Recent" entry save you hundreds of mouse clicks ! So an option to hide/unhide it will be surely the best option for everybody.
Hi, I also would like to add that this feature was very useful and I used it frequently before it was gone. It literally saves lots and lots of mouse clicks when you have to handle many changing files a day and use deep folder structures. I see no harm in putting an option somewhere, I’d be even happy with just an option in a config file somewhere.
Not much I can add that others haven't already said. I as well didn't realize what exactly happened when I lost my recent list. This thread also isn't easy to find for the average user to voice their concerns, but I'm sure more will find their way here as I did. I sincerely hope you will reconsider adding this productive feature back.
I wouldn't expect anything to happen here ever. While struggling for weeks with gnome and gdm 3.26, trying to configure stuff that is easily possible for any other login manager and desktop, I've read many comments and threads and have come to the conclusion that Gnome developers simply don't care about users. They are so convinced that their own view is the only possible and absolutely best one, and that anyone having a different perspective is just too stupid to understand that they are right. Just two examples are the missing screenlocker if you use a different login manager than gdm, or the desktop icons that were removed in 3.28. Now you need an extension to get desktop icons back??? There are users that really like and want desktop icons, so what? Obviously they are just to stupid to understand that they don't want it, but the Gnome developers fortunately were smarter and took the decision for them. Just read https://plus.google.com/115250422803614415116/posts/KygiWsQc4Wm and click on "show 137 previous comments" to start with Linus first comment, and you will lose any hope that any feature will come back just because users want it. Even less if some poor Gnome developer got "confused" by a feature that didn't make any problem during the last decade. The reaction to poor Allans confusion indeed shows the whole problem: Don't make it configurable, just remove it! Srirams reaction in the quoted thread is so typical: "Maybe it isn't such a bad thing to ask people to at least try it and get used to using something with a new system to see if it works. Perhaps as an experiment you should try to see if you can use the default experience for a month and see if it's better or not?" Yes, Sriram and all the other Gnome folks: I tried for more than a month if working without the "recent" feature in the save dialogue is better or not. Guess what: It's worse! It's much worse! So, what now? Will you bring the feature back because me and others have tried without and don't like the new system without the feature? No, you mark it as "RESOLVED NOTABUG ". Thanks for nothing! There are lot of things Gnome people can learn from the KDE community. I did get back the "recent" option for all my QT apps, e.g. okular, by using "XDG_CURRENT_DESKTOP=gtk2 okular" (or alternatively QT_QPA_PLATFORMTHEME="qt5ct" and configuring gtk2 dialogs via qt5ct). That's what I call user friendly! With qt5ct I can chose the overall style and the file dialogues indepentenly from each other! I don't see any gnome app respecting XDG_CURRENT_DESKTOP or DESKTOP_SESSION. But why should they... they know better what's good for me, so why should I want different file dialogues? Stupid me...
(In reply to Frank Steiner from comment #20) > I wouldn't expect anything to happen here ever. While struggling for weeks > with gnome and gdm 3.26, trying to configure stuff that is easily possible > for any other login manager and desktop, I've read many comments and threads > and have come to the conclusion that Gnome developers simply don't care > about users. > > They are so convinced that their own view is the only possible and > absolutely best one, and that anyone having a different perspective is just > too stupid to understand that they are right. Just two examples are the > missing screenlocker if you use a different login manager than gdm, or the > desktop icons that were removed in 3.28. Now you need an extension to get > desktop icons back??? There are users that really like and want desktop > icons, so what? Obviously they are just to stupid to understand that they > don't want it, but the Gnome developers fortunately were smarter and took > the decision for them. > > Just read https://plus.google.com/115250422803614415116/posts/KygiWsQc4Wm > and click on "show 137 previous comments" to start with Linus first > comment, and you will lose any hope that any feature will come back just > because users want it. Even less if some poor Gnome developer got "confused" > by a feature that didn't make any problem during the last decade. The > reaction to poor Allans confusion indeed shows the whole problem: Don't make > it configurable, just remove it! Srirams reaction in the quoted thread is so > typical: "Maybe it isn't such a bad thing to ask people to at least try it > and get used to using something with a new system to see if it works. > Perhaps as an experiment you should try to see if you can use the default > experience for a month and see if it's better or not?" > > Yes, Sriram and all the other Gnome folks: I tried for more than a month if > working without the "recent" feature in the save dialogue is better or not. > Guess what: It's worse! It's much worse! So, what now? Will you bring the > feature back because me and others have tried without and don't like the new > system without the feature? No, you mark it as "RESOLVED NOTABUG ". Thanks > for nothing! > > There are lot of things Gnome people can learn from the KDE community. I did > get back the "recent" option for all my QT apps, e.g. okular, by using > "XDG_CURRENT_DESKTOP=gtk2 okular" (or alternatively > QT_QPA_PLATFORMTHEME="qt5ct" and configuring gtk2 dialogs via qt5ct). That's > what I call user friendly! With qt5ct I can chose the overall style and the > file dialogues indepentenly from each other! > I don't see any gnome app respecting XDG_CURRENT_DESKTOP or DESKTOP_SESSION. > But why should they... they know better what's good for me, so why should I > want different file dialogues? Stupid me... So I guess it's like I always already felt: Just don't use GTK (especially not GTK3). Now if Firefox just ported to Qt5, things would be peachy. Oh, and Emacs maybe. But latter I can at least still use with GTK2, former dropped GTK2 Support already :(
Leaving comments in this bug is pointless. GTK, alongside the rest of GNOME, moved to Gitlab to track issues months ago: https://gitlab.gnome.org/GNOME/gtk/issues and there's already an issue for a creating a design refresh of the file chooser dialog: https://gitlab.gnome.org/GNOME/gtk/issues/1239 Additionally, nobody writing down walls of texts about how "broken" the file chooser dialog still has answered comment #1 except with the evergreen "you broke my workflow" (see: https://xkcd.com/1172/) or "just add an option" (see: https://ometer.com/preferences.html). For instance, an answer on how people plan to solve the fact that directories in recent files lists are not navigable and are decoupled from the file system hierarchy; or an answer on how to distinguish the case when two recently accessed folders have the same name, but live under very different trees without relying on tooltips that may or may not exist or be accessible. I don't expect any answer to be left here. If you have a solution for the design and usability issues raised in #751653, please: file an issue on Gitlab.
You totally missing the point: > For instance, an answer on how people > plan to solve the fact that directories in recent files lists are not navigable > and are decoupled from the file system hierarchy; or an answer on how to > distinguish the case when two recently accessed folders have the same name, but > live under very different trees without relying on tooltips that may or may not > exist or be accessible. All these might be important points to improve the recent file list. And while someone was working on it, you could have hidden the recent file list by default with an option to re-enable it. But you just removed it, ignoring the most important point: It *worked fine* the way it was for obviously every other user than Allan. I never had two directories with the same name in my recent list, so I just don't care if that could have been a theoretical problem or not! It worked for me, it was useful, it was great the way it was! You statement just shows the same attitude that I criticized: *you* (= some gnome developers) don't consider it useful the way it works. The fact that *users* liked it and were happy with the way it worked is absolutely indifferent to you! You continue to ignore users. And this is the worst thing you can do. Design issues, technical reasons etc. are all important points for development decisions. But user wishes and expectations should be too, and that's what's missing in the gnome developer community. And very nice, too, that you are telling us that this whole thread is completely ignored because all developers went somewhere else. Thanks a lot for this appreciation of users!
I second notion to add "Recently used" back to file chooser widget be it compile option or config option. It was ergonomic and very productive as it was. While I moved part of my usage to Bookmarks, you can only have limited number till bookmark pane starts to be overcrowded and loosing usefulness. Also there are cases that just do not cut to bookmark, as it would be needed to be removed after having work done. Constantly adding and removing bookmarks to places used once for a day is clearly not great idea If there is problem with same named folders just print their partial path. If someone named them the same way they clearly had reasons and I do not see that it is gtkfilechooserwidget place to save them from confusion.