Polish Open/Save dialogs
Open, Needs TriagePublic

Description

KDE's Open/Save dialogs are widely considered to be the best in the Linux world, but there's far more we can do to make them truly exceptional. Here are some ideas.

Design goal 1: Optimize view modes for common use cases

We identify two common use search modes for locating files or directories: 1) based on their filenames or metadata, and 2) based on their content or appearance. For the former, a compact optimized list-style view with columns of additional information is ideal. For the latter, a large-icons-style view with previews is ideal. Implementing this will require the following changes:

  • Always perfectly size and align column widths so that Detailed View and Detailed Tree View are actually usable: D11993
  • Improve grid spacing so that Short View with "Icons on Top" is actually usable at medium and large sizes: D12306
  • Show buttons on the toolbar to allow easily toggling between Short View and Detailed Tree View: D12077
  • Fix previews to apply to all supported file types (fixes https://bugs.kde.org/show_bug.cgi?id=318493): D12389
  • Make Previews only show up for icons (in any view mode) larger then 24px or so, as they are unusable and useless at such small sizes: D12321
  • Turn on previews by default: D12328
  • Make the view modes match the ones in Dolphin (e.g. Icons, Compact, and Details, with an option for "Allow expansion" in the settings menu
  • For Icons View only, make the default icon size 64px (fixes https://bugs.kde.org/show_bug.cgi?id=86838): D12326
  • Make KDirOperator display Detailed Tree View by default: D12327

Design goal 2: improve efficiency and safety of overwrite behavior

(Relevant information: D12346#249638)

  • Allow the file dialog to trigger overwrite on double click (irrespective of the click setting) without having to additionally click the Save button afterwards (fixes https://bugs.kde.org/show_bug.cgi?id=267749): D12538
  • Make Kate delegate overwrite behavior to the dialog, rather than handling it itself
  • When a file is overwritten using the Save dialog, display a notification with an undo button in it that will undo the overwrite operation and restore the overwritten file (fixes

Generally improve polish and usability

Add requested features

Fix bugs

Details

Differential Revisions
D12647: Move the inline preview button into the menu
D12591: KFileWidget: Provide faster access to the icon position setting
D12545: Set focus on the filename line edit when a file is selected
D12544: Don't select file extension
D12538: Allow accepting by double-click in save dialog
D7929: [WIP] Add new Column View option to KDirOperator
D12389: Filepicker reads thumbs preview from Dolphin settings
D12385: Thumbnail smooth scaling in filepicker
D12333: Put the open/save dialog's toolbar above all other widgets, like Dolphin does
D12337: Give the file dialogs a "Sort by" menu button on the toolbar
D12240: Save the dialog view settings when closing the dialog without hitting the cancel button
D12227: Save the dialog view settings even when canceling
D12215: Add a "Reload" menu item to KDirOperator's context menu
D12077: Show view mode buttons in the open/save dialog's toolbar
D12306: Improve grid icon layout in filepicker dialog
D11993: Tweak column widths in tree view of file open/save dialogs
D12328: Enable preview by default in the filepicker dialog
D12327: Show Detailed Tree View by default
D12326: In Short View, display icons on top and increase icon size
D12321: Hide file preview when icon is too small
Commits
D12594 / R241:d5f67b07b5ce: KFileWidget: Perfectly align filename widget with icon view
D12593 / R241:0bcc7eadf5ca: KFileWidget: Save places panel width also after hiding panel
D12592 / R241:302c70b39723: KFileWidget: Prevent places panel width from growing 1px iteratively
D12590 / R241:00d8a78f5696: KFileWidget: Disable zoom buttons once reached minimum or maximum
D12588 / R241:e4f4c66f96d8: KFileWidget: Set minimum size for zoom slider

Related Objects

Mentioned In
R241:057de57a7c0d: Give the file dialogs a "Sort by" menu button on the toolbar
D12337: Give the file dialogs a "Sort by" menu button on the toolbar
D12848: Set fix steps for icon sizes
R241:c537a717363c: Allow accepting by double-click in save dialog
R241:bec7f9d6a1ef: Enable preview by default in the filepicker dialog
R241:2559a2873962: Hide file preview when icon is too small
R241:a2759a5fe7b2: Revert "Show view mode buttons in the open/save dialog's toolbar"
R241:1e6b1ce01d4c: Revert "Show view mode buttons in the open/save dialog's toolbar"
D12077: Show view mode buttons in the open/save dialog's toolbar
R241:1b721c4b25e4: Thumbnail smooth scaling in filepicker
D12647: Move the inline preview button into the menu
T8621: sprint for usability and productivity goal
R241:6f15b9de84e4: Don't select file extension
R241:f472f5490125: Hide file preview when icon is too small
D12591: KFileWidget: Provide faster access to the icon position setting
D12538: Allow accepting by double-click in save dialog
T7841: Revamp buttons on the bottom to solve various usability issues
R241:bbc262674a56: Improve grid icon layout in filepicker dialog
D12321: Hide file preview when icon is too small
R241:b9a2ec685e7f: Filepicker reads thumbs preview from Dolphin settings
D7929: [WIP] Add new Column View option to KDirOperator
R241:5a2c49ae1580: Add a "Reload" menu item to KDirOperator's context menu
D12328: Enable preview by default in the filepicker dialog
R241:e839d47fa095: Show view mode buttons in the open/save dialog's toolbar
D12333: Put the open/save dialog's toolbar above all other widgets, like Dolphin does
D12327: Show Detailed Tree View by default
T7682: Proposed look-and-feel changes
Mentioned Here
D12647: Move the inline preview button into the menu
D12588: KFileWidget: Set minimum size for zoom slider
D12590: KFileWidget: Disable zoom buttons once reached minimum or maximum
D12593: KFileWidget: Save places panel width also after hiding panel
D12594: KFileWidget: Perfectly align filename widget with icon view
D12591: KFileWidget: Provide faster access to the icon position setting
D12592: KFileWidget: Prevent places panel width from growing 1px iteratively
D12544: Don't select file extension
D12545: Set focus on the filename line edit when a file is selected
D12538: Allow accepting by double-click in save dialog
D7929: [WIP] Add new Column View option to KDirOperator
D12389: Filepicker reads thumbs preview from Dolphin settings
D12385: Thumbnail smooth scaling in filepicker
D12346: Remove duplicate overwrite confirmation dialog
D12337: Give the file dialogs a "Sort by" menu button on the toolbar
D12333: Put the open/save dialog's toolbar above all other widgets, like Dolphin does
D12328: Enable preview by default in the filepicker dialog
D12327: Show Detailed Tree View by default
D12326: In Short View, display icons on top and increase icon size
D12321: Hide file preview when icon is too small
D12130: Use the more user-friendly string "File type" in the save dialogs
D12215: Add a "Reload" menu item to KDirOperator's context menu
D11993: Tweak column widths in tree view of file open/save dialogs
D12218: Remove Reload button from the file dialogs' toolbar
D12227: Save the dialog view settings even when canceling
D12240: Save the dialog view settings when closing the dialog without hitting the cancel button
D12077: Show view mode buttons in the open/save dialog's toolbar
D12306: Improve grid icon layout in filepicker dialog
There are a very large number of changes, so older changes are hidden. Show Older Changes
ngraham updated the task description. (Show Details)Apr 25 2018, 7:02 PM

Could we have the same icon zoom slider as in Dolphin?

  • Predefined sizes only, no arbitary icon sizes
  • No zoom buttons, (optionally) instead a wider slider

It is really difficult setting a specific size. It's like putting a thread in a needle.

ngraham added a comment.EditedApr 25 2018, 9:16 PM

Could we have the same icon zoom slider as in Dolphin?

+1, Dolphin's is simpler and much more user-friendly.

rkflx added a comment.Apr 25 2018, 9:19 PM

Could we have the same icon zoom slider as in Dolphin?

  • Predefined sizes only, no arbitary icon sizes

Sure, why not.

  • No zoom buttons, (optionally) instead a wider slider

I don't like that. I think in Dolphin it's really hard to recognize the slider as a "zoom slider", I'd rather add the buttons there. Also, in Gwenview the buttons are there, indicating with the icons that the slider is about "zooming".

Another reason for buttons is that they are easier to use for changing zoom step-by-step, not everybody is comfortable or even capable of executing a sliding motion with a touchpad. Let's keep the buttons, please ;)

rkflx added a comment.Apr 25 2018, 9:21 PM
In T8552#139580, @rkflx wrote:

Could we have the same icon zoom slider as in Dolphin?

  • Predefined sizes only, no arbitary icon sizes

Sure, why not.

Hm, OTOH if we keep the buttons, having predefined sizes in the slider is not needed anymore… Better keep the fine-grained control for those that want and need it. Removing that could be disliked by some.

Could we have the same icon zoom slider as in Dolphin?

  • Predefined sizes only, no arbitary icon sizes
  • No zoom buttons, (optionally) instead a wider slider It is really difficult setting a specific size. It's like putting a thread in a needle.

+1 on both FWIW.

I would personally also say we can do away with the slider as well, but I know some will disagree on that.

rkflx added a comment.EditedApr 25 2018, 9:42 PM

-1 for both, I think this would be a big mistake. I don't understand how Nate complains about missing borders for toolbar buttons on Breeze, but then agrees with removing icons which are actually useful for users figuring out what the slider is for and helping them in using the slider.

FWIW, I guess the reason the buttons are missing in Dolphin is simply because the status bar did not have enough height to fit the buttons. Not an issue in the file dialog, Gwenview and DigiKam, so they should not be removed.

rkflx added a comment.Apr 25 2018, 9:45 PM

Provocative idea: Remove the slider. Having only the buttons, the step-by-step setting @anemeth wants would still be there. (We'd need to add some kind of indicator for the size, though, making the exercise moot.)

In T8552#139586, @rkflx wrote:

Provocative idea: Remove the slider. Having only the buttons, the step-by-step setting @anemeth wants would still be there. (We'd need to add some kind of indicator for the size, though, making the exercise moot.)

I like this idea better. I think this is better than the slider, I proposed the slider-only to match Dolphin.

Gnome does something similar too:

In T8552#139585, @rkflx wrote:

I don't understand how Nate complains about missing borders for toolbar buttons on Breeze, but then agrees with removing icons which are actually useful for users figuring out what the slider is for and helping them in using the slider.

Henrik, I've silently put up with this for a while now, but I would appreciate it if you ended the passive aggressive sniping at me. We can discuss issues without subtly calling into question one another's judgment. Thanks.

As for the point under discussion, consistency is an issue, but consistency with what? Which slider is ideal? The one in Gwenview, Dolphin, or the open/save dialogs? In gwenview, arbitrary zoom levels makes sense because of the type of content that you're looking at. I would argue that arbitrary zoom levels are not very useful for file management, and indeed Dolphin doesn't have them--and I'm now aware of any complaints about this.

Perhaps for Dolphin and the open/save dialogs, we could ditch the slider entirely and use a dropdown menu of size options kind of like Windows does. Of course that has a slower interaction pattern than a slider...

So maybe Henrik is right that Dolphin's slider should have buttons on either end the way the open/save dialogs so, and the change we should make in the open/save dialogs is to adopt discrete steps like Dolphin has.

In T8552#139586, @rkflx wrote:

Provocative idea: Remove the slider. Having only the buttons, the step-by-step setting @anemeth wants would still be there. (We'd need to add some kind of indicator for the size, though, making the exercise moot.)

I like this idea better. I think this is better than the slider, I proposed the slider-only to match Dolphin.

Gnome does something similar too:

Mmmmm, that nice big stepper control they have in the Nautilus pop-down menu is really nice.

In T8552#139585, @rkflx wrote:

I don't understand how Nate complains about missing borders for toolbar buttons on Breeze, but then agrees with removing icons which are actually useful for users figuring out what the slider is for and helping them in using the slider.

Henrik, I've silently put up with this for a while now, but I would appreciate it if you ended the passive aggressive sniping at me. We can discuss issues without subtly calling into question one another's judgment. Thanks.

Sorry you feel that way. Please don't take it personally (at least it was not intended this way). Will see how to do better next time.

Perhaps for Dolphin and the open/save dialogs, we could ditch the slider entirely and use a dropdown menu of size options kind of like Windows does. Of course that has a slower interaction pattern than a slider...

Mmmmm, that nice big stepper control they have in the Nautilus pop-down menu is really nice.

These are all nice ideas, but I fear we might turn the task of "polishing" the dialog into a complete revamp, because often one change requires yet another change somewhere else. I'd vote for finishing what we have started first, and later coming back to further improvements. I feel going either the GNOME or Windows way would result in quite radical changes to the whole approach, which seems like a lot of work.

I'll now go back to polish my own patches.

I feel like a jerk for bringing it up, so thanks for understanding. I'm probably being too sensitive.

I agree that we have quite enough to focus on already. So yeah, let's keep going with some of the 39 (!) open tasks here before we add to the pile!

Just as a side note. The Vivaldi browser for example has an option "Use buttons instead of slider" which will toogle the zoom controls which are also located in the statusbar (a place which is best for this in my opinion)

When a file will be overwritten, handle that in the file dialog itself, rather than closing the dialog and displaying another pop-up window, or making the calling app handle it (Fixes https://bugs.kde.org/show_bug.cgi?id=102972). Some apps already do this right (like Gwenview, as of D12346), but some don't (Kate).

Could we have a specific list of apps that need to be changed? :)

anemeth updated the task description. (Show Details)Apr 26 2018, 11:29 AM

When a file will be overwritten, handle that in the file dialog itself, rather than closing the dialog and displaying another pop-up window, or making the calling app handle it (Fixes https://bugs.kde.org/show_bug.cgi?id=102972). Some apps already do this right (like Gwenview, as of D12346), but some don't (Kate).

Could we have a specific list of apps that need to be changed? :)

Kate, so far. Gwenview was recently fixed. Probably more. I took a look at Kate's code and there's a lot of custom stuff for the dialog to handle the overwrite case that can probably be ripped out.

ngraham updated the task description. (Show Details)Apr 26 2018, 7:52 PM
rkflx added a comment.EditedApr 27 2018, 1:39 PM
In T8552#138856, @rkflx wrote:

I'll look over your whole proposal to see whether there are any glaring problems ;)

Done. In general I like it ;) Apart from where I already commented on individual Diffs, here are some additional thoughts:

When a file is overwritten using the Save dialog, display a notification with an undo button in it that will undo the overwrite operation and restore the overwritten file

Sounds like a larger task, and might need some groundwork first. I guess this should not only affect the file dialog, but basically every destructive file operation, e.g. deleting, moving to the trash and also Dolphin's overwrite confirmation dialog.

Add an option to the Settings menu to return focus to the filename field when the user starts to type (fixes https://bugs.kde.org/show_bug.cgi?id=207750)

Hm, adding an option does not sound like a good solution to me, because in general you want both focus / keyboard navigation for folders and easy entering of filenames, not only one of them. It should work just like in KDE3, where pressing and + would switch back and forth between both widgets. This was broken with the introduction of the breadcrumb bar in KDE4, and thus is a bug, not a missing feature (IMO).

Make sure the return/enter keys are almost always bound to the Save or Open button (fixes https://bugs.kde.org/show_bug.cgi?id=385189)

Do we really want that? Currently Return will move focus from the item view to the file name line edit, and a second Return will accept (for Save at least, as for Open it is already directly bound to the button). Sounds like the same discussion as in D12538 to me, only that instead of clicking you press a key. This should be consistent, and also having Enter in addition to is good for discoverability.

Supported File Types list should be sorted alphabetically (fixes https://bugs.kde.org/show_bug.cgi?id=47750)

We should fix applications instead, because in general applications should be allowed to define their own order of mimetypes in that combobox (think of Inkscape, which might want to group different export formats a bit to keep the long list manageable, but not necessarily sort by name).

Make the minimum icon size in KDirOperator respect the global "Small icon size" minimum (fixes https://bugs.kde.org/show_bug.cgi?id=339662)

Wouldn't it make more sense to have the default icon size respect the global minimum, but still allow to override the actual minimum manually? For example for fonts you can set a global size for small fonts, but you are still allowed to select a smaller size in individual apps. Perhaps this way would be even simpler to implement, too.

Show selection markers when the click mode is Single Click (fixes https://bugs.kde.org/show_bug.cgi?id=185793)

As discussed elsewhere, providing a way to select multiple files without having to remember the Ctrl shortcut applies to double click too. The condition for showing those markers should be whether the dialog is opened in multi-select mode or not, and it could respect Dolphin's setting in that regard.


As I said, rest sounds fine, IOW more green that red, even if I mostly wrote skeptical things ;)

rkflx added a comment.Apr 27 2018, 1:40 PM

Just as a side note. The Vivaldi browser for example has an option "Use buttons instead of slider" which will toogle the zoom controls

That should be nicely solved by making the complete toolbar configurable.

which are also located in the statusbar (a place which is best for this in my opinion)

I'm afraid that adding a statusbar to the file dialogs would be a bit complicated from a UI standpoint, as the primary dialog buttons on the buttom would conflict with it.

ngraham updated the task description. (Show Details)Apr 27 2018, 10:10 PM
ngraham updated the task description. (Show Details)Apr 28 2018, 4:52 AM
rkflx updated the task description. (Show Details)Apr 29 2018, 6:18 AM

While I like the direction this is going in, I disagree with using the Detailed Tree View mode by default. I think we should use the simpler Detail View mode instead.

As we discovered in some of the Diffs, the overall set of view modes and view mode options is not all that well thought out yet. While we learned what is available while working on the tasks, our users will actually have a hard time understanding why there are two toolbar buttons, four view modes and two more view mode options.

Proposal:

  • Only a single View mode menu button in the toolbar, no extra settings menu entries anymore. Items similar to Dolphin's modes:
    • Icons (currently Short ViewAbove File Name)
    • Compact (currently Short ViewNext to File Name)
    • Details (currently Detailed View)
    • [] Expandable folders checkbox (currently Tree View and Detailed Tree View)
  • Default option: Details, with Expandable Folders unchecked
  • Same change for Sorting, i.e. only a menu button, no extra settings menu entry.

This would make everything much simpler in terms of UI. While we wouldn't have two buttons for vastly differing views in the toolbar anymore (remember that recently we had no buttons…), choosing between three options is still well in the realms of good usability. Also, the file dialog has less space than Dolphin, so going the menu button route instead of laying all buttons out would make sense, too.

In general users want to choose files, not play around with modes. While we do not reach Nate's ideal design, we'd still make mode switching easier than it was before and encourage it this way. Maybe that's the best we can do for now?

ngraham added a comment.EditedMay 1 2018, 1:32 AM

I strongly support the proposal to unify the view modes and options to resemble Dolphin's. If we make the change in KDirOperator, we'll need to make sure we don't break any clients that currently default to Short View. Also, a great deal of clients currently rely on Tree View, so we can remove that from the file dialogs' UI (I would be in favor of this even apart from any of the other proposed changes), but we can't remove it from KDirOperator.

Are you proposing that we have three dropdown menu buttons in the toolbar? One for View mode, one for Sorting, and one for "extra settings?" That might be menu button overload, and In order to be on board with this at all, I'd first want us to resolve the issue the Breeze issue with lacking downward-pointing arrows for menu buttons. If we can't resolve that issue I'm not in favor of proliferating even more menu-buttons-that-you-can't-tell-are-menu-buttons.

Why don't we make the view mode changes first, and then work out what we're going to put on the toolbar based on the amount of space available? I'd really like to have visible buttons for the view modes if possible.

ngraham updated the task description. (Show Details)May 1 2018, 1:36 AM
ngraham updated the task description. (Show Details)May 1 2018, 1:45 AM
rkflx added a comment.May 1 2018, 8:04 AM

I strongly support the proposal to unify the view modes and options to resemble Dolphin's. If we make the change in KDirOperator, we'll need to make sure we don't break any clients that currently default to Short View. Also, a great deal of clients currently rely on Tree View, so we can remove that from the file dialogs' UI (I would be in favor of this even apart from any of the other proposed changes), but we can't remove it from KDirOperator.

Are you sure we need to change KDirOperator (apart from exposing some parts, like I did in D12591)? IIRC the file dialog is put together in KFileWidget, so ideally only the front-end would change.

Are you proposing that we have three dropdown menu buttons in the toolbar? One for View mode, one for Sorting, and one for "extra settings?"

That's correct. We already have one (Settings), you wanted to add another (Sorting) and now we'd get a third (View modes). I'd rather click View buttonShort View than Settings buttonView modeShort View, just as Sort ButtonA-Z is faster than Settings buttonSortingA-Z.

I'd first want us to resolve the issue the Breeze issue with lacking downward-pointing arrows for menu buttons.

If I understood Hugo correctly in https://bugs.kde.org/show_bug.cgi?id=344746, he was in for changes, and there were already concrete proposals. Your latest message reads "but with some tweaks to improve the ease of determining which button they're attached to", so I'm afraid unless you or someone else comes along with those "ideal" tweaks, nothing will happen at all.

Don't let the perfect be the enemy of the good.

Why don't we make the view mode changes first, and then work out what we're going to put on the toolbar based on the amount of space available? I'd really like to have visible buttons for the view modes if possible.

Could you detail how the final result should look like similar to how I did this in my previous comment, i.e. not only the big picture, but every detail? Otherwise it's a bit hard to understand what you have in mind exactly.

ngraham added a comment.EditedMay 1 2018, 2:17 PM
In T8552#140229, @rkflx wrote:

Could you detail how the final result should look like similar to how I did this in my previous comment, i.e. not only the big picture, but every detail? Otherwise it's a bit hard to understand what you have in mind exactly.

Okay, how about this?

Toolbar:
Back Forward Reload (maybe) [vertical separator] Icons view Compact view Details view [vertical separator] "Sort & View options" [flexible space] size slider & buttons

URL bar:
up URL bar

The New Folder button is moved to the bottom.

The Sort & View options button shows a dropdown menu with the following items in it:

( ) Sort by name
( ) Sort by size
( ) Sort by date
( ) sort by type
[separator]
[X] Descending
[ ] Folders First
[separator]
[] Allow expansion in Details view
[separator] 
[ ] Show hidden files
[X] Show Places navigation panel
[X] Show inline preview
[ ] Show aside preview

Question: do we actually need Show Bookmarks? Doesn't the Places panel contain all that functionality?

Also, I feel like we will be able to save space on the toolbar by moving the Show Preview button to the menu because:

  1. With this idea, the menu becomes much more discoverable
  2. With our changes to the preview code for small icons and once we turn them on by default, there are fewer reasons to want to turn them off

The toolbar would look somewhat like this:

rkflx added a comment.EditedMay 1 2018, 2:25 PM

You are asking some more unrelated questions which I'll look into later, but you missed to answer my most important question: How will the view modes work?

Currently there are six five modes, your suggestion has only three.

In T8552#140322, @rkflx wrote:

You are asking some more unrelated questions which I'll look into later, but you missed to answer my most important question: How will the view modes work?

Currently there are six five modes, your suggestion has only three.

I agreed with your proposal to match what dolphin does. So we'd have Icons View, Compact View, and {Details View}, with a checkbox for "Allow expansion".

rkflx added a comment.May 1 2018, 2:49 PM

Okay, I see you edited your original comment to also include Allow expansion in Details view. Makes sense, but to match what we currently have my suggestion would be to make this affect Compact View too (currently Tree View).

Question: do we actually need Show Bookmarks? Doesn't the Places panel contain all that functionality?

To me that's a different type of use case, because you can have a detailed hierarchy of bookmarks, but perhaps don't want them displayed in Dolphin. The places panel also only supports a linear list, but none of the rich editing options of the bookmarks.

Of course by default they should be hidden, but I don't think we should kill them just yet.

The Sort & View options button shows a dropdown menu

Nice idea, but having text is a no-go. I already discussed my general reasons for the Sorting button text, but here we even have another problem: For other languages this combined text will become so long it will look absolutely ridiculous, make the toolbar much too wide and draw too much attention.

Also, I'd make the location more standards-compliant: Chromium, Firefox and Thunderbird all have their settings button aligned on the very right (and I'd recommend to do the same for Dolphin eventually). It would be a standard location for users to remember.

Maybe just swap the settings button and the zoom widget?

moving the Show Preview button to the menu

Makes sense to me, but might be controversial with others.


Rest looks good ;)

In T8552#140332, @rkflx wrote:

Okay, I see you edited your original comment to also include Allow expansion in Details view. Makes sense, but to match what we currently have my suggestion would be to make this affect Compact View too (currently Tree View).

I don't think we need to show Tree View in the file dialogs at all. Its only advantage over Detailed Tree View is that it can fit in very narrow spaces. We don't have that limitation in the file dialogs. It's basically made for vertical file browser panels embedded within apps (all of which currently use it as their view mode).

An Allow expansion in Details view checkbox would essentially toggle the view between Detailed view and Detailed Tree View. So we would wind up with the exact same three views as Dolphin:

  • Icons View: large icons, label below icon
  • Compact View: the current default view for file dialogs
  • Detailed View, with the option to allow expansion if desired: just like Dolphin

I thought this was what you were proposing before. If it is... then I approve!


Question: do we actually need Show Bookmarks? Doesn't the Places panel contain all that functionality?

To me that's a different type of use case, because you can have a detailed hierarchy of bookmarks, but perhaps don't want them displayed in Dolphin. The places panel also only supports a linear list, but none of the rich editing options of the bookmarks.

Of course by default they should be hidden, but I don't think we should kill them just yet.

OK, let's forget about it for now.


The Sort & View options button shows a dropdown menu

Nice idea, but having text is a no-go. I already discussed my general reasons for the Sorting button text, but here we even have another problem: For other languages this combined text will become so long it will look absolutely ridiculous, make the toolbar much too wide and draw too much attention.

The reason why I keep bringing up text and downward-pointing arrows is because I believe we need something to make the settings menu more discoverable. An alternative is if we make it less important by removing the sorting settings and giving them their own menu, which it seems like you and I now agree on. I could accept a text-less menu button if we get a really good icon and the button has a downward-pointing arrow.


Seems like we're here now:

Toolbar:
Back Forward Reload (maybe?) [vertical separator] Icons view Compact view Details view [vertical separator] Sort [flexible space] size slider & buttons Settings

The Sort and Settings buttons are menu buttons with downward-pointing arrows but no text

URL bar:
up URL bar

The New Folder button is moved to the bottom.

The Sort button shows a dropdown menu with the following items in it:

( ) Sort by name
( ) Sort by size
( ) Sort by date
( ) sort by type
[separator]
[X] Descending
[ ] Folders First

The Settings button shows a dropdown menu with the following items in it:

[] Allow expansion in Details view
[separator] 
[ ] Show hidden files
[X] Show Places navigation panel
[X] Show inline preview
[ ] Show aside preview
[ ] Show Bookmarks
rkflx added a comment.May 1 2018, 7:32 PM

I thought this was what you were proposing before. If it is... then I approve!

Well, initially I simply wanted to keep all modes, but I could also agree with your reasoning and find the dialog would get even better this way. It should only be made very clear by whomever implements this that one mode will be gone for good (instead of sneaking in a change just like that).

Seems like we're here now:

Sounds good :) As you know I agree with making dropdown menu buttons more discoverable, but the fact that this needs work should not lead to workarounds when designing the file dialog.

Another point for having two buttons is that each won't contain so many items anymore.

The Settings button shows a dropdown menu

Maybe move Show hidden files and Show inline preview in another separated group, as both settings also pertain to what's shown inside the file widget? Then the last group would be strictly about panel/button configuration:

[] Allow expansion in Details view
[separator] 
[X] Show inline preview
[ ] Show hidden files
[separator] 
[X] Show Places navigation panel
[ ] Show aside preview
[ ] Show Bookmarks

+1, sounds like we are in full agreement now. I'd also like to change the wording on some of the entries in the last section, so we'd wind up with this:

[] Allow expansion in Details view
[separator] 
[X] Show icon previews
[ ] Show hidden files
[separator] 
[X] Show Places panel
[ ] Show Preview panel
[ ] Show Bookmarks button
rkflx added a comment.May 1 2018, 7:48 PM

+1 on the wording changes.

Frameworks @elvisangelaccio @anemeth Any objections to this? Any help with implementing?

ngraham updated the task description. (Show Details)May 1 2018, 7:52 PM
ngraham updated the task description. (Show Details)May 1 2018, 8:09 PM
ngraham updated the task description. (Show Details)May 1 2018, 8:23 PM
ngraham updated the task description. (Show Details)May 1 2018, 8:26 PM
rkflx updated the task description. (Show Details)May 1 2018, 8:33 PM
ngraham updated the task description. (Show Details)May 1 2018, 11:27 PM
abetts added a subscriber: abetts.May 2 2018, 3:13 AM

I wanted to also propose a bit of separation between areas for the dialog. Maybe Dolphin can also follow suit. Take a look.

ngraham added a subscriber: broulik.May 2 2018, 3:29 AM

I've felt for quite a while that we need a line to separate toolbars from content beneath them, but that would ideally need to be done in Breeze rather than just here in the file dialogs.

Not sure how I feel about the bottom line. I think we at least need a line below the inline places panel to separate it from whatever's below, but I don't think we need an extra line between the content view and the Name field.

We already have a Breeze setting that draws a frame around Places panels (System SettingsApplication StyleWidget StyleBreezeConfigureFramesDraw frame around dockable panels). Here's how it looks:

Personally I think this look hugely better, but I know @broulik hates it. :)

abetts added a comment.May 2 2018, 3:35 AM

I've felt for quite a while that we need a line to separate toolbars from content beneath them, but that would ideally need to be done in Breeze rather than just here in the file dialogs.

Not sure how I feel about the bottom line. I think we at least need a line below the inline places panel to separate it from whatever's below, but I don't think we need an extra line between the content view and the Name field.

We already have a Breeze setting that draws a frame around Places panels (System SettingsApplication StyleWidget StyleBreezeConfigureFramesDraw frame around dockable panels). Here's how it looks:

Personally I think this look hugely better, but I know @broulik hates it. :)

Visuals first, that looks good. Better than my idea. What I am looking for too, if possible, is to come to an area where we can take panels all the way to the window edge. We miss out good pixels and looks by enclosing items in such a small window.

Here are some examples:

We can and should make the Places panel and the KDirOperator content view flush the left and right edges, respectively--just like Dolphin does--because it fixes the "double margin" bug that you're seeing, which is the result of KWin adding its extra window border width by default (https://bugs.kde.org/show_bug.cgi?id=315400).

Unless we change the default KWin setting for window borders to "No borders" or "No side borders", the best we can do is reduce the side margins and fix https://bugs.kde.org/show_bug.cgi?id=315400.

ngraham updated the task description. (Show Details)May 3 2018, 2:05 PM
ngraham updated the task description. (Show Details)May 10 2018, 1:10 PM

We're going to land future changes onto the file-dialog-improvements branch and then merge everything back to master once it's all cohesively ready.

ngraham updated the task description. (Show Details)May 21 2018, 12:01 AM

Since this appears to be the main hub for Open/Save dialogs:

  • I feel that a row highlight would feel better than highlighting only the name in Detail view/Tree detail view.
  • The rename option mentioned above would be great to have inline as in Dolphin. (Select an item -> F2)
ngraham updated the task description. (Show Details)Jun 1 2018, 3:51 AM
xyquadrat updated the task description. (Show Details)Jun 2 2018, 1:34 PM
ngraham updated the task description. (Show Details)Jun 2 2018, 7:48 PM