For the use-case of video/presentation mediaplayers it can be useful to also
control the brightness of the screen interactively from remote.
Details
Details
- Reviewers
- None
- Group Reviewers
KDE Connect
Diff Detail
Diff Detail
- Repository
- R224 KDE Connect
- Branch
- brightnesssupport
- Lint
No Linters Available - Unit
No Unit Test Coverage
Comment Actions
My first take on KDEConnect plugins, feedback welcome.
Questions I currently have:
- Is this the right way to approach the purpose of remote control of screen brightness?
- How could I integrate the remote screen brightness into the Plasma battery/energy applet? I thought I had heard this was already done for remote battery, but could not see it working or find related code
- How is a remote state properly modeled? How do we know when a plugin should emit change signals and when should it stop doing so?
Comment Actions
Nice idea!
General approach looks alright, one could merge the two plugins into one. If we leave then split I'd like more descriptive names (e.g. BrightnessController and BrightnessReporter)
- How could I integrate the remote screen brightness into the Plasma battery/energy applet? I thought I had heard this was already done for remote battery, but could not see it working or find related code
Maybe something like this https://git.reviewboard.kde.org/r/123263/ @broulik are you still interested in this?
- How is a remote state properly modeled? How do we know when a plugin should emit change signals and when should it stop doing so?
Your approach looks fine. AFAIK the plugin gets destroyed when the connection is lost
| plugins/brightness/brightnessplugin.cpp | ||
|---|---|---|
| 62 | You can use np.set<T>(key, value), no need to squeeze everything in a QVariantMap | |
Comment Actions
Motivation to split was that one might only want control of brightness into one direction. So persons with access to device A can control brightness of B, but not the other way around. Or if there are devices which do not have brightness capability, but should be used to control other devices. Makes sense, or did I miss something otherwise possible with plugin settings?
Was following the naming patterns of existing plugins, but happy to rename if some newer naming patterns are now recommended.
- How could I integrate the remote screen brightness into the Plasma battery/energy applet? I thought I had heard this was already done for remote battery, but could not see it working or find related code
Maybe something like this https://git.reviewboard.kde.org/r/123263/ @broulik are you still interested in this?
Ah, darn, I hoped I just had missed some settings in the UI.
- How is a remote state properly modeled? How do we know when a plugin should emit change signals and when should it stop doing so?
Your approach looks fine. AFAIK the plugin gets destroyed when the connection is lost
I might not have read all documentation. No clue so far how the lifetime of a plugin instance is managed. For now I guessed there is one plugin instance created per connected & seen device, if enabled with that device. So is the instance created when the device has been found at runtime, and then is deleted again if the device is no longer visible?
Comment Actions
Makes sense. Given that complexity will grow I would leave them separated
Was following the naming patterns of existing plugins, but happy to rename if some newer naming patterns are now recommended.
The existing one confuse me sometimes. Might change that someday
- How could I integrate the remote screen brightness into the Plasma battery/energy applet? I thought I had heard this was already done for remote battery, but could not see it working or find related code
Maybe something like this https://git.reviewboard.kde.org/r/123263/ @broulik are you still interested in this?
Ah, darn, I hoped I just had missed some settings in the UI.
- How is a remote state properly modeled? How do we know when a plugin should emit change signals and when should it stop doing so?
Your approach looks fine. AFAIK the plugin gets destroyed when the connection is lost
I might not have read all documentation. No clue so far how the lifetime of a plugin instance is managed. For now I guessed there is one plugin instance created per connected & seen device, if enabled with that device. So is the instance created when the device has been found at runtime, and then is deleted again if the device is no longer visible?
I think so, you could add some Logs to contructor, connected() and destructor to verify
| plugins/brightness/brightnessplugin.cpp | ||
|---|---|---|
| 52–53 | I guess this should go, it gives an error and I don't see from whom it should request that | |
Comment Actions
- remove wrong requestBrightness in BrightnessReporter
- use wrong commata in json
- use np.set<T>(key, value) over passing QVariantMap
| plugins/brightness/brightnessplugin.cpp | ||
|---|---|---|
| 52–53 | Ah, forgot to remove (left over from initial version which had both plugins in one :) ). | |
Comment Actions
Works neat! Let's talk about a proper UI for it. I've created a simple Android UI. For the desktop-to-desktop use case (did you actually know that you can pair two desktops?) we could add a slider to the plasmoid. Another place to add it could be the Kirigami app (the one hidden behind EXPERIMENTALAPP_ENABLED) which I hope we can use for Sailfish as well
| plugins/CMakeLists.txt | ||
|---|---|---|
| 31 | I would move it out of the if branch, at least brightness as it's not related to the Kirigami app | |
Comment Actions
Nice. I had not tested any functionality myself yet :P So far only drafted the code to get an idea how such plugins are done (though by example of real world needs idea). Fancy to see this turn so quickly into a real product. kdeconnect seems magic :)
I've created a simple Android UI.
Cool, saw the review request and will see to test this tonight.
For the desktop-to-desktop use case (did you actually know that you can pair two desktops?)
Yes, even multi-seat on the same device. Surprised no-one has yet extended multiplayer kde games to work across kdeconnect pipes? :)
we could add a slider to the plasmoid.
Yes, until we can hook that into Solid, would be something for the start. Not yet looked at the plasmoid code. Does it have some plugin-based UI as well, or would we hardcode that for now?
| plugins/CMakeLists.txt | ||
|---|---|---|
| 31 | oh, I missed the "APP" in "EXPERIMENTALAPP_ENABLED". would move both then, hoping we will find a way to use the brightnesscontroller from the kdeconnect plasmoid. | |
Comment Actions
Shouldn't it be part of the application workflow? I'm afraid we may be doing something ad-hoc where it's not required.
Maybe we just need an action that is "100% brightness". In fact this can be somewhat easily be implemented with RunCommands too.
Comment Actions
The use-case which inspired me has been this: using laptop with big screen for movie watching in the evening. as it got dark outside, the screen had been too bright by the time, so brightness needed adaption. later light in room was turned on, again need to adapt brightness to match. Being able to do with remote control by kdeconnect on the mobile avoids having to leave comfortable position and interrupt movie watching by stepping in front of device, also allows immediate check if new brightness is okay (no need to sit back just to stand up again to tune brightness some more). And only needs one hand, so other can keep holding the drink/beer bottle :)
I think this is less app specific, but a general purpose remote control feature for the screen of some device (think also e.g. Pi-based entertainment/info center).. Just like the brightness control built directly into a device also is general purpose (function key handlers working independent of current app running, Battery & Brightness Plasma applet also being general purpose control, not app specific. The idea here with kde-connect would be to have a simple remote proxy for that control.
Comment Actions
- do not depend plugins on EXPERIMENTALAPP_ENABLED
- add brightnessMin (to handle 0 meaning screen off for some drivers)
| plugins/remotebrightness/kdeconnect_remotebrightness.json | ||
|---|---|---|
| 23 | I somehow expected that this controls which plugins are shown as available for a given device. But when I had disabled the counterpart plugin ("kdeconnect_brightness") on another device, so it had no active plugin supporting the respective incoming & outgoing packet types, this plugin here is still active in the lists of plugins for the connection to that other device and can be even enabled.. So unless I made a mistake somewhere, what would be the recommended thing to do to know if a remote device has an active counterpart for the given packet types? | |