Hi, are there any details about this? I might put some work into this. I think the arranging of several screens by drag and drop is quite clumsy at the moment. The OSD should also be considered, it solves a lot of the common cases. Maybe the kcm and OSD should be closer coupled to help people.

In T7254#152422, @gladhorn wrote:

Hi, are there any details about this? I might put some work into this. I think the arranging of several screens by drag and drop is quite clumsy at the moment. The OSD should also be considered, it solves a lot of the common cases. Maybe the kcm and OSD should be closer coupled to help people.

Can you please provide context for the comment? Are you referring to a specific KCM, something different?

My understanding was that this task was about the displays kcm. I'm curious if there are more ideas around the kcm. Looking at https://phabricator.kde.org/M112/434/ there are some ideas for the screen kcm, but it seems very incomplete.

In T7254#152541, @gladhorn wrote:

My understanding was that this task was about the displays kcm. I'm curious if there are more ideas around the kcm. Looking at https://phabricator.kde.org/M112/434/ there are some ideas for the screen kcm, but it seems very incomplete.

In the mockup, I took the first screen that is shown in the current KCM and simplified it. We can talk through it so that we can understand where it is coming from. What are some other questions that you have about the proposed KCM?

https://phabricator.kde.org/T3464 has a bunch of ideas.

OK, let's step back then :)

What is the KCM for?

• Arrange several screens (left/right/mirror/one display off) some people have many screens, potentially positioning them so that they are aligned at the top/bottom/left/right
• Rotate screens
• Scale when highdpi (either for all screens or better for each screen individually, which is better supported with wayland)
• Select a primary screen, this is where the plasma panel goes by default
• Set a refresh rate per screen

Then there are several on screen displays:

• identify screens (shows a popup on each screen with the screen name)
• quick settings offering:
  • external only
  • internal only
  • mirror
  • external left
  • external right

I actually like the on screen display (osd):

The current KCM doesn't make it very clear that the user is configuring the screen they clicked in the upper part. That also is troublesome without mouse.

Let's take an even bigger step back! :)

From a user perspective, the KCM is for configuring:

1. How big everything is on the screen
2. When multiple screens are connected, how they're arranged, how big things are on each one of them, and which one is the primary screen
3. (Uncommon) How any of those screens are oriented
4. (Very uncommon): The resolution or refresh rates of any of those screens

Therefore my conceptual recommendation would be to optimize for the common case and follow "Simply by default, powerful when needed." How about this?

1. When there's only a single screen, don't show the UI for manipulating multiple screens; it's completely unnecessary and takes up the valuable top part of the window. That should save a lot of space and make the KCM much simpler and more approachable overall. When a second screen is connected, the KCM can show the multi-screen configuration UI.
2. Emphasize the display scaling UI over the resolution changing UI. Today, it's very rare for people to ever manually change their screen resolution. Instead of hiding the display scaling UI behind a button, we could put that right on the main page of the KCM. This is what Apple does these days:
   
3. Hide the resolution and refresh rate controls behind an Advanced KCollapsibleGroupBox. Possibly the rotation controls too (undecided about that).

I'm centralizing the discussion here so we don't have three Phab tasks tracking the same thing. I've migrated the original description (with some editing) from T3464.

I like the direction, that makes a lot of sense. I wonder what to do about the primary screen. Making the single screen use case more simple is good, I didn't think about it since I almost never use the kcm for that, but it's certainly relevant.
Another point to consider is font DPI, which is currently in a different place in system settings, but very related to the scaling.

In T7254#152624, @gladhorn wrote:

Another point to consider is font DPI, which is currently in a different place in system settings, but very related to the scaling.

It shouldn't be that related any more on Wayland. Or let's say not necessary at all for most people to change anymore, since Wayland scaling is perfect out of the box after we have squashed all bugs.

In regards to single display case: I could imagine that the single screen should then stretch over the full "screen position area", but this area then become a constant size, such that the controls always have enough space. Or not show the area at all. I would try to avoid a rewrite of the position area, because it's already in QML.

When there's only a single screen (the common case), I think it's pretty clear that everything in the KCM is about the single screen that you're currently looking at. IMHO no need to have a separate "here's your screen!" UI.

I think the font DPI setting needs to be much more hidden or even disappear completely IMHO. I see people using it because they say that the scale factor system doesn't work well enough for them, but all it seems to do it replace those bugs with a different set of bugs.