Use a default toolbar layout that looks better and makes more sense for new users.
Details
- Reviewers
ngraham GB_2 elvisangelaccio - Group Reviewers
Dolphin VDG - Commits
- R318:9cd042a86c85: Change default Dolphin toolbar layout
Open Dolphin (with the default toolbar)
Diff Detail
- Repository
- R318 Dolphin
- Lint
Automatic diff as part of commit; lint not applicable. - Unit
Automatic diff as part of commit; unit tests not applicable.
+1, I love it. I would even add New Folder or Create New to the toolbar as well, but that's just me.
However this needs some technical changes to proceed:
- Please adjust CMakeLists.txt to increase the frameworks dependency version to 5.51 (prior to that version, the expanding spacer didn't exist)
- Please bump the version number at the top of dolphinui.rc (this needs to be done in every patch/commit that changes anything in an .rc file)
src/dolphinmainwindow.cpp | ||
---|---|---|
1730 | Tooltips are written as commands or sentences. Maybe change this to something like "Show menu" |
Make sure the default layout doesn't look lopsided when the application menu is enabled instead of the control button.
CMakeLists.txt | ||
---|---|---|
11 | Needs to be 5.61.0 (i.e. follow the existing pattern) |
Don't forget about the other inline comment too. :) You can also mark the comments as done and then hit Submit to mark them as done.
In the file dolphinmainwindow.cpp i changed m_controlButton->setToolTip(i18nc("@action", "Menu")); to m_controlButton->setToolTip(i18nc("@action", "Show menu"));
This looks great to me now. Testing it out, the new layout feels much nicer:
However I have one hesitation regarding replacing the three individual view mode buttons with a drop-down menu button. It feels like an unnecessary change. I'm not against it, but I also don't see a particularly strong reason for it either. Can you explain your reasoning for this?
I just changed it, because others in the VDG chat thought it's odd that the view buttons have no labels. I'll change it back.
You don't necessarily have to, I just wanted to start a conversation about it. :) I do like the symmetry of the actions on the periphery being icons-only and the ones in the middle having icons.
I think having 3 icon only buttons is still more efficient, you need one less click to change the view mode. This is also how other file managers have it.
There wasn't much discussion about using the view mode button in the VDG:
<thavn> perhaps we should consider which buttons have labels and which are just the icon as well...
<noahdvs> I find it odd that we use icons with no labels for the different views
<noahdvs> Maybe we should switch them for the View Mode toolbutton?
I think the biggest reason for it is that the label makes it clear that these buttons change the view mode. Clicking it also shows the names of the three different view modes so users can decide by the names and not just by the icons. It also teaches the user the shortcuts for them.
I think it looks better with the view mode button.
It does look kinda lopsided but I am not sure if it is worth it to change the default look because of that.
It's fine how it is now, how it also was before. There are tooltips for the buttons, and if we really want to show a shortcut, we can do it in the tooltip, but then everywhere in a different patch.
We should probably keep the show preview button unless we want to enable previews by default.
Ok. If we're not going to have a button to enable/disable them by default, we should disable previews for documents under a certain size. Maybe =< 32px or =< 22px?
This is not very nice to look at
... compared to this
I think it is because you can enable the full application menu without any confirmation or editing dialog. If we just move the split button over to the right side, it should improve the symmetry a bit. It could be further justified by saying that the buttons on the left are only for normal file viewing functions (this is where Nate's mom and dad should look) and the functions on the right are for more advanced features. I also think that it could be easy to overlook the search button with no label and only 1 or 2 small icons on the right side. If you move split over to the right side, that makes it easier to spot the magnifying glass next to it.
I think the view mode buttons should be replaced by the single View Mode menu button. Unlabelled icons are a bad idea unless the symbol is very common and very distinct. I don't think it's reasonable to expect people to understand the compact mode and icon mode icons without looking at the tooltip.
I think the Sort By button should also be on the left.
If a Create New button is also added after more discussion, I think it should also be on the left.
D12077 added the view mode buttons to open/save dialog for consistency with current dolphin.
So my point would be that given they have distinct icons and are used with the same exact semantic elsewhere, it could be a good idea to keep them.
If we decide we'd rather use the single view mode menu button, the same change should be applied to KFileWidget/KDirOperator.
No, I missed them, but now I've seen them.
Yes, once you have the muscle memory, 3 buttons is more efficient. Maybe it's just a pet peeve of mine that I'm getting hung up on, but I hate having to read a tooltip when I'm not 100% sure what an icon means before I click the button. BTW, Windows 10 doesn't show icon-only view mode buttons, although File Explorer is by no means a good standard for UI design. MacOS has 4 icon-only view mode buttons (ew) and GNOME has 1 that seems to flip between the thumbnail and list modes
I think this example is a very specific occurence for technical users. Most will imo be happy to just have the preview turned on without the need to change that because:
- Previews for text files are turned off by default
- File types have a lot of meaning for us whereas most don't care if they open an .odt or .doc file
- Browsing files where a preview is useless and the file type helps a lot in differentiating is (probably) a rare occurence (.h/.cpp). If there are a bunch of .odt and .doc files in a folder then the preview is more relevant than what type there is.
So I think we should remove the preview button by default.
I could be persuaded to have the Split button on the left, but either way this looks good.
I put it on the right (miscellaneous) because the split button doesn't change properties of the current view, a new view is also on the right side and to make the search or menu buttons not look lopsided.
Agreed. As a supplementary thing, perhaps we could have text file previews stop displaying for small sizes, as they become unreadable and are truly useless. But other preview types that show predominatatel visual content are always useful, even at small sizes:
Either way, material for another patch. :)
I think this is fine. It seems like I'm in the minority here with my opinion on the view mode buttons, so I'll just let that go.
I would be okay using a drop-down menu if:
- The title and icon of the button reflected the active mode as they do for Okular's toolbuttons with menus
- Drop-down menu toolbuttons got downward-pointing arrows with the Breeze widget theme (https://bugs.kde.org/show_bug.cgi?id=344746)
Material for another time, IMO.
Wow, this is quite a radical change :)
I'm not against changing the default layout, but we should be 100% sure to get it right. It would be very annoying if we have to change it again in six months because people didn't like it.
My comments after a quick try:
- I don't think we should add the "Go Up" button because you can already achieve the same action by using the url navigator buttons.
- Why the Split button on the right? It looks out of place imho.
- I wouldn't remove the Stash button because it shows up only if you have kio-stash installed. And it's a nice feature to advertise imho (it was the output of a GSoC project some years ago).
- This is possibly a problem in my setup, but this patch made my information panel disappear :O
I kind of agree, but don't have a strong opinion since it's a common control in file managers and doesn't take up much space.
- Why the Split button on the right? It looks out of place imho.
- Because the controls on the left are "normal" controls that can be used whether you're using the regular file view or not. The controls on the right introduce other views like search and split view. Stash could go on the right side as well with that logic.
- Because we needed something on the right to give the GUI a bit more visual balance when the application menu is enabled.
- I wouldn't remove the Stash button because it shows up only if you have kio-stash installed. And it's a nice feature to advertise imho (it was the output of a GSoC project some years ago).
Fair point. Might be off-topic, but I'm not sure what the usecase for stash is. I installed it as soon as it was available, but I don't know when I'd ever use it.
- This is possibly a problem in my setup, but this patch made my information panel disappear :O
Looking at the diff, I see nothing in this patch that would do that. However, I am experiencing the same problem with the version of git master Dolphin that I compiled with kdesrc-build. I'm not sure what causes the problem, but the version of git master dolphin provided by openSUSE's KDE:Unstable repos still has the info panel.
When your information panel disappears with git master, usually that means your baloo-widgets is out of date. It really should be integrated into Dolphin's own repo IMO since Dolphin is the only user.
Edit dolphinui.rc Add <Action name="split_stash" /> Before <Action name="split_view" />
Well, if I'm not wrong only the Windows explorer has it. Nautilus and the MacOS explorer don't.
- Why the Split button on the right? It looks out of place imho.
- Because the controls on the left are "normal" controls that can be used whether you're using the regular file view or not. The controls on the right introduce other views like search and split view. Stash could go on the right side as well with that logic.
- Because we needed something on the right to give the GUI a bit more visual balance when the application menu is enabled.
I see, makes sense.
TL;DR Looks good besides the Up button :)
src/dolphinui.rc | ||
---|---|---|
96 | Yes, you added it here. :) |
Why remove the up button when it doesn't use much space and is useful?
Just because these file managers don't have it doesn't mean we also shouldn't include it (Nemo, Thunar, PCManFM have it for example). It is very useful when you navigate back and forth between different directories, but then want to quickly go back to the folder that is a few folders above. If you would use the back button then you would have to click it a lot more.
You can also use it when you are in a pinned directoy and easily want to go to the parent folder.
Because you can "go up" using the url navigator. It is true that it doesn't take much space, but that doesn't mean that we should waste it. We should reserve this space in case we decide to add another action in one, two or ten years. ;)
I find myself using the URL Navigator to go up far more in GNOME software than in Dolphin. I think that's because the GNOME version actually looks far more clickable than ours does. Maybe if we improve that, then people will be more subtly, psychologically comfortable using it to go up?
Random thought about the View Button for a potential future patch if necessary: Couldn't the single view button just not be click-dragged from the single view button to the view mode in the resulting menu that the user wants in order to keep the same amount of clicks as having them separated?