Kate is really the only one that's wildly inconsistent here, with a totally different appearance and a different new tab behavior (they appear on the right, not the left). These issues are already tracked with https://bugs.kde.org/show_bug.cgi?id=385520 and https://bugs.kde.org/show_bug.cgi?id=390043, respectively.

Keyboard shortcuts are already unified: ctrl+++pgup/pgdn switch tabs. This does not work in KTextEditor views (e.g. in Kate and KDevelop) due to a bug: https://bugs.kde.org/show_bug.cgi?id=383721 (see proposed patch D7497)

I agree that Konsole needs to put close buttons on the tabs. There's actually an open patch for that: D17814

Icons in the tab seem very implementation-dependent and I don't know if a rule would be beneficial here. For implementations where each tab would show the same icon 100% or 99% of the time, it's not worth it IMHO.

I think this is a pretty neat idea (especially because I love the idea of close buttons in Konsole).

By the way, in macOS, from what I could glean, the close tab buttons are present in the app tabs but don't appear until you actually hover over them.

EDIT: Never mind :D That hover thing doesn't work for touchscreens (thanks Nate haha)

Visually the style Kate is using, with a minor change to only have the close red on hover, and the tab shaded selection color on hover of background tabs.

Keyboard shortcuts : Ctrl + Tab / Ctrl + Shift+ Tab as our default shortcut. Tab is used for focus change. I'm Ok with Ctrl + PgUp / Ctrl + PgDn as a secondary shortcut.

The split should be in tab since, usually if your split the view you are trying to look at both sides for some comparison. You may not want other tabs split in that way. And allowing per tab allows the user to have most options in how the content is shown.

Outside of a web browser I do not see the need to show an icon in the tab.

Shortcuts: I'm okay with using ctrl+tab as the default shortcut as long as we preserve ctrl+pgup/pdgn as a secondary shortcut for compatibility.

Appearance: I think we should not use Kate's style everywhere and should stick to the typical style used everywhere else. Reasons:

• It looks different from everything else and is not themable
• It's a custom widget, so this would require a lot of code changes everywhere else
• With this style, the current tab is much less obvious than it is with the other style
• It's ugly (subjective, but important)

Close button: I think it should be always shown on each tab, and just be an X. It should gain a red circle on hover.

Splits: Seems implementation-dependent.

Icons in tabs: Seems implementation-dependent. e.g. makes sense for Dolphin; does not make sense for KTextEditor views; sometimes make sense in Konsole.

Also, food for thought regarding close buttons: if we put each close button on the left side of its tab, then it's easy to close multiple tabs, since clicking on it will bring the next tab's close button into the exact same position; you can just repeatedly click on the same space to close multiple tabs.

In T10233#171165, @ngraham wrote:

Also, food for thought regarding close buttons: if we put each close button on the left side of its tab, then it's easy to close multiple tabs, since clicking on it will bring the next tab's close button into the exact same position; you can just repeatedly click on the same space to close multiple tabs.

excellent, much better than having to point and click every time

In T10233#171165, @ngraham wrote:

Also, food for thought regarding close buttons: if we put each close button on the left side of its tab, then it's easy to close multiple tabs, since clicking on it will bring the next tab's close button into the exact same position; you can just repeatedly click on the same space to close multiple tabs.

But that would only happen if tabs do not resize when removing other tabs. This is afaik only true while the tab bar is scroll able due to too many tabs?

In T10233#171222, @fabianr wrote:

In T10233#171165, @ngraham wrote:

Also, food for thought regarding close buttons: if we put each close button on the left side of its tab, then it's easy to close multiple tabs, since clicking on it will bring the next tab's close button into the exact same position; you can just repeatedly click on the same space to close multiple tabs.

But that would only happen if tabs do not resize when removing other tabs. This is afaik only true while the tab bar is scroll able due to too many tabs?

Right, but why would the tabs resize when other tabs are closed? Only Kate's tab bar does this as far as I can tell and that's the nonstandard one. The closable tabs in Konsole and Dolphin for example have a fixed size determined by the title text, and do not change their size when others are closed.

Right, but why would the tabs resize when other tabs are closed? Only Kate's tab bar does this as far as I can tell and that's the nonstandard one. The closable tabs in Konsole and Dolphin for example have a fixed size determined by the title text, and do not change their size when others are closed.

Firefox and Chrome both resize tabs when openeing or closing tabs and the tabbar is already full. Up to an min and max size. SO the behavior is not uncommon.

Just noticed that dolphins tabs do resize to the path name.

What are we going to do with something like the unsaved content notifier in Kdevelop? At the moment it resizes and shows an aditional icon ( a document-save) to indicate the unsaved content.

I would suggest to either use an emblem instead of an icon or to add the icon, keep the size and ellide the title.

Merge request for Refactored tab content and added recommendation about size .

(Kirigami) Tabs seam to have kind of a strange height of 28.

I would them to have a height of 30, because the icons are 22x22 and smallSpacing, that we normally use as padding, is 4.
As it is now, the padding is 3 to the icons, or 5 to the label.

I would recommend to increase the height to 30 and set the padding to smallSpaing?

One idea for new tab behavior from https://bugs.kde.org/show_bug.cgi?id=403690

• When a new blank/empty/default tab is opened, put it on the far right
• When a new tab is opened from some context (e.g. "Open this folder in a new tab") open it immediately to the right of the current tab

This would mirror the behavior seen in web browsers.

In T10233#171164, @ngraham wrote:

Icons in tabs: Seems implementation-dependent. e.g. makes sense for Dolphin; does not make sense for KTextEditor views; sometimes make sense in Konsole.

Some text editors do show in tabs icons for different filetypes (like IntelliJ or older versions of Atom), but I can't think of anything else.

In T10233#171162, @rizzitello wrote:

Keyboard shortcuts : Ctrl + Tab / Ctrl + Shift+ Tab as our default shortcut. Tab is used for focus change. I'm Ok with Ctrl + PgUp / Ctrl + PgDn as a secondary shortcut.

Ctrl + PgUp / Ctrl + PgDn is already used to navigate in text document, Not only in KTextEditor, but also in other text editors or IDEs like IntelliJ.
Why not use Ctrl + Tab / Ctrl + Shift + Tab as primary shortcut in other KDE apps? This shortcut is widely used also in non KDE apps (for example in browsers like Firefox or Chrome)? I think it's more user friendly and shouldn't conflict with other shortcuts.

edit: Konsole probably should be an exception with it's Ctrl + PgUp / Ctrl + PgDn. I think Gnome terminal and perhaps other terminals do use the same shortcut.

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

In T10233#171758, @fabianr wrote:

Firefox and Chrome both resize tabs when opening or closing tabs

When closing tabs with the mouse the tabs are not resized until the mouse moves away from the tab bar (Firefox, Chrome, Opera, Vivaldi).

I just came here because this is an issue that intensely irritates me, and I'd like to help: https://blogs.kde.org/2020/02/19/it-time-war-tabs

Have we ever considered thinking outside the (application) box and telling the UI shell which views are being managed by each window, so the shell can help the user switch view (app/view/file/uri, even Activity) consistently? I realise this is bigger than consistent tab style across apps, so please point me to it if this is in the wrong place.

Windows 10 does that, showing taskbar thumbnails for windows on a per-tab basis, not a per-window basis. It feels nice for windows that have 3 or fewer tabs. For windows with like 30 tabs (i.e. web browsers), it turns into a list, which is nice. I wouldn't mind having that in Plasma.

In T10233#221316, @ngraham wrote:

For windows with like 30 tabs (i.e. web browsers), it turns into a list, which is nice

Indeed, having a flat list when small that become a two-level list when large is a tidy solution.

In T10233#180614, @dariuszdeoniziak wrote:

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

agree with ctrl+tab/ctrl+shift+tab as primary due to being a defacto standard from the browsers. Where did the PgUp/PgDn shortcuts come from?

In T10233#221412, @wstephenson wrote:

In T10233#180614, @dariuszdeoniziak wrote:

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

agree with ctrl+tab/ctrl+shift+tab as primary due to being a defacto standard from the browsers. Where did the PgUp/PgDn shortcuts come from?

It came from terminal apps, noticed it in Konsole and Gnome Terminal. Although Ctrl + Tab works in Konsole too, not sure about other terminals.

In T10233#221412, @wstephenson wrote:

In T10233#180614, @dariuszdeoniziak wrote:

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

agree with ctrl+tab/ctrl+shift+tab as primary due to being a defacto standard from the browsers. Where did the PgUp/PgDn shortcuts come from?

Also web browsers! :) They implement this too. GNOME apps also use this shortcut. So it seems to have become something of a cross-desktop standard.

In T10233#221413, @dariuszdeoniziak wrote:

In T10233#221412, @wstephenson wrote:

In T10233#180614, @dariuszdeoniziak wrote:

I think best way to unify shortcuts in applications would be to use both Ctrl + PgUp / Ctrl + PgDn and Ctrl + Tab / Ctrl + Shift + Tab when possible, but not if it is already used by important feature or is a non formal industry standard, in that case use only one of the shortcuts. If both shortcuts can't be used by an application then either leave tab switch unassigned by default or provide 3rd shortcut option.

agree with ctrl+tab/ctrl+shift+tab as primary due to being a defacto standard from the browsers. Where did the PgUp/PgDn shortcuts come from?

It came from terminal apps, noticed it in Konsole and Gnome Terminal. Although Ctrl + Tab works in Konsole too, not sure about other terminals.

Please note that Ctrl+Tab/Ctrl+Shift+Tab in Konsole (and in some way also in Kdevelop) is using "last used" order while Ctrl+PgUp / Ctrl+PgDn (Kdevelop has some other shortcuts for the same functionality) is using tab order. This is a very nice feature that I like - Firefox has also recently adopted this distinction between the two modes of switching and using two different shortcut sets.

When looking at HIG / reference implementation, please consider the tab ordering mode and allow for both modes to exist in the same application.