GNOME Bugzilla – Bug 710093
Nautilus doesn't save show hidden files setting on shortcut activation
Last modified: 2016-05-25 12:30:35 UTC
I had to kill nautilus because it was hanging. The window was showing hidden files. Now, every time nautilus starts up it shows hidden files. This is undesired. I tried looking up the place where I can change this back, but did not find it. Please advise.
Go to the "Files" menu, choose "Preferences"; a "Files Preferences" window pops up. There you will find a checkbox for the option "Show hidden and backup files". Is there a checkmark in the checkbox? If so, click to remove the checkmark, then close all nautilus windows; when you open nautilus again, do you still see hidden files? You can find more help in the documentation for more help: - https://help.gnome.org/users/gnome-help/3.8/nautilus-views.html.en - https://help.gnome.org/users/gnome-help/3.8/files-hidden.html.en
Wow, that was completely counter-intuitive for me! Thanks for the advise. Why the heck is the preferences menu located under the thingy in the top bar instead of under the 'settings/gear' button of the nautilus window itself?! I'm betting there are more people experiencing this. The whole thing of placing menus under the window thingy in the top bar is a big mistake as far as I'm concerned. And it gets even _more_ awkward in multi-screen setups...
With relation to hidden files, does it work as expected now?
(In reply to comment #3) > With relation to hidden files, does it work as expected now? yes it does. sorry for not being explicit.
(In reply to comment #4) > yes it does. sorry for not being explicit. No problem, I just wanted to making sure. Considering that you didn't know where to find the Preferences, I wonder why the Preferences were changed if didn't enable that checkbox yourself. Did you display hidden files (using [Ctrl]+[H] or the context menu) in the "Open file" or "Save file" dialog before?
I (In reply to comment #5) > (In reply to comment #4) > > yes it does. sorry for not being explicit. > > No problem, I just wanted to making sure. > > Considering that you didn't know where to find the Preferences, I wonder why > the Preferences were changed if didn't enable that checkbox yourself. > > Did you display hidden files (using [Ctrl]+[H] or the context menu) in the > "Open file" or "Save file" dialog before? I only ever use Ctrl+H
Not sure what the problem here was, but on Ubuntu bug tracker something similar has occurred to several people: hidden files become visible by default but the option in Nautilus itself does not make a difference. The show-hidden option in dconf-editor does make the option "stick": | gsettings set org.gtk.Settings.FileChooser show-hidden false https://bugs.launchpad.net/ubuntu-gnome/+bug/1171852
That's still an issue, as pointed on https://bugs.launchpad.net/nautilus/+bug/1247221, only happens when org.gtk.Settings.FileChooser show-hidden is true though
How to reproduce the bug in ubuntu. Hope this helps. Sorry if its not appropriate (first bug contribution in gnome :)): How to reproduce the bug: 1. Open Nautilus: Everything normal, hidden files are hidden. 2. In Nautilus press CTRL + H: Hidden files are shown. 3. Close Nautilus and open again: hidden files are back hidden. 4. Open Gedit; 5. In gedit try to open file. In the file chooser dialog, press ctrl + h. Hidden files will be shown, to be choosen. Close Gedit without choosing a file. 6. Open nautilus. Hidden files are shown again. Resume: when showing hidden files in the file chooser dialog, this preference sticks when re-opening nautilus. PS: You can revert to the default behavior in nautilus: Edit -> Preferences -> Uncheck "Show hidden files" In UX terms, its counterintuitive.
Having a shared setting with the file chooser was demanded and implemented in https://bugzilla.gnome.org/show_bug.cgi?id=143599, so closing as wontfix.
(In reply to Carlos Soriano from comment #10) > Having a shared setting with the file chooser was demanded and implemented > in https://bugzilla.gnome.org/show_bug.cgi?id=143599, so closing as wontfix. Carlos, I think the problem really isnt the setting sharing. But how it is behaving differently between the file chooser and nautilus. Examples: 1) File Chooser: 1.1 Open Gedit 1.2 Try to open file 1.3 CTRL + H in the file chooser dialog to show hidden files; 1.4 Close dialog and gedit without opening a file; 1.5 Reopen gedit 1.6 Try to open a file 1.7 Hidden files are still shown 1.8 Press CTRL + H: hidden files will be hidden 1.9 Once again, close gedit without opening a file 2.0 reopen gedit 2.1 try to open a file 2.2 latest setting (hidden files should be hidden) is respected; 2) File Chooser X Nautilus 1.1 Open Gedit 1.2 Try to open file 1.3 CTRL + H in the file chooser dialog to show hidden files; 1.4 Close dialog and gedit without opening a file; 1.5 Open nautilus: hidden files are shown. 1.6 Press CTRL + H, hidden files are hidden. 1.7 Close nautilus 1.8 reopen nautilus 1.9 hidden files are again shown. Differently from file chooser the ctrl + h trigger (or the menu option view -> hidden files) dosent saves the new setting.
Oh I understand what you mean now. The title of the bug report is kinda misleading. This was fixed on 3.18. Can you still reproduce it with latest version?
Actually i dont have access to the latest version. I am using Ubuntu 16.04, which uses 3.14.3 version of nautilus. First, i will reproduce your information that it is fixed in 3.18 in the related ubuntu bug. Second, is it possible to backport the solution to 3.14.3 ? Ubuntu is a big user base and as far as i remember they decided to not use the most recent nautilus version during the development because of some integration bugs. I dont have many experience with gnome source code, but if you can give me some direction to start, i can research and try to backport it. Cheers.
Ah I see, yeah we indeed fixed this on 3.18, so I'm going to close as fixed. Backporting this is not trivial To make consistent this change would be needed to make the same change for the zoom preference, sorting preference, etc. This involves UI and translations changes. These kind of changes are not allowed on stable releases and I believe downstream distributions wouldn't want to neither. In any case, 3.20 is the version we currently support which is the stable version, 3.14 is unsupported for almost 2 years now. So this change relies on the shoulders of whoever wants to not update to the stable version where this is fixed. Cheers