We have had beta days for the last few releases and they've worked well. We haven't managed to get down to zero .0 regressions, but we've been doing better overall. Closing.

Most of this stuff has gotten done and the remaining actionable thing here is https://bugs.kde.org/show_bug.cgi?id=390817, and we don't need a whole Phab task to track it; closing.

Not super relevant as we just need to do the hard work of manually supporting right-click for apps that still need it and don't have a touch-optimized UI.

@niccolove, isn't this done now? Is your code upstream anywhere?

Closing in favor of https://invent.kde.org/plasma/systemsettings/-/issues/15

Only some cleanups in the json files, will take care of that in the next week.

@alex do you think there's anything left to do here?

that's needed in the pacgages metadata itself, but probably yeah, not needed in the package structure metadata itself, I wouldn't oppose that

This has been implemented with https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1043 for Plasma 5.25! Thanks @The-Feren-OS-Dev!

In T10413#234816, @davidedmundson wrote:

@ndavis can you elaborate on the scenario, I don't understand

Oh, sorry! I already opened some bugs at https://bugs.kde.org/ but this time I had misunderstood the Nate Gragam comment ...

There's already a bug report for this: https://bugs.kde.org/show_bug.cgi?id=281270

Oh hey, we ended up with pretty much just that in Plasma 5.25. :)

I just discovered the module-x11-bell PulseAudio module, which was just implemented in Pipewire's version 0.3.44.

great!

It is quite complex. It's in progress at https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1325

@lavender @ngraham @ognarb
Regarding this feature wish https://bugs.kde.org/show_bug.cgi?id=444676
Do you think it is technically "complex" to implement to have wallpaper derived colors as accent color? So that accent colors will change by Activity?
I wrote "complex" because the term has fallen several times here:
https://bugs.kde.org/show_bug.cgi?id=341143

My favourite of "http://phabricator.kde.org/file/data/6whyyim5gmlkquf4loar/PHID-FILE-wwndftrzby5fixz2nswm/export.png" is the top-right version, because the current presence of iconography is without necessity or benefit, and because removal of it is important for phone-screens because they are primarily vertical and small. Retainment of the title-bar is necsssary not merely because otherwise it may appear to be fake, but additionally because removal of it would be detrimental to consistency, which although is eternally important, is currently especially important: "http://phabricator.kde.org/T11093".

Because the QML port is in progress, I am removing it from the KF6 board

FWIW, Telegram devs have a patch to make dbusmenu-qt code to build with Qt 6 [1], and Arch Linux added CMake patch [2]. From the perspective of an LXQt dev (me), it will be great if those efforts are consolidated.

I'm not a designer but how this looks as suggestion ?

It's dead

@resdex there are no updates. In last KDE Sprint it was decided that such an effort it eould require man power and commitment and there was noone that step in and say, I want this and I will lead the effort.

I guess something I am missing is the "WHY?" part of the argument. Why should Plasma integrate at a default level with Latte?

@mvourlakos Do you have any updates on the current state of this topic?
What I would like to see, when using latte dock, is that it gets rendered before the Desktop is ready.
Right now after the Splash Screen I see my Wallpaper, and it takes 2-3 seconds for latte to start and render the dock.
You can make some beautiful Desktops with latte-dock. It would give plasma a boost if people could generate Global Themes with a latte-configuration that is a 1 click install.

Hey there, has there been any progress here?
The last post is quite old and I'm also interested in solving this issue.

In T14997#266992, @ngraham wrote:

1. Add a page introducing Kickoff since it's a fairly central UI element that's also tucked away in a corner with no text.

In T14997#266390, @ognarb wrote:

I wonder if we should allow distros to add pages? An use-case would be for Fedora to have a button to accept third parties repos (for the codecs/nvidia)

This has been done elsewhere

One weird thing is that when hovering a buttons, the gradients is flipped vertically (or the gradient goes away, it's hard to tell).

These post makes some mention of inconsistencies in some KCMs:

quick note regarding inset: -1 was chosen for compatibility, but obv that won't matter for kf6 :)

I don't think this is a good idea everyone. First, I feel this is basically surrendering our design to the belief that others do better than us. I don't believe that falling into the idea of "the grass is greener on the other side" plays well for an open source project. If there are people who feel inspired by proprietary systems, they have the choice of being able to create their own styles. That's what Plasma enables, but we are not a system copycat. We believe in the power of ingenuity, that means, we believe we propose different ideas for the desktop than others.

Switching to alternate decent layouts can be interesting even for users that have never used the operating systems the layout is based on. It might simply be better suited for their individual computer usage. There is a reason there are a lot of popular tutorials on how to accomplish such changes.

https://invent.kde.org/plasma/plasma-workspace/-/merge_requests/1201
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/692
https://invent.kde.org/plasma/kgamma5/-/merge_requests/5

A welcome app would be a great way to help new users learn about Plasma's incredible features and capabilities

I wonder if we should allow distros to add pages? An use-case would be for Fedora to have a button to accept third parties repos (for the codecs/nvidia)

Sure!

I love it! Are you open to feedback regarding the page content at this time?

I no longer think this is a good idea. :( User feedback suggests that our default UX is too similar to another platform (Windows) already, which puts it in an "uncanny valley" where it is like 80% the same as that platform, but divergent enough to cause frustration and anger.

I no longer think this is a good idea. :( User feedback suggests that our default UX is too similar to another platform (Windows) already, which puts it in an "uncanny valley" where it is like 80% the same as that platform, but divergent enough to cause frustration and anger.

openSUSE has a similar thing:
https://github.com/openSUSE/openSUSE-welcome

Looks really interesting and it could definitely help new users. Can we get a page linking to KDE Social Media and websites at some point?

This looks really cool. I hope this can make it at some point, since it would solve some of my issues with workflow that I have when using activities.

Has this ever been implemented? I need to use a yubikey which requires this.

Some stuff regarding the parent app filtering remains, but that is handled in T14730

In T13889#261518, @alex wrote:

The virtual standardInternal* methods remain, but I guess this can be deprecated too. I am not aware of any applications that use - or might use these methods. If anything they should use the KCoreAddons KPluginLoader/KPluginMetaData.

Ah sorry, I hadn't realised that part was also a mockup. Thanks for the reply. This tabbing in the title bar is a lovely idea though...well if it does not create some other problem elsewhere.

right, gotta keep on topic in my own task

That's a topic for T13467: Theming in Plasma 6 :)

In T14954#264982, @ngraham wrote:

• Delete PlasmaComponents3 and make SVG Plasma styling (if it is kept) get applied via a simple QQC2 style

Sounds like a great plan to me!

• Delete PlasmaComponents3 and make SVG Plasma styling (if it is kept) get applied via a simple QQC2 style

• Delete PlasmaComponents2

• Delete the Air theme (maybe move it into GHNS and have it live in the vdg-extras repo)
• Move the Oxygen theme into the Oxygen repo
• Move the Breeze theme into the Breeze theme

In T12068#264877, @gguerin wrote:

Sorry, slightly off topic, but how do you get the application tabs in the title bar as shown in the screenshot in that comment?? Many thanks

I know this is a bit of necromancy on this task, but it's becoming somewhat relevant with the exceptional design work from the Blue Ocean effort. Breeze has evolved significantly since the original graphics were created, and portions such as the spinners are quite behind the style of the desktop. I wouldn't go as far as to wholesale change the style, but we are due for the cursors to be adjusted slightly so they better fit the Breeze of 2022.

In T12068#223761, @alex-l wrote:

In T12068#223750, @alexde wrote:

Please bear in mind that the dimming may still be too strong for dark themes with a already dimmed screen.

Alright; if this effect becomes rewritten as I guess, it should be possible to introduce an option to satisfy everyone. ;) Thus, it's not necessary to focus on this specific effect now in the further course of the task. Sorry for the detour. :)

Sorry I think there is no difference with dark themes.... the 20%-opacity black rectangle you see below just reduce the contrast between background and text widgets colors. What's matter is the difference between them... Even in a theme where it's intentionally lower a -20% of contrast can't really make a difference...

EDIT: I just checked and the current effect apply a 60% of black, three times more than my mockup. I think it's already a good improvement.

Is this being followed up on the KDE Gitlab? I couldn't find it.

Is this being followed up on the KDE Gitlab? I couldn't find it.

In D26675#678819, @davidre wrote:

we could install an icon into hicolor as fallback

we could install an icon into hicolor as fallback

I see. So the bug is seen only if Breeze icons aren't installed? Because I read that it happened only on some systems, but I didn't know which exactly.

One way to fix this is if sddm have copies of the needed password buttons, then it should work regardless of the installed icon themes.

In D26675#678811, @bharadwaj-raju wrote:

Is there an SDDM issue to track this? Because I edited the file to make revealPasswordButtonShown true, and the button shows up just fine. Which makes me think this might've been fixed in SDDM.

Is there an SDDM issue to track this? Because I edited the file to make revealPasswordButtonShown true, and the button shows up just fine. Which makes me think this might've been fixed in SDDM.

Anyways this doesn't seem like a super pressing issue given that it has happened now once at the end of the lifetime of Plasma5

Here's something we could perhaps do in the meantime: re-serialize the color data to kdeglobals on plasmashell startup if color data is missing or differs from what's in the config file of the active color scheme. This would also fix https://bugs.kde.org/show_bug.cgi?id=384950.

but I'm strictly against doing it for kio/kio-extras