GNOME Bugzilla – Bug 582989
Navigating up in the pathbar makes the view ambiguous
Last modified: 2018-05-02 14:42:10 UTC
I had an interesting phone call from my father this morning, who was confused by the GTK file dialog box. Upon looking harder, I understand the cause of his confusion. If you go deep into a directory hierarchy, the names of the directories you've entered are shown on the screen, each in a little box. New boxes are added on the right-hand side as you enter new directories. If you then come back _up_ to a parent directory, those boxes on the right-hand side don't go away. See screenshot at http://david.woodhou.se/filedlg.png for example -- it's actually looking at the ~/Download/ directory but you could be forgiven for thinking that it's in the ~/Download/solos-pci-0.07/soloscli/ directory. After returning to a parent directory, why do we keep the old subdirectory on the screen? It's just confusing -- the fact that the actually selected directory is a 'pressed' button, and has bold text, is really not enough of a hint. Ideally, those old subdirectories should go away and stop confusing the user when we leave them and navigate back up to the parent. Perhaps it's useful to be able to go back to them quickly without having them in the list again, but that could be achieved with a small right-arrow button; the mirror image of the one on the left in the above screenshot. Or anything else that isn't so confusingly prominent. It certainly doesn't make sense for them to have the same visual status as the still-valid parent directories of the currently-selected folder.
> it's actually looking at the ~/Download/ directory but you could be > forgiven for thinking that it's in the ~/Download/solos-pci-0.07/soloscli/ > directory. Sure, the user is always forgiven... > After returning to a parent directory, why do we keep the old subdirectory on > the screen? It's just confusing -- the fact that the actually selected > directory is a 'pressed' button, and has bold text, is really not enough of a > hint. This is the first time I hear this complaint. Bold and depressed is a pretty strong and pretty standard way to indicate the current element, I'd say. > Ideally, those old subdirectories should go away completely when we leave them. No. The reason we keep them around until you go down into another branch of the tree is for visual continuity, and for allowing you to go back and forth between a directory and its ancestors without constantly having to find the directory again in the file list. Nautilus has exactly the same location bar behaviour, btw.
'visual continuity' means it still *looks* like you're in that deep directory, when you're no longer there, right? But hey, at least it still looks similar, so that's nice and pretty. Just misleading. There have to be better ways of getting back to the previously-selected child directory — I already suggested one possible alternative.
I ran into this exact problem recently. Now that the GtkPathBar *really* shows you where things will be saved, including in the recently-used mode, it is certainly confusing when you navigate up from $cwd and the subdirectories remain on the right of the current path component. I kind of like the idea of "hiding" the subdirs under a right-arrow component. We'd need to play with this to see how it feels (or write a pathbar widget that does custom drawing in a prettier way...).
We're moving to gitlab! As part of this move, we are moving bugs to NEEDINFO if they haven't seen activity in more than a year. If this issue is still important to you and still relevant with GTK+ 3.22 or master, please reopen it and we will migrate it to gitlab.
Yeah, this still happens.
(In reply to David Woodhouse from comment #0) > It certainly doesn't make sense for them to have the same visual status as > the still-valid parent directories of the currently-selected folder. (In reply to David Woodhouse from comment #2) > 'visual continuity' means it still *looks* like you're in that deep > directory, when you're no longer there, right? But hey, at least it still > looks similar, so that's nice and pretty. Just misleading. They don't have the same look; active (depressed) GtkButtons are meant to be visually distinct and are styled on that basis. I would say that part of the problem is that our theme does not style the active ones sufficiently different from inactive ones to make the difference in status obvious; see Bug 771204.
Yeah, that would probably help. Especially if we can visually distinguish all the buttons *up* to the selected one, somehow. So it's really obvious that [ home ] [ dwmw2 ] [ Download ] ... is currently selected but not (in my original example above): ... [ solos-pci-0.07 ] [ solospci] The ones on the right, which are mostly there to give you a quick way to get back down into the directory you just navigated up out of, could be made a lot less prominent.
That's a fair idea IMO. They could get the .dim-label style class, for example.
...but of course, we don't want to go too far in the other direction and make them seem insensitive, so it might need more nuance than that
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gtk/issues/316.