Conceptual changes to KScreen
Roman Gilg
subdiff at gmail.com
Sun Nov 25 11:47:39 GMT 2018
On Sat, Nov 24, 2018 at 8:42 PM Nate Graham <nate at kde.org> wrote:
> [CCing visual-design at kde.org]
>
> Hi Roman,
> Could you summarize for less technical people like me what the
> user-facing impact of this change would be? How would this change the
> experience of managing external screens for laptop users? Etc.
>From a user-facing standpoint there is not much change. Certain
display property a user manipulates manually via the KCM are now per
default persistent over all possible configurations of displays (i.e.
which displays are connected) he might change to in the future.
It is assumed this is what most users want for following (per-)display
properties:
* resolution
* scale factor
* rotation
* refresh rate.
In certain rare scenarios user might be interested in saving
properties for one specific configuration only though. Changing the
retention value from the KCM allows that. Also this can be used as a
fallback to current behavior. It is assumed though that only very few
users if at all choose to do that.
Judging by that the current design in
https://phabricator.kde.org/D16997 with the two radio buttons is
sub-optimal. It should be made more clear what the default behavior is
and that changing that is not necessary and probably not desirable in
most use cases.
Another special case is when multiple displays of the same
(brand+)model are connected. Choosing different properties on them
(for example having one rotated and another one not) makes it
necessary to decide if one of them and if so which one should override
the global property values of this model. My current idea would be to
just disallow influencing the global value in case more than one
display of same model are connected and falling back to old /
configuration specific values. But maybe there might be a better
solution, for example such that exactly one of the displays of
identical model type overrides the global values.
More information about the Plasma-devel
mailing list