Dolphin: move tabbar above the main toolbar

I.e., a browser-like layout.

The problem with the current layout is that the “location” part of the main toolbar really belongs to the current tab. So, the UI hierarchy doesn’t match the logical one.

The problem is especially visible in split views. Without tabs:

And with tabs:

The tabbar just “cuts” in between the perfectly aligned split views and their locations.

1 Like

Looks good to me.

4 Likes

maybe it’s a theming thing, but when dolphin has focus my title bar and tool bar are visually set apart from the viewing areas with the tabs so it does not feel disjointed to me with the tabs how they are.

Screenshot_20231225_053438

1 Like

Same here. Mine show as separated, except for the one tied to the active tab. Breeze

The difference is that those two screenshots are from Plasma 5 :slight_smile: The screenshot the OP posted is from Plasma 6.

Well, that would make a difference. :slightly_smiling_face:

I agree that tabs above the toolbar/locationbar looks better to me. For what it’s worth, I opened a bugs.kde.org issue about this, with screenshots comparing to old/new Firefox versions, although maybe that wasn’t the best place to open the issue: 464386 – Place tabs above toolbar

Well, if everyone wants them moved up, then go for it. I’ll get used to it.

2 Likes

Even though browsers do this, I’ve never understood the appeal of moving tabs higher up in the window. Having the tabs above the toolbar implies visually that toolbars are per-tab, but that’s not the case.

I guess the main motivation is that users click on tabs more frequently than on the toolbar (which also applies to Dolphin, in my experience, when I’m using tabs), so Fitts’ Law (which doesn’t apply to Dolphin since the title bar).

But also the main part of the toolbar - the URL box - does belong to the tab. So do most buttons: Back, Forward, Reload, etc. This also applies to Dolphin.

In the same sense, Information panel and Terminal panel belong to the tab too. So the current layout is hierarchically incorrect in multiple aspects.

1 Like

And this specific area is what I feel most wrong:

3 Likes

Well, the toolbar kinda is per tab.

The back, forward and parent directory buttons, the view mode buttons, the current location breadcrumbs/text field, the split button all depend and take effect on the current tab. They do not take effect on hidden tabs and do not show the status of hidden tabs. Also, if you tear a tab into its own window it gains its own toolbar.

However, the menu bar/hamburger menu indeed is not tab specific.

We are simply getting closer to the BeOS (1) approach of stacking different windows together using tabs and moving away from the MDI approach.Opera, one of the first browsers to offer tabs, actually started by offering MDI windows within windows, moved to tabs and MDI, just tabs below and finally tabs on top. Other browsers never had the MDI phase. Tabs below are somewhere in between the two approaches and less flexible than either. Especially on Windows, MDI was everywhere in the '90s. Today, I can’t really think of any MDI app.

Kwin even used to offer window stacking back in the KDE4 SC days (2) and it is one feature I wish would make a return. Today, other than Haiku, I think the only platform that supports this feature is Windows thanks to 3rd party apps like TidyTabs and Stardock Groupy. There are two tickets (3) about this feature but they are marked wontfix. Personally, I still even hope for DWD.

  1. Haiku's GUI

  2. Hands-on: semantic desktop starts to show in KDE SC 4.4 | Ars Technica

  3. 343690 – Missing windows tabbing , 474739 – kwin support for tabbed windows

1 Like

A correction (can no longer edit) to my previous post. Apparently Cosmic desktop will also have window stacking: Design discussion: Stacks and Floating Windows · Issue #262 · pop-os/cosmic-comp · GitHub

The tab-bar location messes with the perception of the split panes in a very bad way. Split panes are clearly per-tab but but the information about the panes is located above the tabbar. There might be logical inconsistency with tabbar above the toolbar but it’s not actively confusing in the way that tabbar below addressbar is in the case of split panes.

1 Like

Hello everyone.
Is there something new on this topic? I agree that the tabs should be above the “Location” bar, because this bar reflects the state of the tab.
This is the behaviour of browsers (firefox, chrome, edge, etc) and it is also present on the Windows 11 file explorer, and also these two alternatives:

1 Like

This is just the opposite of my workflow. I click the toolbar buttons a lot. I have 15 buttons besides the 5 you list, a total of 20. The tool bar buttons are situated above the section they are used with.

The folder navigation is on the left, view type, search, filter bar and hidden files etc are above the main file section, and bookmarks and terminal on the right. I do not like playing the Menu Maze game. Click a button and move on. This is also why I don’t like the hamburger menus.

My location bar is separate from the toolbar. I have the toolbar, the tab bar, and then the location bar.

This is Plasma 6.

How do you put the location bar inside the tab?

For me, this is the what makes the big difference.
I thought the whole toolbar had to be moved, but only the location bar is very welcome.

Never mind: I just realize I only need to remove it from the toolbar.

Ok. Now I see I still would like to move the whole toolbar to inside the tab, because of the location of the buttons.

This looks awesome!!!

Would be great to have this available!!!

it makes total sense and would just be a matter of moving the tabbar to show up above the toolbar.

From a technical view point… is that a hard thing to do?

Anyone can shed a light of how hard this could be???

1 Like