ToolButton should not be used in shared component since it's clints
might have different representation.
Instead, make the component have no visual representation at all,
delegating it to clients themselves.
New error:
/usr/share/plasma/plasmoids/org.kde.plasma.keyboardlayout/contents/ui/
main.qml:17:5: Unable to assign [undefined] to QString
This is because just string is returned and not an object.
The expression should always return struct with proper fields instead.
onWheel is a bit messy with trackpads. It we just compare > 0 our scroll
rate is effectively determined by the refresh rate of the device. Use of
120 "wheels" is a common pattern used elsewhere.
Code is effectively copied from plasma-pa
The switch to previous/next direction I copied what was existing.
Return "layout" and "layoutsList" Properties where all layouts names are
now stored.
getLayoutLongName() DBus method is not used any more so it was also
deleted from DBus API in KWin and P-D, see corresponding commits there.
The Properties interface allows QML code be more declarative.
There is a trade-off though as now we have to:
- store all layout names on client side, even if it's not needed for
base QML layout component here
- duplicate layouts in layoutsList Property as they are also stored in
Action objects of the plasmoid in P-D.
Rework DBus API - getLayoutsList() now provides full details about the
layouts.
Remove Q_PROPERTY's as they are not make much sense here.
Port to a fully event-driven interface towards QML.
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
There were three principal sources of errors and warnings:
1. Un-ported `onFooChanged` statements
2. `config.fontSize` being unconditionally referenced from components
without access to it (it comes from the SDDM config)
3. Accessing units from the context property rather than the singleton
All are fixed now. Tested with:
1. `sddm-greeter --test-mode --theme ~/kde/usr/share/sddm/themes/breeze/`
2. `~/kde/usr/lib64/libexec/kscreenlocker_greet --testing --theme ~/kde/src/plasma-workspace/lookandfeel`
3. `/kde/usr/lib64/libexec/ksmserver-logout-greeter --fakearg`
No regressions found.
BUG: 425349
FIXED-IN: 5.20
Gives them a nicer icon.
The icon does not yet exist in Plasma but gaming-input does, so it falls back to that.
CHANGELOG: Battery Monitor can now show battery levels of gaming devices, such as wireless gamepads and joysticks
Differential Revision: https://phabricator.kde.org/D11571
This allows the theme to decide it does not want us to just show a battery frame
and then add the individual fill pieces but to provide a different battery for
every fill. The current Breeze theme does this by providing a red Fill20 and Fill0
and to prevent superimposing a full red battery ontop of a black one, the Battery svg
can have this item which hides the battery frame.
If a theme decides to manipulate the looks of the "empty battery",
like the current Breeze theme does by painting it red, it can now
provide a Fill0 svg. If it is not present, the old behavior, showing
just the battery "frame" that is, remains.
Alexander Lohnau
Andrey Butirsky
David Edmundson
Nate Graham
Kai Uwe Broulik
Aaron Seigo