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