Considerations:
* In any point of time, the only layout info client might need is about:
- a single layout (the current one)
- list of all layouts configured (e.g to fill context menu entries)
There is no chance it might need to asqure some random layout info
which is not current.
* To get current layout Display Name, client shouldn't have to asqure
the current layout itself first - such dependecy makes code based on
async DBus API unnecessary complicated.
* Shall the layouts context menu be ever desired, it would be easy to
implement by adding both Name lists (Short/Long) and Index getters to
the API.
KWin/P-D parts:
impr: Keyboard Layout DBus API: drop excessive method arguments
No need to reimplement switching to the next layout logic in every QML
code - implemenation is already there on KWin/P-D side
KWin/P-D parts:
impr: Keyboard Layout DBus API: expose switchToNextLayout() method
KWin Wayland initially misused the DBus API and passed Long layout Name
via currentLayoutDisplayName() method which is wrong.
Instead, the new currentLayoutLongName() property should be added,
and Short Name be passed via currentLayoutDisplayName() as it is for
X11.
When layout changes, the country code (or short layout name) should be passed via DBus
from compositor to this C++ QML plugin, and then to a keyboard applet for
indication
CCBUG: 390079
KWin commit: "feat: expose keyboard layout Short Name via DBus"
Summary:
QDBusInterface is useful for runtime introspection but little else.
As we know the interface in advance we can generate the keyboard layouts
interface and have non blocking, easier to read, easier to maintain
code.
Test Plan: Opened lock screen, it had the whole list, cycled between them
Reviewers: #plasma, broulik
Reviewed By: #plasma, broulik
Subscribers: plasma-devel
Tags: #plasma
Differential Revision: https://phabricator.kde.org/D22846
Andrey Butirsky
David Edmundson