D11459: [WIP] Add plugins for controlling local & remote screen brightness

Nicolas Fella noreply at phabricator.kde.org
Mon Mar 19 00:00:46 UTC 2018


nicolasfella added a comment.


  In D11459#228870 <https://phabricator.kde.org/D11459#228870>, @kossebau wrote:
  
  > In D11459#228727 <https://phabricator.kde.org/D11459#228727>, @nicolasfella wrote:
  >
  > > Nice idea!
  > >
  > > In D11459#228684 <https://phabricator.kde.org/D11459#228684>, @kossebau wrote:
  > >
  > > > My first take on KDEConnect plugins, feedback welcome.
  > > >
  > > > Questions I currently have:
  > > >
  > > > 1. Is this the right way to approach the purpose of remote control of screen brightness?
  > >
  > >
  > > 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)
  >
  >
  > 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?
  
  
  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
  
  > 
  > 
  >>> 2. 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.
  > 
  >>> 3. 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

REPOSITORY
  R224 KDE Connect

REVISION DETAIL
  https://phabricator.kde.org/D11459

To: kossebau, #kde_connect
Cc: nicolasfella, broulik, adeen-s, SemperPeritus, ahmedbesbes, daniel.z.tg, jeanv, seebauer, bugzy, MayeulC, menasshock, ach, apol
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kdeconnect/attachments/20180319/ae831aa6/attachment-0001.html>


More information about the KDEConnect mailing list