D26026: refactor: let Control be a QObject

Roman Gilg noreply at phabricator.kde.org
Sun Dec 15 21:37:50 GMT 2019


romangg added a comment.


  In D26026#578484 <https://phabricator.kde.org/D26026#578484>, @davidedmundson wrote:
  
  > > This is a preparatory step to add signals later for watching file changes.
  >
  > I don't think I understand. What for? 
  >  If it's full output configuration going via the disk that would go against the main part of kscreen architecture.
  
  
  It's not for the full output configuration but only certain settings communicated from KScreen KCM to its daemon and which are not communicated through KWayland / XCB. For now I do/plan it for:
  
  - Output retention
  - If the refresh rate is automatically chosen or set by user explicitly.
  - If the resolution is automatically chosen or set by user explicitly.
  - If the rotation value is automatically chosen or set by user explicitly.
  
  Example rotation: Default is "Automatic". That means if KScreen daemon detects orientation change via sensor it will send new configuration with updated rotation value for internal screen to KWin via KWayland. User now selects "Manual", then KScreen daemon ignores future orientation changes and not send new configuration via KWayland.

REPOSITORY
  R104 KScreen

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

To: romangg, #plasma
Cc: davidedmundson, plasma-devel, LeGast00n, The-Feren-OS-Dev, jraleigh, fbampaloukas, GB_2, ragreen, ZrenBot, ngraham, alexeymin, himcesjf, lesliezhai, ali-mohamed, jensreuterberg, abetts, sebas, apol, ahiemstra, mart
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20191215/0e969907/attachment.html>


More information about the Plasma-devel mailing list