GNOME Bugzilla – Bug 136077
No way to open hidden files
Last modified: 2011-02-04 16:16:07 UTC
Trying out the new gtk file-selector with gedit, if I want to open a hidden file, it seems to be impossible. 1. Hidden files don't display in the right-hand files/folders box, even if "All Files" is selected. 2. There's no place to type in the file name, even if you know it. So how am I supposed to open my .cshrc file for editing? This is using gtk+-2.3.5.
*** Bug 136775 has been marked as a duplicate of this bug. ***
In the location dialog, we need to do something like if (is_dotfile (filename)) _gtk_file_system_model_set_show_hidden (model, TRUE); and *then* select the typed filename in the file list.
Is the location dialog the one you get when you type Ctrl-L? How does a user know about this key combination? It seems like an undocumented power-user feature. There should be a way to do this without knowing special keypresses, shouldn't there? It should be obvious from looking at the file-chooser dialog.
First: not beeing able to open some important files on my machine I consider a rather critical bug. Could somebody please change Severity? Second: Even If one figures out the CRTL+L trick one cannot just browse through available dot files like in the old file chooser. Imagine I want to edit a config file but I am not exactly sure whots its name is: In the old one I could do something like - enter ".li" in the location bar and hit TAB -> the file (and directory) list updates and shows me all files starting with ".li" Oh, so many? - now I can continue typing ".lin" and hit TAB again to further filter the list of available files - continue until I have found the one file I'm looking for With the new Popup I do have tab completion but since it does not affect the list of displayed files I have to guess the right file name to find it. This happens not only with dot files but whenever I try to use the location popup to find a file. And I always try to use the location popup since I'm faster typing than using the mouse and scroll through endless lists and often I have my hands on the keyboard anyway and stopping and grabbing the mouse stops my work flow. This is a big step backwards in usability IMHO.
I agree, changing to critical. Tab-completion I also consider to be a power-user feature. This should be something that anyone can figure out, without having to read the documentation. How about a button or checkbox to turn on or off the display of hidden files?
"critical" is defined as involving data loss or making the whole system unstable. It's specifically not defined as "irritates me a lot". In my opinion, the solution is to make a context menu that allows turning on "show hidden". With 2.4.0 in strings freeze, we cannot translate that for now. I'm not 100% sure whether such a context menu is a file chooser or an application job, though.
I stand corrected. I didn't open the bug, though, because it irritates me a lot. I know how to use a command line to get around it. It's the people who don't who will be irritated. Where would the context menu be located? IMHO, whatever the solution is, it needs to be visually obvious in the default dialog. Or is there a logical way to add it to the file-types dropdown? I.e., the dropdown might include: Normal files + hidden Normal files Text files when called for opening a text file. Obviously that wording needs improvement.
Hidden files could have been handled via the file filter but for reasons I don't know it is a separate layer of filtering. Hidden directories could not have, as currently directories are not subject to filtering beyond the hidden/non-hidden level.
I have 2 arguments against using the filetype drop-down menu to show/hide the hidden files. (1) Regular filters should be applicable to hidden files as well. That won't be the case if the only way to show hidden files is via the filter "all files + hidden". (2) The filter "all files + hidden" would have to be the only filter also applicable to directories. Changing the 'file filter' to be able to see hidden directories might not be the obvious choice for most users (since the current filter is likely to match the file type they are looking for).
*** Bug 138427 has been marked as a duplicate of this bug. ***
I have a suggestion. If I type, for example, ~/.bash_profile to open that file, and there is a match, I think this should be opened immediately from the location bar, rather than having to go back to the selector, then clicking open again. Only where there is no match should it take you back to the selector with the rest of the hidden files showing. same goes for regular (non-hidden) files. It should just parse the entry, and take you as far as it can. i.e., if I type ~/.bash then open, it should show the home directory in the selector box, and show hidden files, or actually, just those files beggining with .bash.
If the location dialog (Ctrl L) is the solution for this bug, how does the average user know that it's there?
I think we need to find a way of adding the location dialog there in a way that makes it simpler to discover. (Ctrl L) is very unfamiliar with anyone who used windows for example. Not to say we should ape the windows one, but just make it easy to find.
I'm working on this.
Fixed on CVS. The mechanism to handle hidden files is in place now -- right-click on the file list and toggle the "Show Hidden Files" option, or select a dotfile in the C-l dialog. Note that this doesn't work in gedit, because there is a bug in _gtk_fnmatch() in that it effectively always turns on the FNM_PERIOD optio (for GtkFileSel's purposes), but GtkFileChooser doesn't like this. I'll file a bug about this.
*** Bug 138956 has been marked as a duplicate of this bug. ***
*** Bug 148341 has been marked as a duplicate of this bug. ***
*** Bug 148339 has been marked as a duplicate of this bug. ***
*** Bug 148336 has been marked as a duplicate of this bug. ***
I still think this isn't very discoverable on the part of ordinary users. I've never before come across any list box the contents of which could be modified by right-clicking.