Moved and finished (now works) here: https://invent.kde.org/plasma/kwin/-/merge_requests/17

whops, this created a diff, not a MR

Ping @davidedmundson ?

Strong +1

I agree with a single KCM called wallpapers used to set all wallpaper in System Settings. Not a fan of having so many apply buttons, but I'm sure we can come up with something good.

I'm a bit confused. Aren't we changing the size for third party global themes as well? Do all global themes set their size?

How do you think about putting it horizontally centered at the top of the screen? Maybe even avoiding panels, if possible?
I'd be fine both with "floating a bit under the panel" and "merged with screen/panel top" like krunner.

With the smaller appearance, I'm feeling a bit like it just floats there... for no reason... it gives me the impression than there's no visual connection with anything. It's a bit like it's in a random position, maybe because it's not vertically centered. Could be fine anyway, but I was wondering if there's another place where it would better fit. Maybe top left? Can it avoid panels?

Can confirm. Also, I'd make the tap and hold indicator a bit smaller, maybe half of the size it currently has :-)

I want to see the indicator under my finger, at the current size I can almost see it (maybe my fingers are too thick)

I'm a bit torn about this. It is indeed very nice, but at the same time I don't feel like it's the right solution. Ignoring minor complaints I'd have ("it's a very large button!") it doesn't feel right that the user, in order to change login wallpaper, would think that they have to right click on the desktop, click on edit desktop, click on "login and logout settings", and then change it. I think two other solutions that _might_ be better are:

• Decide that login and lockscreen wallpapers are part of the desktop as much as the desktop wallpaper (which doesn't make sense tech-wise, but it might make sense user-wise), rename "Wallpaper" to "Desktop Wallpaper" in the Desktop Settings KCM and embed directly there "Lockscreen Wallpaper" and "Login screen theme". This would mean
  • Splitting the "Appearance" tab from the Screen Locking KCM to a new KCM called "Lockscreen Wallpaper" which would be in the customize desktop window, thus making the content of the Screen Locking KCM just the "activation tab", but adding a button "customize wallpaper..." which would open the "Lockscreen Wallpaper" KCM
  • Doing the same with the "Login Screen" KCM, which would be split in "Login Screen Theme" KCM (shown in customize desktop) and "Login Screen" KCM (shown in SySe) only containing what now is in the "Advanced" tab, but with a "Customize theme..." at the top. OR - probably better - have only one "Login Screen" KCM which only shows the theme selector and is both on the "customize desktop" and current location in system settings, and add "Advanced" as a button that open up a new kirigami page rather than using tabs.
  • All of which kinda feel ugly from a "let's categorize things based on how they work under the hood" point of view, but instead it could make sense from a "let's categorize things based on what the user expects" point of view.
• OR, show the desktop configuration KCM is system settings, and somehow create a category there for wallpapers?
• OR we just go with what you are proposing. I'm not against it, but I feel it's more of a "limiting damage" than a "let's fix the problem at the root"

Can confirm. Also, I'd make the tap and hold indicator a bit smaller, maybe half of the size it currently has :-)

two fingers swipe gesture to left, right and up as shortcut to navigate back, forward and up

Everything works for me, except two finger gestures

In D28627#652806, @ngraham wrote:

In D28627#652538, @niccolove wrote:

Actually -- this seems to no longer apply panel internal margins?

Works for me.

Should the icons increase by fixed value steps, or smoothly scale as the panel is resized?

I'm not a great fan of button that will be - imo - hardly used by the average user in such a visible location. Also, it takes up some vertical space from the sidebar which isn't great.

+1 for the direction!

Ok, so.
What about a virtual sprint? Who's interested in joining in? It could be in late June / early July.

Are we really sure this is worth exposing to the user?

For some reason, the heading is still one or two pixels off... still, much better than before

Generic +1 to the idea, but:

• I would not go higher than 50 as panel width
• The clock is too small, it probably needs a version where there's a new line between hour and minutes
• We should check that all widgets work correctly in a vertical panel
• Panel should stay in the same edge when screen is autorotated

VDG wise, this looks good and consistent.

Round things up again

In D29479#664767, @broulik wrote:

Notifications don't use PlasmoidHeading

Address some feedback

Remove inHistory change

Sorry, I'll make a different patch for that

I added one last thing: I feel like it was not a good idea to show the heading in history for notifications that are not in group. I added a inHistory bool, false by default, that's set true in FullRepresentation for notifications that are in history. Heading is not shown for any notification in the history.

Address feedback and add inHistory bool

Fix very long application names

Fix very long notification titles

Address feedback

Move lineSvg to root element

Fix visibility

LGTM