Sat Apr 20, 2019 12:49 pm
I am quite fond of Dolphin and its powerful features and have even spent a week or two on adding help texts to it (waiting for reviews: https://phabricator.kde.org/D20471). Still I find myself using Gnome Files for simple file management because of its clean and simple design.
I want to make Dolphin look clean and nice by default. The slogan is "Simple by default, powerful when needed" after all and I want the design to look as simple by default as possible.
Have a look at the default user interface of Dolphin: https://pasteboard.co/Ib0xgyD.png
For me there are three parts that make Dolphin look not great. I will explain my ideas on how to solve them as well.
1. The Places panel
2. The Toolbar icon arrangement
3. The Status Bar text
1) The Places panel
Fortunately this is already being worked on. I didn't look into the progress on this yet or what exactly is all in the making but I am sure it will be an improvement.
Cheer for the people working on this and wait patiently.
2) The Toolbar icon arrangement
My main problem here is that there isn't enough structure in the Toolbar. There is this big bunch of icons all aligned left which leads to the top left of the Dolphin window to be cluttered with symbols while the top right is empty. It makes me a bit uncomfortable seeing my main tools all crowded together above the Places panel. If the Menubar is enabled there is even more information in the top left corner. Fortunately the Menubar is hidden by default.
2a Create a spacer widget that allows changing alignment of Toolbar icons. Put this spacer where it makes sense by default to group the actions visually. I would propose having it on the right of the different views so there would be the basic standard actions on the left of the spacer and the more advanced viewing options and the Control button on the right. (like it is in Firefox)
2b Think hard about what icons should be there by default and which should be labeled. I am quite happy with the defaults here. The only one I am unsure about is wether the Split view should be there by default as I imagine any basic user to get mildly overwhelmed when the view splits. New tab and new window are in my opinion the more common ways to have the functionality of split without actually splitting.
2c Fix the bug that prevents changing the Control button so we can even think about wether it should be labeled by default or where it should be placed. (Bug report: https://bugs.kde.org/show_bug.cgi?id=368421)
I think the Control button shouldn't be labeled since it is the only thing that looks like it contains options in the whole UI anyways. (like it is in Firefox)
3) The Status Bar text
The text on the left of the status bar is visually noisy since it changes whenever you interact with the view in any way. I find this very distracting. It changes when you hover or select items and shows information about the folder you are viewing when nothing is selected or hovered. You have to figure this and its use out yourself which isn't obvious since the most critical information (size) is only at the end of the line in brackets. It also tells you what file type an item has which helps if the abbrevation is unknown to you.
I actually never used this status bar text. Nonetheless it might be useful to know about the size or file type of an item you are viewing without opening a separate properties window.
3 Have there be no text most of the time. Only show the size of selected items by default. This way the size of items can still be found out but there won't be a changing text in the status bar when one is just looking through folders and hovering over items. You can even still get the size of all folder contents in the current view by selecting all with Ctrl+A.
The only functionality lost is information on hover (which only displays it for two seconds for me which might be a bug). Anyways selecting a file you are hovering isn't that much of a hassle probably. If you want to know the size of many files you can activate that information in the view properties after all.
With these ideas/solutions applied we get this: https://pasteboard.co/Ib0xzJj.png
My more adventurous solution I am unsure about:
4 Remove the status bar by default.
4a The status bar text on the left is not needed for most use cases and not necessary for the rest.
4b The zoom slider can be replaced by having zoom in and out buttons in the Toolbar.
4c The available space information doesn't need to be displayed there whenever you look through files. (Although there should be some place that tells users about their disk space situation.)
Removing the status bar and adding zoom buttons will lead to this: https://pasteboard.co/Ib0xR34.png
What do you think? How should Dolphin look by default?
At best this thread will lead to a task in Phabricator that defines the default look.
Tue Apr 23, 2019 8:08 pm
2a) I like the spacer idea and would suggest that be made available for all applications.
2b) Another idea is to combine the view mode buttons into a single selector.
I'll note that while I don't use the split mode there are plenty of users who do use it regularly. Retaining it as available to add will be appreciated if it is removed by default.
3) Perhaps make the Status Bar itself optional and disabled by default, as well as make the text (and other components) optional. I believe the information presented is useful to different people, so the flexibility should be maintained but I'll agree that it doesn't have to be there by default.
4b) I think I would prefer zoom buttons in the tool bar over the slider.
airdrik, proud to be a member of KDE forums since 2008-Dec.
Mon Aug 19, 2019 5:16 pm
It turns out the Forum isn't the best place these days to get a discussion going. I'll just update this once more so this thread has closure and to thank you airdrik for your reply.
This is a great idea. In the end it was me who implemented expanding spacers for all applications based on your suggestion: https://phabricator.kde.org/D22609
Just a week later a discussion was started on changing the default toolbar which I am quite active in. All in all I am happy with the results: https://phabricator.kde.org/D23075
This concludes 2b and 2c for me.
I agree and Noah Davis does as well but it is overruled for now.
I might be implementing this and 3 some day and hope it finds endorsement. I am pretty sure these are controversial though (the few votes on the poll seem to confirm this) which makes working on them less useful and fun.