Version: (using KDE 4.0.0) Installed from: Ubuntu Packages Since the introduction of the brand new breadcrumb navigation method in the KDE Open Dialog, the "parent folder" button in completely useless, cause folder hierarchy is meant to be navigated with the breadcrumb, not with the up arrow. in fact Dolphin doesn't have this button. The "refresh" button is useless as well, because nowadays the file view is by default smart enough to reflect immediately every change in the filesystem, so refreshing it should be left only to the F5 key (in case the automatic detection doesn't work). This will save us a lot of real estate and will appear the open dialog less cluttered, enhancing the user experience
On Monday 21 January 2008, Davide Ferrari wrote: > Since the introduction of the brand new breadcrumb navigation method in the KDE Open Dialog, the "parent folder" button in completely useless, cause folder hierarchy is meant to be navigated with the breadcrumb, not with the up arrow. Yes, but not when the navigation bar is switched to "text edit" mode, that's the problem. > The "refresh" button is useless as well, because nowadays the file view is by default smart enough to reflect immediately every change in the filesystem Only for local files or remote operations done by the current user's kde, but not if anything else is changed in a remote folder (by someone else). > so refreshing it should be left only to the F5 key (in case the automatic detection doesn't work). Maybe. But "hidden" shortcuts (i.e. without any visible appearance) are not a good idea in general, even though this one is pretty common.
> Yes, but not when the navigation bar is switched to "text edit" mode, that's the problem. Ok, but the point is that the default *has* changed, so it could sound rude but "text edit" mode is a second class citizen now, so if someone is using it, she should conform with back/forward or with the backspace as a known hidden shortcut. Or at least consider it for the sake of coherency with Dolphin (which, again, it's the default now). About remote refresh problem, ok, you've got a point... although I think people with problems could just go backward/forward, the button can "survive" :) maybe hidden in the tools button?
On Monday 21 January 2008, Davide Ferrari wrote: > people with problems could just go backward/forward That doesn't work since we use a local cache of the remote directory listings :-)
You have a point about the default being redundant, of course. I wonder if we can make the up button appear when switching modes, but this might shuffle stuff around... I'll let others give their input on this topic anyway, I think it's been discussed a little bit before.
Thanks for adding me to CC. We had similar discussions for Dolphin, but just the other way around: the up-button should be added per default ;-) David's point that the up-button is required when switching to the "text mode" of the breadcrumb is quite important. Adding it dynamically to the toolbar is something which should be avoided from my point of view, but one option would be that when switching the breadcrumb automatically an up-button is added on the left side of the breadcrumb widget. I've thought quite often about this during the last months, but I think the up-button should not be part of the breadcrumb widget itself. My personal point of view: I'm not sure about the default configuration of the file-dialog, but in any case if we remove the up-button from the default configuration we must provide a way to add it again. I know from the input in Dolphin that some people require the up-button for their workflow. As a similar discussion can be held for the refresh-button: maybe making the toolbar configurable would be the way to go?
From a perfect ignorant point of view: would be too hard to share this setting between Dolphin and kdelibs/kdeui? I mean, if I put the up arrow in Dolphin, it should appear in the open/save dialog as well. If this isn't possible, as I suspect, I second Peter's opinion about configurable toolbar, even if I'd prefer to not add yet another option.
I've addedd the "up" button in dolphin manually.
On Tuesday 22 January 2008, Peter Penz wrote: > one option would be that when switching the breadcrumb automatically an up-button is added on the left side of the breadcrumb widget. Actually this sounds like a very good solution to me... This way there is no reshuffling of toolbar buttons while still making the up button available when the widget is in text edit mode.
> On Tuesday 22 January 2008, Peter Penz wrote: > > one option would be that when switching the breadcrumb > > automatically an up-button is added on the left side of > >the breadcrumb widget. > > Actually this sounds like a very good solution to me... > This way there is no reshuffling of toolbar buttons while > still making the up button available when the widget > is in text edit mode. My concern about this solution was that people who hate the breadcrumb view maybe don't want to lose another 20 pixels of horizontal space for the "up-button" (they lose already around 20 pixels because of the "restore to breadcrumb"-button on the right). Hmmm, in the file-dialog this would not matter, as the location-bar and the toolbar are in the same line. But I guess if we add this button to the breadcrumb, it must (?) be configurable whether it should be shown or not (e. g for people who have added the up-button in the toolbar of Dolphin already). Maybe my concerns are totally invalid. We could try adding such an "up-button" to the text-mode of the breadcrumb and initially make it not configurable and lets wait for user-feedback. Any thoughts?
Peter, you've just gained 20px by remove the "hardcoded" up button, so if it appears again well, we are at the same point :) This because obviously if you remove the up button is to give the breadcrumb more space
Any news? KDE4-trunk still behaves the same...
> Any news? KDE4-trunk still behaves the same... Sorry, I had no time for this task yet. It's on my TODO-list, but has not a very high priority, as there are still some major issues left in Dolphin for KDE 4.1.
I always use the "Up" button to go to parent directory, even in (default) bread crumb mode, so having it there is not a bug. Regarding configuration, people are probably used to right-click a toolbar to edit it, so adding an option to customize the toolbar would not clutter the interface. Changing severity to "wishlist".
Related: Bug 137837.
Let's use this to track the refresh button, which seems less controversial and less useful than the Up button. Also keep in mind that we're adding it to the context menu: https://phabricator.kde.org/D12215 So this functionality won't be completely lost via the GUI.
We had a big discussion on this matter in https://phabricator.kde.org/D12218 and came to the conclusion that these buttons are still needed--especially for network locations. So for now they've gotta stay, sorry! If and when we make the toolbar buttons editable (Bug 137837), you'll be able to do it yourself.