Saturday, 2021-04-11 KF6 meeting notes

Ahmad Samir a.samirh78 at gmail.com
Sun Apr 11 12:36:39 BST 2021


Hello, we held the second ever KF6 weekly meeting yesterday, and here are the meeting notes, taken 
by Luigi Toscano (lightly proof-read by myself).


Investigate replacing KSelectAction with QActionGroup (<https://phabricator.kde.org/T12097> )

Moved back to backlog, because it (most likely) doesn't require any input. Nicolas Fella will check 
whether any work is really needed.

------------------------

KGlobalAccel cleanup and improvement for desktop files (<https://phabricator.kde.org/T12063>)

A bit of recap:

* the original API has some issues (see the ticket)
* some time ago it was changed to accepte a desktop file with shortcut definitions, but the code is 
not trivial

The question is: should we support only the desktop file as a way to define the global shortcuts?

Probably fine for applications, it may not work for plasma or kwin, which have a lot of actions. A 
huge file with all actions would be needed. But in fact anything that can be installed can install a 
desktop file.

The discussion moved to some cross -framework dependencies (powerdevil uses kxmlgui to access 
shortcut stuff for example), and to the question on whether KGlobalAccel should be part of 
Frameworks or Plasma.

In short, KGlobalAccel is made of an API and a daemon.

The deamon is really Plasma-specific, but there are really no drawbacks of keeping that in 
Frameworks, as long as the code is fixed to never trigger it outside Plasma (not even through 
dbus-activation). Right now it can happen and it leads to bad interference with other DE's shortcuts 
API (e.g. GNOME).

The API can probably stay as it is. While the only implementation is on Plasma, it may stay with the 
current Windows/macOS code to allow people to easily compile it on those platforms without #ifdefs, 
and smart enough to disable for example the global shortcut creation integration in KXMLGui when 
running on other platforms.

Future contributors may decide whether a) revamp the platform-specific backends or b) create a new, 
really multiplatform API which would use KGlobalAccel as Plasma backend.

------------------------

Create replacement for KPluginInfo::kcmServices (<https://phabricator.kde.org/T13555>)

The work is mostly done: a refactor of the way plugins and their KCMs are associated, with a direct 
link in the plugin definition instead of the complicated code which runs right now (and which relies 
on a deprecated classes).

The pending question is whether to allow each plugin to list multiple KCMs (which would cover some 
use cases, like Kontact plugins, even though those don't use this mechanism right now). After some 
discussion, it seems there is really no drawback on using a list of KCMs instead of a single KCM.


What we forgot to do is pick the tasks for discussion for the next meeting, so if you have 
suggestions please post them somewhere (on this ML would work best).

-- 
Ahmad Samir


More information about the Kde-frameworks-devel mailing list