Show view mode buttons in the open/save dialog's toolbar
ClosedPublic

Authored by ngraham on Apr 9 2018, 10:47 PM.

Details

Summary

Without this patch, changing the view mode is unnecessarily difficult: you need to click on the settings button in the corner, then navigate to a sub-menu if you want to change the view mode.

This patch adds toggle buttons for the two most useful view modes (Short view and Detailed view) to the toolbar.

Test Plan

Compile and deploy patch, create and log into a new user account, open Kate, open a file open or save dialog, and see that there are buttons to switch between Short View and Detailed Tree View:

Diff Detail

Repository
R241 KIO
Branch
show-view-mode-toggles-on-open-save-dialog-toolbar (branched from master)
Lint
No Linters Available
Unit
No Unit Test Coverage
ngraham created this revision.Apr 9 2018, 10:47 PM
Restricted Application added a project: Frameworks. · View Herald TranscriptApr 9 2018, 10:47 PM
ngraham requested review of this revision.Apr 9 2018, 10:47 PM
ngraham edited the test plan for this revision. (Show Details)Apr 10 2018, 2:25 AM

Can we arrange them so that they're more consistent with Dolphin? i.e. put the Preview button at right-most

Great, I even didn't know that this was possible *lol*
But wouldn't it be more consistent with dolphin to add the list view also ?

ngraham updated this revision to Diff 31813.Apr 10 2018, 1:21 PM

Also move the Preview button over to the right, so it doesn't compete with the view mode buttons

Can we arrange them so that they're more consistent with Dolphin? i.e. put the Preview button at right-most

Sure!

Great, I even didn't know that this was possible *lol*
But wouldn't it be more consistent with dolphin to add the list view also ?

Yes, I suspect a lot of people didn't know this. :) I'm hesitant to add a third mode for a couple of reasons:

  1. The open/save dialog doesn't really support the same modes in the same way that Dolphin does. It toggles between having the icons on top or on the left side by making them discinct modes; the open/save dialog does it by having the icons mode be a single mode, and toggling only the position of the icons
  2. Three modes is honestly overkill; icons and list mode are sufficient for 95% of use cases. The other modes are still available via the Configure icon in the top-right corner. "Simple By default, powerful when needed"

To elaborate, the open/save dialog has four view modes:

  • Simple View: what most other platforms would calll "Icons view". Can be configured to have the icons to the left side of the labels (Windows style), or above them (macOS, GNOME, Cinnamon, XFCE, ElementraryOS, everyone-else style).
  • Details View: what most other platforms would call "List view"
  • Tree View: a somewhat useless view that's like Details View except that it allows expanding the contents of folders, but omits all of the detail columns
  • Detailed Tree View: like Details view, but allows expanding the folders

I think Simple View and Detailed View make the most sense to put in the toolbar.

ngraham edited the test plan for this revision. (Show Details)Apr 10 2018, 2:07 PM
ngraham edited the summary of this revision. (Show Details)
ngraham updated this revision to Diff 31848.Apr 11 2018, 1:32 AM

Also add a Sort menu to the toolbar

ngraham retitled this revision from Show toggle buttons in the toolbar for the two most commonly-used view modes in the file open/save dialogs to Show view mode buttons and a sort menu in the open/save dialog's toolbar.Apr 11 2018, 1:34 AM
ngraham edited the summary of this revision. (Show Details)
ngraham edited the test plan for this revision. (Show Details)

I'm not thrilled about the dropdown menu button losing its an arrow when you make it activate-able with a regular click, but that's a Breeze issue (that I plan to fix soon...).

rkflx added a subscriber: rkflx.Apr 11 2018, 8:42 AM

I brought this up before, but let me repeat: It is of utmost importance to test with the default settings, i.e. default font size and default dialog size (remove ~/.config/kate* for that). Your current version does not look good, despite what you show in your screenshot in the summary:

Note that I'm not saying your intention in this patch is wrong. But as there is only so much space available, you need to prioritize what can be shown. By default, there should be no overflow arrow in the toolbar too. Ideas:

  • Sorting is irritating, this needs an icon, e.g. view-sort-descending, object-order-back or an entirely new icon. OTOH I wonder if this entry is needed at all, because for Detailed View you could simply click on the table headers.
  • The slider should get a minimum size.
  • There should still be a good amount of whitespace between what's on the left and on the right side of the toolbar. This separation into groups results in faster navigation in the UI and helps in making it feel less crowded.

Please resist the urge to put everything in the toolbar. Configuring the dialog is not a regular task, so using the Configure button is fine too. Only the most important settings should be shown.

I brought this up before, but let me repeat: It is of utmost importance to test with the default settings, i.e. default font size and default dialog size (remove ~/.config/kate* for that).

Actually, the file is ~/.config/kdeglobals, and the pertinent information is in the under the [KFileDialog Settings] section.

Your current version does not look good, despite what you show in your screenshot in the summary:

I did test with default settings. The slider is fully visible, though I'll admit that the whitespace could be improved.

(...along with a lot of the other papercuts you can see in that screenshot)

Note that I'm not saying your intention in this patch is wrong. But as there is only so much space available, you need to prioritize what can be shown. By default, there should be no overflow arrow in the toolbar too. Ideas:

  • Sorting is irritating, this needs an icon, e.g. view-sort-descending, object-order-back or an entirely new icon. OTOH I wonder if this entry is needed at all, because for Detailed View you could simply click on the table headers.

Yes that's true, I had thought about that, but in Short View there is no obvious way to configure the sorting, and the little configure menu in the corner is something that only experts use (it may get a little better once the icon is at least better as depicted in my screenshot, see D12034).

For now I'll remove the sort button and do that in another patch.

  • The slider should get a minimum size.

Not related to this patch, but I can think about it.

  • There should still be a good amount of whitespace between what's on the left and on the right side of the toolbar. This separation into groups results in faster navigation in the UI and helps in making it feel less crowded.

Please resist the urge to put everything in the toolbar. Configuring the dialog is not a regular task, so using the Configure button is fine too. Only the most important settings should be shown.

This was going to be it, don't worry. :) Configuring the dialog is only not a regular task because the interface to do so is currently hidden behind a sub-menu to a menu that's only revealed by clicking on an unlabeled button with an inscrutable icon. That may be "powerful when needed", but it's certainly not "simple by default".

Mac users change the view modes on their open/save dialogs all the time; I've seen them effortlessly do it for 20 years, because the view mode buttons are visible by default. A KDE contributor up-thread even admitted that he didn't know this functionality existed! That's definitely the sign of an interface that could stand to benefit from being made more obvious.

rkflx added a comment.Apr 11 2018, 1:43 PM

Actually, the file is ~/.config/kdeglobals, and the pertinent information is in the under the [KFileDialog Settings] section.

No, that's wrong:

> cat ~/.config/katerc 
[FileDialogSize]
Height 780=480
Width 1112=830

…and that's why you did not use the actual default settings.

Actually, the file is ~/.config/kdeglobals, and the pertinent information is in the under the [KFileDialog Settings] section.

No, that's wrong:

> cat ~/.config/katerc 
 [FileDialogSize]
 Height 780=480
 Width 1112=830

…and that's why you did not use the actual default settings.

Aha, mystery solved! So the size is remembered per app, but the settings are global. That's... interesting.

ngraham updated this revision to Diff 31884.Apr 11 2018, 1:46 PM

Remove sorting menu button; will do that in a separate commit

rkflx added a comment.Apr 11 2018, 1:47 PM

So the size is remembered per app, but the settings are global. That's... interesting.

Not only that, but they are remembered per screen size, which means you can have different window placements and window sizes per setup, i.e. on your notebook, with a larger display attached etc.

ngraham retitled this revision from Show view mode buttons and a sort menu in the open/save dialog's toolbar to Show view mode buttons in the open/save dialog's toolbar.Apr 11 2018, 1:48 PM
ngraham edited the summary of this revision. (Show Details)
ngraham edited the test plan for this revision. (Show Details)

How's this?

Better now? That's with a new fresh user account, so I think we can be sure it's using the default settings. :)

rkflx added a comment.Apr 11 2018, 2:04 PM

Hm, seems like the width of the places panel is set in kdeglobals (and too small, BTW). After resetting this, without Sorting it's a +1 from my side (did not look at the code, though).


As for Sorting: If a user does not click on the Configure button which then has "Sorting" in plain sight, why would he click on a Sorting icon? The problem is not that sorting is too hidden, but that users don't get the idea to actually click on any button in the toolbar. Moving sorting does not help at all with that.

For the view modes it's different, because users recognize the icon from Dolphin. I'd just add the view modes, and IMO sorting in the Detailed View is a good enough compromise. We could think about making this mode the default, because the horizontal scrolling of Short View is kinda difficult to use anyway.

rkflx accepted this revision.Apr 11 2018, 2:06 PM

Okay, did look at the code ;) But please get at least one extra approval from someone else…

This revision is now accepted and ready to land.Apr 11 2018, 2:06 PM

Okay, did look at the code ;) But please get at least one extra approval from someone else…

Yep, was planning on it.

Hm, seems like the width of the places panel is set in kdeglobals (and too small, BTW)

Expect another patch to improve this at some point soon. :)

As for Sorting: If a user does not click on the Configure button which then has "Sorting" in plain sight, why would he click on a Sorting icon? The problem is not that sorting is too hidden, but that users don't get the idea to actually click on any button in the toolbar. Moving sorting does not help at all with that.

Well a button with text on a toolbar is more visible than a sub-menu hidden behind a menu hidden behind a text-less button in the corner that currently has an inappropriate icon. But this is a more general problem with KDE-style ToolButtons that...

  • Don't visibly look like buttons until you hover over them
  • Don't have text, just an icon
  • Use a small abstract monochrome line-art icon

These buttons don't really communicate "Click me, I'm a button!" like they should. I plan to start a VDG conversation on the subject eventually.

For the view modes it's different, because users recognize the icon from Dolphin. I'd just add the view modes, and IMO sorting in the Detailed View is a good enough compromise. We could think about making this mode the default, because the horizontal scrolling of Short View is kinda difficult to use anyway.

Agreed. I was also planning to change the default for Short View to put the icons on top rather than on the side, to match Dolphin's default behavior. That's gated behind a couple of bugs with that view mode that I have to fix first though. Details View as the general default also makes sense for me once D11993 lands (without that, it's often almost unusable).

rkflx added a comment.Apr 11 2018, 5:58 PM

I was also planning to change the default for Short View to put the icons on top rather than on the side, to match Dolphin's default behavior. That's gated behind a couple of bugs with that view mode that I have to fix first though.

Might be difficult, because in order to fully display most filenames, you'd need to make the icon size large enough, but then you'd only be able to display relatively few items. The file dialog is different to Dolphin in the sense that the space the viewport can occupy is quite small, so a different view mode is not too bad. I'm curious though if you have a magic patch in mind which creates space out of nothing ;)

Details View as the general default also makes sense for me once D11993 lands (without that, it's often almost unusable).

Something to keep in mind: Both GTK and Windows also default to Details View.


More ideas to fit more buttons:

  • Consolidate the view mode buttons into a single button with a radio button pop-up menu (just like in Windows).
  • Move the reload button to the URL navigator.
  • Display the reload button only for remote folders (where KDirWatch cannot work).
ngraham added a reviewer: VDG.Apr 13 2018, 1:38 PM
abetts accepted this revision.Apr 13 2018, 4:34 PM
rkflx added a comment.Apr 13 2018, 5:18 PM

I know I already accepted this, but:

moves the preview button over to the right so it doesn't compete with the new view mode and sorting buttons.

While you now could remove "sorting" from the summary, I wonder whether it would make sense to revisit moving Preview. How about this:

After looking at your screenshot again, I'm not too fond of how Preview and Zoom Out relate to each other…

One more thing which came to mind after revisiting the dialog: Why not use Detailed Tree View instead? This way the buttons would act as a kind of simple/advanced switcher. Also, this is what Dolphin does, too!

ngraham planned changes to this revision.Apr 13 2018, 5:22 PM

I know I already accepted this, but:

moves the preview button over to the right so it doesn't compete with the new view mode and sorting buttons.

While you now could remove "sorting" from the summary, I wonder whether it would make sense to revisit moving Preview. How about this:

After looking at your screenshot again, I'm not too fond of how Preview and Zoom Out relate to each other…

One more thing which came to mind after revisiting the dialog: Why not use Detailed Tree View instead? This way the buttons would act as a kind of simple/advanced switcher. Also, this is what Dolphin does, too!

Good points!

One reason why I used Detailed Vew instead of Detailed Tree View was honestly because I think it has a better icon. Detailed Tree View's "squares connected with lines" iconography tolerably communicates "tree-style view" but not "vertical list of items" and "columns of additional information". The icon for "Details" view IMHO communicates both of these things much better, and those seem like more important parts of the functionality to signal than that fact that it's a tree-style view.

Dolphin has the same issue, but confusingly uses Detailed View's icon for that horrible side-scrolling Windows-style columnar list view (AKA Compact View Mode). I wonder how many people would cry bloody murder if we changed Dolphin to use the Detailed Vew icon for its own Detailed View Mode, and then removed the icon for Compact View Mode from the toolbar by default and found it a better icon (it would still be available from the View menu of course).

If we did this (after making icons-on-top mode the default for file pickers), then both Dolphin and the file pickers would have the same number of buttons, with each one display the same view and using a consistent icon.

rkflx added a comment.EditedApr 13 2018, 5:51 PM

Let's do one step at a time ;) First, decide which mode we want to show. Then think about the icon, i.e. either switch icons or redo the icon itself. (Basing the mode on the icon instead of on the behaviour is very questionable, I'm surprised you even bring this up…) The third step would be to look at Dolphin (where I think you should do a poll to gauge usage of what you describe as the "horrible" mode, an assessment which I'd agree with but maybe other don't… Also currently there is not much need in Dolphin to reduce the number of view mode icons in the toolbar, there is still enough space).

TBH, I don't think users look too much at what the icon depicts. They just recognize them as those square thingies from Dolphin and remember that clicking on them switches view modes. They try out which one they like best, and then choose their preference. This is also what I learned in other places: The relative positioning of the icon is much more important than what's on the icon itself. Thus I think you worry too much about the icon.

I would simply go for Detailed Tree View with the existing icon. One quick idea to tweak the icon to become more list-style would be to fill out the square on the top right, emphasizing the vertical axis. What do you think?

rkflx added a comment.EditedApr 13 2018, 6:34 PM

The third step would be to look at Dolphin (where I think you should do a poll to gauge usage of what you describe as the "horrible" mode, an assessment which I'd agree with but maybe other don't… Also currently there is not much need in Dolphin to reduce the number of view mode icons in the toolbar, there is still enough space).

Looked more into this, I don't think the third mode should be removed, and I don't think it's too bad to have 3 modes in Dolphin and 2 modes in the file dialog (the window sizes are different after all). Reason: In Dolphin all 3 modes always are in a group: In the menu, and most importantly in the config dialog. This group of three modes should also be reflected in the toolbar, otherwise it could cause confusion.

rkflx added a comment.EditedApr 14 2018, 7:44 AM

If we did this (after making icons-on-top mode the default for file pickers), then both Dolphin and the file pickers would have the same number of buttons, with each one display the same view and using a consistent icon.

After running Short view with Above filename and icons set to 32px for a while, I made an interesting observation: I'm much slower with selecting files, and it feels much more tiring. For example, try to locate ArcanistBranchWorkflow.php as quickly as you can:

Surprisingly I found Next to filename works much better. (I suppose Detailed Tree View shares the same properties, while still being more similar to the vertical scrolling people are used to from small mobile devices.)

Thinking about this, there might be reasons:

  • For Open File, it is important to choose a file, so having files with an identical prefix aligned to each other is much more readable.
  • For Dolphin, larger click targets and the ability to show previews are more important for the task of file management, which often involves multiple files (and not just one file like in the opening case).

Therefore I'd tend to not recommend switching defaults to Above filename, having different modes in the file picker and in Dolphin is fine!


Edit: Ah, it makes even more sense to me now:

If we were to track where the user is looking at with an eye tracker, i.e. record a gaze plot and perform a scan path analysis, it'd probably be all over the place for the first image (back and forth over the filenames, then back and forth over the files, with icons in-between), while for the second image it would be much cleaner (simple reading motion like in a column of text).

ngraham updated this revision to Diff 32112.Apr 14 2018, 1:48 PM

Rebase on current master

This revision is now accepted and ready to land.Apr 14 2018, 1:48 PM
ngraham updated this revision to Diff 32113.Apr 14 2018, 1:58 PM

Use Detailed Tree View and adjust separators and spacing

Yes, when the filename or metadata are the primary tools for differentiating files, having the items presented in a list format is much much better, as in your example of browsing for source files. But keep in mind that source files and other textual documents are only one use case! Large icons with previews are often much more helpful for predominately visual content, like images (think of Gwenview's open and save dialogs!), videos, presentations, epubs and comic book files, and many PDFs. This distinction is why I wanted to make it easier to change view modes within the file dialogs, and why I think each of the two view modes accessible from the toolbar should ideally support one of those use cases. If we don't change the icon positioning default, then we'll have two view modes that are optimized for textual content, and none for visual content.

Thankfully, previews aren't shown for tiny icons, and each view mode remembers its own size settings, so it's feasible with very little work to have Detailed Tree View show 16px icons and a nice tight list, and icons-on-top Short View show 48px (or larger) icons with previews. With this, we would have two views, each optimized for one of the two primary content types, which seems humane and appropriate given the diversity of software out there.

Of course this discussion is relevant to the next patch, not this one...

ngraham edited the test plan for this revision. (Show Details)Apr 14 2018, 2:13 PM
ngraham edited the summary of this revision. (Show Details)
rkflx accepted this revision.Apr 14 2018, 11:18 PM

Ah, small misunderstanding: I was mainly referring to not making Above filename (in conjunction with Short View) the overall default for the dialog. If Detailed (Tree) View was the default, changing the mode of Short View is probably fine. We could also add a third button, so it would work just like in Dolphin (needs removing Reload, but who is using that anyway, because it's not even present in Dolphin? See also D12215 ;).

Regarding your examples of primarily "visual" documents: I acknowledge that's one of the uses cases. However, please understand that here we are building a generic dialog. It also has to work for save (where previews do not make much sense, because you are mainly selecting a directory and then typing the filename manually), and for all other filetypes where you'd rather have long names than a big icon. The unifying theme for all items is the filename, not the preview! IOW, your use case is only a subset of all possible cases, but the default choice should fit all situations. Of course your work in making it easier to switch is important here, too…


Use Detailed Tree View and adjust separators and spacing

LGTM

Ah, small misunderstanding: I was mainly referring to not making Above filename (in conjunction with Short View) the overall default for the dialog. If Detailed (Tree) View was the default, changing the mode of Short View is probably fine.

Great. I could get on board with making Detailed Tree View the default.

We could also add a third button

I wouldn't be against that in principle, but that's much more challenging since icons-on-top vs icons-on-the-side is currently a setting that applies to Short View, not two separate views the way they are in Dolphin. Separating those out would be a big headache due to the way the data is stored, and furthermore if we separated that out into Icons View and Details View, then there would be five modes, unless we also removed Detailed View and Tree View... All in all I think that would be desirable, but I'm not sure I'm ready for that quite yet.

so it would work just like in Dolphin (needs removing Reload, but who is using that anyway, because it's not even present in Dolphin? See also D12215 ;).

...and D12218. :)

Regarding your examples of primarily "visual" documents: I acknowledge that's one of the uses cases. However, please understand that here we are building a generic dialog. It also has to work for save (where previews do not make much sense, because you are mainly selecting a directory and then typing the filename manually), and for all other filetypes where you'd rather have long names than a big icon. The unifying theme for all items is the filename, not the preview! IOW, your use case is only a subset of all possible cases, but the default choice should fit all situations. Of course your work in making it easier to switch is important here, too…

Yep, that was the point. :)

Ping. Any objections from Frameworks people?

+1 for making things easier and prettier.

Asking around on IRC and Telegram, I haven't found anyone who objects to this. Landing it.

ngraham closed this revision.Apr 19 2018, 2:18 AM

Somewhat related, why does the Size header have a number of items listed and not the size in bytes for all the items inside the folder?

size

0 items
2 items

Shouldn't it be:

size
1 kb
3 Mb

??

Somewhat related, why does the Size header have a number of items listed and not the size in bytes for all the items inside the folder?

size

0 items
2 items

Shouldn't it be:

size
1 kb
3 Mb

??

It's like that in Dolphin too. The reason is because it out to be tricky to implement See https://bugs.kde.org/show_bug.cgi?id=158090. I tried last year but ran into a bunch of issues that I wasn't a good enough programmer to resolve.

Somewhat related, why does the Size header have a number of items listed and not the size in bytes for all the items inside the folder?

size

0 items
2 items

Shouldn't it be:

size
1 kb
3 Mb

??

It's like that in Dolphin too. The reason is because it out to be tricky to implement See https://bugs.kde.org/show_bug.cgi?id=158090. I tried last year but ran into a bunch of issues that I wasn't a good enough programmer to resolve.

Awesome, just wondering. Don't mean to derail the conversation. Food for thought!

rkflx added a comment.EditedApr 30 2018, 11:17 PM

I wonder if we should revert this before it ships to users. I'd rather not introduce this in 5.46 in case we decide to change it again for 5.47.

Better accumulate visual changes a bit, because constantly changing the dialog might get annoying for users.

I wonder if we should revert this before it ships to users. I'd rather not introduce this in 5.46 in case we decide to change it again for 5.47.

Better accumulate visual changes a bit, because constantly changing the dialog might get annoying for users.

I agree, there is no reason to rush it.

So, are we going to revert this? Tagging is in two days...

abetts added a comment.May 3 2018, 9:52 PM

It would be cool if we could introduce it in this release and polish a lot for the next release. I give it a +1. @ngraham ?

It would be cool if we could introduce it in this release and polish a lot for the next release. I give it a +1. @ngraham ?

My understanding (according to the discussion in T8552) is that we don't want two buttons for "Short View" and "Detailed Tree View", but rather three buttons to match Dolphin's Icon/Compact/Detail view modes.

So it wouldn't make much sense to ship this patch only for one or few releases.

rkflx added a comment.May 6 2018, 6:18 AM

One more idea: Would it make sense to land each part of the rework on a dedicated rework branch first, and only once everything fits together (both in design and implementation) merge that branch to master?

This would avoid huge dependency stacks as well as the need to rush for deadlines in the release schedule.

One more idea: Would it make sense to land each part of the rework on a dedicated rework branch first, and only once everything fits together (both in design and implementation) merge that branch to master?

This would avoid huge dependency stacks as well as the need to rush for deadlines in the release schedule.

Yes, that would help a lot!