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.

3 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.

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.

And this specific area is what I feel most wrong:

2 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.