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