Thanks, this is an exhaustive and frankly quite convincing overview. I think my age is showing here as I hadn't realized that every other platform had moved away from what you call the editable tab style for non-editable tabbed views. The distinction makes sense to me.

I would actually love to have the ElementaryOS style floating segmented control that can live in a toolbar or on the page,view itself, and I've wanted this for a long time. There are already quite a lot of views throughout KDE software that I've long thought could benefit from it. See https://bugs.kde.org/show_bug.cgi?id=384514.

What does this mean for the tab redesign I am working on? i.e, what should the tabs look like now?

In T13012#227413, @abstractdevelop wrote:

What does this mean for the tab redesign I am working on? i.e, what should the tabs look like now?

Not much, pretty much just defining how the style of tabs you're working on will be used.

In T13012#227413, @abstractdevelop wrote:

What does this mean for the tab redesign I am working on? i.e, what should the tabs look like now?

Nothing; we'll use your new style for editable/document/content view tabs and come up with a new style for view navigation tabs.

OK, seems good. I'm almost finished, so maybe I'll be able to submit it tomorrow. ;)

Awesome!

I'm a fan of how Maui deals with lateral navigation. Totally agree with distinction between tabs and non-editable views, as I had expressed in the 'unify how to navigate in an app' task.

Here is some quick mockups.

In T13012#227542, @squeakypancakes wrote:

Here is some quick mockups.

I like the bottom right one: it has the appearance of a smaller version of the SwipeNavigator component, which I think is a +1 for consistency.

In T13012#227542, @squeakypancakes wrote:

Here is some quick mockups.

Keep in mind that the same component should be used to navigate the main views of an application

In T13012#227542, @squeakypancakes wrote:

Here is some quick mockups.

I like the bottom right one: it has the appearance of a smaller version of the SwipeNavigator component, which I think is a +1 for consistency.

The bottom right mockup looks very similar to the original mockup idea which I had for the tabs, it looked like this:

The only different is that the tabs are centered, and the underline is thicker. However, nobody really seemed to like that idea, because they thought that the tabs seemed detached from the window. I actually kind of like the bottom left, however I have no idea how to implement that...

In T13012#227542, @squeakypancakes wrote:

Here is some quick mockups.

Oh I love the top right one, or the top left one without the horizontal lines on either sides of the pills.

I think it comes down whether you prefer Apple/ElementaryOS style (floating grouped pills with text inside) or Google/Android style (floating text with lines underneath). I prefer the former because the grouping and exclusive nature of the items is clearer, and I also just prefer UI elements that have defined boundaries.

We could have an option...? I like both, but it's a bit out of my scope to do the EOS/macOS ones. :/

In T13012#227542, @squeakypancakes wrote:

Here is some quick mockups.

I like the top right one as well.

OK, it seems like mostly everybody likes the top-right, and I think I've figured out how to implement it. So please don't do this anybody else, because I'd like to have something to submit for KDE. :) However, before I jump into it, I would like to clarify a few things.

First of all, it seems like one of the goals of this task are to have two different tab styles for mutable and unmutable tabbars. Clearly the pill-tabs won't work in dolphin or kate, for example. So in those apps should we keep the current tab style, use Material/Gnome/Windows tabs, or Mozilla/Firefox style tabs? I think it will be quite simple to detect whether tabs are mutable in the breeze code, we'll just have to see if the tabsClosable() property is true or not, because all mutable tabs scenarios that I can think of also involve the tabs being closable. (I think?)

Second, I think that for mutable tabs, their corners should NOT be rounded, although @ngraham disagreed with me. (sorry for the shouting) The reason I think this is because then apps will be allowed to place the tabbed UI next to the toolbar and sidebar without gaps, like in @manueljlin's mockups, and that looks really nice. Already, apps like Konsole and Kate do this: in the case of the former, the tabs are not rounded because they're right up at the edge of the window, and in the latter, they completed overrode the current tab style.

Also, I noticed that in some place on Plasma, for example the audio widget, material style tabs are already in use. If we change the tab style, will we also need to change these?

What does everybody think? (btw I joined the VDG :-) )

Carson in already implementing it for Kirigami in D28873 :-/ it could asozbe implemented in qwidgets, but it should have the same look

In T13012#227634, @abstractdevelop wrote:

OK, it seems like mostly everybody likes the top-right, and I think I've figured out how to implement it. So please don't do this anybody else, because I'd like to have something to submit for KDE. :) However, before I jump into it, I would like to clarify a few things.

First of all, it seems like one of the goals of this task are to have two different tab styles for mutable and unmutable tabbars. Clearly the pill-tabs won't work in dolphin or kate, for example. So in those apps should we keep the current tab style, use Material/Gnome/Windows tabs, or Mozilla/Firefox style tabs? I think it will be quite simple to detect whether tabs are mutable in the breeze code, we'll just have to see if the tabsClosable() property is true or not, because all mutable tabs scenarios that I can think of also involve the tabs being closable. (I think?)

Right those are mutable tabs: They can be re-arranged, opened/closed, renamed, and hold content views. So those will continue to use the current "tab-like" style. We only want to use this new style for navigation between different kinds of views: multiple pages of a settings window, multiple views of a sidebar (e.g. in Okular or Gwenview), and so on.

Keying off of the tabsClosable() property makes sense to me.

Second, I think that for mutable tabs, their corners should NOT be rounded, although @ngraham disagreed with me. (sorry for the shouting) The reason I think this is because then apps will be allowed to place the tabbed UI next to the toolbar and sidebar without gaps, like in @manueljlin's mockups, and that looks really nice. Already, apps like Konsole and Kate do this: in the case of the former, the tabs are not rounded because they're right up at the edge of the window, and in the latter, they completed overrode the current tab style.

I could probably be persuaded of this. You make a good point.

Also, I noticed that in some place on Plasma, for example the audio widget, material style tabs are already in use. If we change the tab style, will we also need to change these?

Personally I support the initiative to make Plasma use a visual style that's closer to apps, but this is not universally-agreed-to IIRC so I think it would need more discussion.

What does everybody think? (btw I joined the VDG :-) )

I think it's a great plan! Welcome aboard! We're happy to have your participation and contributions.

Ok, thanks Nate! And I don't know anything about Kirigami, so I don't mind somebody else doing that @niccolove! ;-)

In T13012#227542, @squeakypancakes wrote:

Here is some quick mockups.

I honestly am mixed between preferring bottom-left and bottom-right. Bottom-left feels perfectly in line with the New Breeze Design demonstrated thus far in concepts, but at the same time bottom-right does still fit in and provides consistency with the current Plasma Styling, as well as potentially other widgets I do not know about right now. One thing is for sure, though - that border around the bottom-left one, if we have that sorta style chosen anyway, is definitely a nice design detail to convey what is changing in the tabs and would allow us to in the future add controls outside of tabbed views while keeping controls outside of tabs looking more natural than without.

Could you please try a combination of 2 and 4? I am curious how that would look like.

In light of the discussion about https://invent.kde.org/kde/okular/-/merge_requests/156 and the new Calligra design, I'm starting to wonder if the pill tabs really will look good. In System Settings, definitely yes. In Okular or Calligra... I'm not sure. :/

Yeah I'm also starting to become convinced that the pill-style tabs are not the best approach, though I love them in the abstract. In those screenshots, we have a certain style for sidebars in config windows: a light blue background with a darker blue bar on the edge facing the content view. I wonder if we could just do the same thing for top tabs, but with the bar on the bottom edge rather than a side edge. IIRC @cblack has been working on this for Kirigami. My only objection to this style is when the tab bar is unbounded, or free-floating; I just don't think it looks good to have colored rectangles and text floating in space. But when a tab bar using this style is framed by adjacent views (as with the sidebar case we already have), then those views provide the necessary visual anchoring and I think it looks great! IMO if we can commit to that, we could probably use that style everywhere for non-editable views.

In T13012#228345, @abetts wrote:

Could you please try a combination of 2 and 4? I am curious how that would look like.

In T13012#228356, @ngraham wrote:

Yeah I'm also starting to become convinced that the pill-style tabs are not the best approach, though I love them in the abstract. In those screenshots, we have a certain style for sidebars in config windows: a light blue background with a darker blue bar on the edge facing the content view. I wonder if we could just do the same thing for top tabs, but with the bar on the bottom edge rather than a side edge. IIRC @cblack has been working on this for Kirigami. My only objection to this style is when the tab bar is unbounded, or free-floating; I just don't think it looks good to have colored rectangles and text floating in space. But when a tab bar using this style is framed by adjacent views (as with the sidebar case we already have), then those views provide the necessary visual anchoring and I think it looks great! IMO if we can commit to that, we could probably use that style everywhere for non-editable views.

Is this what you are talking about?

Yep!

Although in that view, the adjacent tab bars kind of look a bit odd butted against one another, hmm.

Shouldn’t this be added to T10891?

In T13012#231382, @achauvel wrote:

Shouldn’t this be added to T10891?

Sort of. That task is mostly about the UI, where this task is sort of more UX than UI, still. I guess it's related enough.

My two cents here:

In T13012#228360, @squeakypancakes wrote:

After seeing that one, and the original 4 styles, I think the best might be a combination:
This one basically, but on its own and slightly rounded. Or maybe like that when it makes sense, but standalone and rounded in cases when it would cause visual problems demonstrated here, or the layout doesn’t surround it well enough.
As for the view frames, I think a thin horizontal line, maybe fading into the background towards the ends, is enough, a full frame is not needed, and those horizontal lines look best when they are centered with the tabs. Of course these lines only need to be there when the rounded standalone version is used.

Or is that double style too messy? Is uniformity preferred instead (of it harmonizing with its surroundings in all cases)?

Is this thing still being worked on? This was looking great, with nice ideas.

This was implemented in Kirigami and it's waiting for a QWidgets counterpart