WIP branch: https://invent.kde.org/frameworks/knotifications/-/commits/work/nico/associated-window

Something worth doing could be replacing setAssociatedWidget(QWidget*) with setAssociatedWindow(QWindow*)

I don't see us getting rid of KStatusNotifierItem before 6.0 given that QSystemTrayIcon is missing features

Plasma::PluginLoader still uses X-KDE-ParentApp to restrict some items to a specific parent app. The concept is sound, e.g. there could be a plugin thing that only makes sense with Latte that we don't want to show in regular Plasma.

Plasma theme stuff would become a new framework (for plasma mobile apps etc)

there's two actionable subtasks: Creating new repositories for the SVG and Dataengine stuff

https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/735

For systemtray's inner containment we'd also need a way to add actions, but that doesn't require exposing the full KActionCollection either

This could still be backed by a KActionCollection internally, but it would give us more flexibility in the long term by not exposing that in the API

Instead of exposing them as QMap I'd rather add a function that exposes the actions individually, like in https://invent.kde.org/frameworks/kio/-/merge_requests/997

Is there anything left to do here?

@vkrause can we consider this Done?

@alex is there anything left to be done here that needs to happen before 6.0?

This isn't really a frameworks problem, just something that needs to be ported in apps, so moving this to Done

Given this is new API that we can add any time I'm moving this to low priority

From the QWheelEvent docs:

https://invent.kde.org/plasma/kdecoration/-/commit/4091b18bfef5e1ff8f2924ad18917ebbb14987b0 changes the deprecated posF() to position().

This task is lacking details to be actionable

I don't think this is actionable as-is. As long as we have the current SVG-based theming system for Plasma the Plasma::Theme class is still relevant

Moving this to low-priority since it doesn't really impact the public API

https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/723

https://invent.kde.org/frameworks/kglobalaccel/-/issues/3 outlines some plans I have for kglobalaccel

Consensus at the meeting was to move it to KConfig

https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/732
https://invent.kde.org/plasma/plasma-desktop/-/merge_requests/1390

https://invent.kde.org/frameworks/plasma-framework/-/merge_requests/660

SmallIcon/DesktopIcon/BarIcon/UserIcon/MainBarIcon is done.

I think passing in the ID via a setter would be cleaner, because the full ID has to be typed out for providing the kauth action. Having it once explicitly stated and once derived from some internal string concatenation with the pluginId seems weird.

In T14733#267634, @nicolasfella wrote:

For QML KCMs this is all implemented on the frameworks side.

For KCModule there is one internal usage left: It uses the KAboutData's componentName for some KAuth stuff: https://invent.kde.org/frameworks/kconfigwidgets/-/blob/master/src/kcmodule.cpp#L128

Options here would be to use the same KPluginMetaData-via-ctor approach as for the QML KCMs or passing that id via a setter

https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/185 and https://invent.kde.org/frameworks/kdeclarative/-/merge_requests/183 cleans up the remainder for QML KCMs

https://invent.kde.org/pim/grantleetheme/-/merge_requests/19

As far as I can tell most usages don't actually affect anything, so I don't think there's a practical consistency problem.

PlasmaCore.Units.iconSizeHints.panel is still used a lot

Is this still relevant given that the Qt5-QList behavior doesn't exist any more in Qt6?

WIP branch, not finished yet: https://invent.kde.org/frameworks/kservice/-/commits/work/nico/servicetype/

As long as these still use KIconLoader internally moving them to KWidgetsAddons is not doable.

Do we allow to configure the shortcuts for applet actions in the UI anywhere?

https://invent.kde.org/frameworks/kio/-/merge_requests/1180 cleans up the unused functions

https://invent.kde.org/frameworks/kio/-/merge_requests/1178

https://invent.kde.org/frameworks/kwindowsystem/-/merge_requests/86

The whole thing lives in plasma-workspace now

First steps:

https://invent.kde.org/frameworks/kio/-/merge_requests/1138

see also T12409

How do we proceed here?

https://invent.kde.org/frameworks/kio/-/merge_requests/1137

KWallet has a distinction between LocalWallet and NetworkWallet. By default they are the same, with an option in the KCM for "Different wallet for local passwords". QtKeychain doesn't have such a distinction and always uses the network wallet

In T16044#284836, @davidre wrote:

For service menus KService is used to read it as well
https://invent.kde.org/frameworks/kio/-/blob/master/src/widgets/kfileitemactions.cpp#L602

In T16044#284807, @nicolasfella wrote:

Actually this is at odds with https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/68, which uses KService to read non-application desktop files

Actually this is at odds with https://invent.kde.org/frameworks/kglobalaccel/-/merge_requests/68, which uses KService to read non-application desktop files

For now using QTextCodec is fine for that, it's still available in qt5compat