+1 from me.
does it need to go into next release or can also get in next+1?

In T10201#228340, @ngraham wrote:

Thanks! Keep in mind that we want this to apply to 3rd-party apps as much as possible as well. Even for apps that only get a KWin-drawn SSD titlebar, we still want that titlebar to have the same background color as the whole Tools Area on a KDE app.

is a final color set decided for this?
https://phabricator.kde.org/D29232#inline-167074

call it Header

D29232 tries to add a new color group, with experimental support for a cmpletely speared set for the "inactive" case

• comments++

In D29157#656640, @ngraham wrote:

Heh, clever!

However if System Settings is already open and you use KRunner to open a KCM, it switches focus to that existing System Settings window but doesn't show you the thing that you just opened.

• load a new module when a new instance is invoked

• move here faces and packagestructure

• move faces and packagestructure to libksysguard

• use the new face library

• move all face-related stuff in own library
• use the new face library

in the end, just centered vertically the sheet in 812238afdcb7

• add missing file

looking a bit at the problem and at how KColorScheme works, my proposal is the following:

• have a new group in KColorScheme, independent from window titlebar colors, called ToolsArea, HeaderBar or something like that.
• Breeze QStyle would use that kcolorscheme group for the top titlebar only
• Apps can use it for extra things if they want
• the breeze decoration, would use that new group, and *not* the [WM] group, which doesn't have enough colors for actual widgets to work into (just like oxygen which doesn't use those colors)
• if there is a setting in the decoration or somewhere else, the actual decoration would use this group only there.
• Ideally, KDecoration (and somewhere in the styles?) could have some api to advertise if this fusion of titlebar/toolbar is supported by the moving parts

Is on the right track but I think the technical approach needs more discussion, i think something needs to be encoded into KColorScheme, like a new color group (probably independent from titlebars actually)

In D29064#654956, @ngraham wrote:

Foor fod thought: we might want to also think about some of the consequences of removing kcmshell; we could need to add programmatic cross-KCM navigation into system settings itself. For example, in D29080, I'm calling kcmshell from inside a KCM to pop-up the KScreen KCM on top of the fonts KCM.

• use namespace

• remove leftovers

• support for startup module arguments

so, let's try to vertically center when the size is less than the parent

for 5.19, personal preference would be:

• Vera
• Flow light
• altai/rainy morning

Note: the kirigami patch implementing it was wrong, caused crashes and has been reverted.
the way this thing wants to be implemented needs to have 2 parts:

1. a new titlebar (or whatevergood semantic name for it) needs to be added to KColorScheme https://api.kde.org/frameworks/kconfigwidgets/html/classKColorScheme.html#a49fb44861670c838d940c70205318136 so then is easy for qwidget applications to use it (and is also the proper place the kirigami desktop theme should take it from)
2. in Kirigami, also use a colorset just like all the other colorsets, which in the desktop theme would take it from KColorScheme just like all the other things
3. (the half-deprecated) Plasma::Theme should get it too for compatibility

I agree on crystalline to have dull colors...
however, as shapes go, is probably the best of the bunch. Would be possible to contact the author for a differently colored version?

btw may be worth trying to have a stackview that switches between this view and the one before based on page with (wideMode property of pagerow)

if there can't be a super smooth transition between a listview and this thing (perhaps with a stackview, but i'm not sold) then there should always be just the cardlayout with the same cards look, just as a single column

In D28873#652747, @ngraham wrote:

Like you mentioned, don't we want to use the tabbed sidebar view thingy for that?

This patch is about having the whole app navigation as a tabbed thing, so more like tabs in a webbrowser than a generic tabview (with frame and all which this shouldn't have)
so they are 2 different things: i still think a drop in replacement for a tabview will be needed, but this is probably different beast

ok, thanks for the clarification

what's the "tools area"?
are there other use cases than client side decorations? (which we don't want to support)

In D28873#649459, @niccolove wrote:

My opinion from the consistency side: I actually think this is a good possibility for the Consistency goal. After some digging around, my opinion is that

Tabs should only be used on application views that are user-editable (eg: when it's possible to open a new tab or close another).

It's imo appropriate to have a different component for changing views, especially on Kiri. But of course, that component should be consistent. Right now we have big square sidebars, toolbars, etc etc etc etc etc

my concern here using qsettings in this place, is that then it kinda clashes when an application uses its own config like it should, from a framework (kconfiggroup, kconfigskeleton etc)
i always refrained from using any form of config read/write here, and i think we should continue to do so.
Kirigami is a tier1 framework that should do the kleast possible, is more like KGuiAddons/§KWidgetAddons, *not* a full feature kxmlgui, which if we want to have something along the lines, we should have a proper framework to do so, and not tier1

In D28625#642954, @cblack wrote:

Looks like a nice visual improvement.

Are the changes to the scenegraph stuff related? They don't look like a related change to making the Kirigami.Card use the ShadowedRectangle to me.

I reverted this change in the 5.18 branch, as there shouldn't ever be ui changes in stable branches (unless very, very serious)

• port to the new library