Is it also accessible from the menu in the top right?

In D12218#247125, @broulik wrote:

Is it also accessible from the menu in the top right?

No, that's a settings menu, not a toolbar overflow menu. Ultimately the toolbar should be editable, to satisfy all possible desired combinations: https://bugs.kde.org/show_bug.cgi?id=137837

I personally find the reload button much more useful to have there.

... (looking at the buttons) ...

Why not removing back, forward and up? This is not an ironic or sarcastic suggestion! Just be frank, how often do you use back?
How often do you use forward (close to never i assume).
And up? Well, it's twice in there already. You have the breadcrumb bar which allows you to go up.

Refresh on the other hand is something i use relatively often, more then any of the other buttons. But it depends on my hand position. If i'm already moving the mouse i'm inclined to hit the refresh button, if i'm already on the keyboard then i'm inclined to just press F5.

In D12218#247355, @markg wrote:

And up? Well, it's twice in there already. You have the breadcrumb bar which allows you to go up.

Not if you are in Edit mode (see bug for discussion). Also note that e.g. openSUSE even patches Dolphin to provide Up by default (and I would suggest this as the way forward as well, i.e. adding it in Dolphin instead of removing it in the file dialog).

how often do you use back?

It's not about us, but about regular users. For them it is reassuring to go back to the previous state when they misclicked on a directory. And having the corresponding Forward then makes it pretty clear that it is a web browser-like navigation, and not some kind of "show the previous dialog" thing known from mobile devices. Let's keep consistency with Dolphin here.

Refresh on the other hand is something i use relatively often, more then any of the other buttons.

Curious to know: What do you need Refresh for? Maybe there's need for some changes so you won't have to hit that button manually so often?

Refresh on the other hand is something i use relatively often, more then any of the other buttons.

Curious to know: What do you need Refresh for? Maybe there's need for some changes so you won't have to hit that button manually so often?

As i said, it's all relative. I barely use any of the buttons but the one i do use is refresh.
I only need it when i'm impatient (for instance when wanting to click on a file that is still being copied) or when i'm browsing a slow network drive.

In D12218#247400, @markg wrote:

As i said, it's all relative. I barely use any of the buttons but the one i do use is refresh.
I only need it when i'm impatient (for instance when wanting to click on a file that is still being copied)

Not really a valid use case; KDirWatcher should update the view for you automatically, and there's no practical benefit to mashing the reload button. The button isn't there to facilitate OCD. :) To do that, just hit F5. :)

or when i'm browsing a slow network drive.

The Reload functionality is still available via the F5 as well as the context menu. Are those not enough for this use case? And how common is this, really? I'm not sure that "file manipulation from the open/save dialog on a slow network drive" is a common enough use case to justify taking up space in an extremely constrained UI to show a button for reloading the view, especially once that functionality is available via another GUI method too (it's always available via F5.

Ultimately the pressure here will be reduced by making the toolbar editable, so people who really want a visible Reload button can have one. But until then, we need to ask ourselves whether the general user benefits from having this button always visible, more than he or she might benefit from having something or more general usefulness visible in the toolbar (e.g. a dropdown menu button that exposes sorting options).

In D12218#247481, @ngraham wrote:

In D12218#247400, @markg wrote:

As i said, it's all relative. I barely use any of the buttons but the one i do use is refresh.
I only need it when i'm impatient (for instance when wanting to click on a file that is still being copied)

Not really a valid use case; KDirWatcher should update the view for you automatically, and there's no practical benefit to mashing the reload button. The button isn't there to facilitate OCD. :) To do that, just hit F5. :)

Not valid? I'd remove all those buttons on the left side except for refresh :)

or when i'm browsing a slow network drive.

The Reload functionality is still available via the F5 as well as the context menu. Are those not enough for this use case? And how common is this, really? I'm not sure that "file manipulation from the open/save dialog on a slow network drive" is a common enough use case to justify taking up space in an extremely constrained UI to show a button for reloading the view, especially once that functionality is available via another GUI method too (it's always available via F5.

Ultimately the pressure here will be reduced by making the toolbar editable, so people who really want a visible Reload button can have one. But until then, we need to ask ourselves whether the general user benefits from having this button always visible, more than he or she might benefit from having something or more general usefulness visible in the toolbar (e.g. a dropdown menu button that exposes sorting options).

I find refresh (much) more important then the preview toggle (that should imho be under the settings thingy, not as it's own button).
Removing refresh is a mistake in my opinion.
Note that F5 is for some users FN + F5 in case the user prefers to use the "FN" functions (in my case that is true on one keyboard where the volume keys are hidden under F8, F9 and F10). That's not an argument to either keep or remove it, but just to show that refresh doesn't always have to be a one-key thing. But i consider that to be a "it's your own fault" case as the user then knowingly chose this.

But perhaps we need more opinions.

Can we find a compromise? For example, the Places panel already seems to know when something is on a remote location. Could we show Refresh only for remote folders? The toolbar reorganizing itself would also make users aware of the need to manually refresh in some cases.

+1

Should we land this onto the file-dialog-improvements branch, or are folks still unsure?

In D12218#271290, @davidedmundson wrote:

It can be useful for network views, but those are a minority of use cases

Every large scale KDE deployment (from my POV by far our most important userbase) has a network share.

It might not be needed often, but when it's needed it's needed.

Would you be okay with some of the compromises mentioned above, or is this again an all-or-nothing thing?

• Show toolbar button only for network folders.
• Move Reload to KUrlNavigator.

In D12218#271375, @rkflx wrote:

In D12218#271290, @davidedmundson wrote:

It can be useful for network views, but those are a minority of use cases

Every large scale KDE deployment (from my POV by far our most important userbase) has a network share.

It might not be needed often, but when it's needed it's needed.

Would you be okay with some of the compromises mentioned above, or is this again an all-or-nothing thing?

• Show toolbar button only for network folders.
• Move Reload to KUrlNavigator.

The problem would then be the detection of a network share.
I can mount a cifs share locally, you'd not know the difference.
Same with any filesystem. They can all become local. And - frankly - with SMB it has some performance benefits to mount it locally with cifs.

You could go for the "isSlow" check (smb is included in there iirc), but it would be a quite weak check.
I'd just say no to this. Reload needs to stay imho.