Thanks for the mockups! Some initial remarks after looking at it for a couple of minutes:

• Open configuration module is orthogonal to extend to the left / right
• What's the use case here? (I know, initial setup, but kscreen remembers settings, so I'd only want to get the config module for unknown hardware combinations, so this is a lot more complex than just one checkbox
• The user can't delete a config, so the "new display" thing is not reversible (i.e. once set up, no way to get this behaviour back)
• Checkboxes and radios in the previews seem really hard to make look good (not that I've tried)
• I'm unhappy about an advanced section, is that really necessary (currently, it's only refresh rate under this, which makes the advanced completely pointless)
• Like in the original design, the relationship between refresh rate and the resolution is not clear
• The rotate button on the previews seems cumbersome to use (we can only rotate in 90 degree snaps, meaning we'd have to do some really brutal snapping), also, rotating stuff by dragging is very cumbersome

I received feedback that for the case of just one screen, this UI is complete overkill, is there something we can do about that (short of doing a completely different UI when only one screen is connected)?

As to scaling the kscreen kcm ui live while dragging ... I'm not so sure about it. It does sound neat, but it also bears the risk of UI bits falling outside of the screen (and thus input area), window being repositioned (if we choose to do so), and at the very least the slider control slipping away under the mouse. Sounds like a nice idea in theory, but it has so many problems attached to it, I'm not sure we want to go down that route.

OTOH, the modal scaling dialog we currently have is not beauty queen either.

displays on top of each other is a perfectly valid case, also with different resolutions, so I'm not sure this would

• work well
• be discoverable by users

Thank you for the feedback! Let's see...

• Open configuration module is orthogonal to extend to the left / right

The idea was that if set to extend, it would just extend and not open the KCM when a new screen is plugged in, so that people who for example plug in different projectors often would have something that "just works" without doing any configuration.

• What's the use case here? (I know, initial setup, but kscreen remembers settings, so I'd only want to get the config module for unknown hardware combinations, so this is a lot more complex than just one checkbox

That's why it says "new display". It would only happen for new hardware. As said above, this happens often e.g. for people who go from conference to conference, plug in new projectors all the time and don't want to do any set up each time.

• The user can't delete a config, so the "new display" thing is not reversible (i.e. once set up, no way to get this behaviour back)

One can open the KCM manually at any time. That combobox is only meant to set the automatic behavior when a new display is plugged in and the user does not want to set up anything manually. You can always go into the KCM later and change anything about that display to your heart's content.

• Checkboxes and radios in the previews seem really hard to make look good (not that I've tried)

Let's see if our "making things look good experts" can come up with good ideas. If not, we have to revisit this idea.

• I'm unhappy about an advanced section, is that really necessary (currently, it's only refresh rate under this, which makes the advanced completely pointless)

If resolution is indeed a common thing to change, then the advanced section indeed does not provide benefit. I'll kill it, then.

• Like in the original design, the relationship between refresh rate and the resolution is not clear

Bold idea: Are there valid usecases for manually reducing the refresh rate to anything lower than the maximum possible at the current resolution? Or, actually, do modern displays even allow for manual control? If not, we could just remove the combobox and instead add the max refresh as information to the resolution slider label (e.g. 1024x768, 60Hz).

• The rotate button on the previews seems cumbersome to use (we can only rotate in 90 degree snaps, meaning we'd have to do some really brutal snapping), also, rotating stuff by dragging is very cumbersome

Alternative: Just put rotate left/right buttons in there instead. I don't think upside-down is exactly a common usecase anyway, so having to click twice to get there would not be much of a problem.

I received feedback that for the case of just one screen, this UI is complete overkill, is there something we can do about that (short of doing a completely different UI when only one screen is connected)?

We could just hide the controls for enabled and primary if there is just one screen. Yes, that would still leave a box with just one screen in there, but I don't think that adds too much to perceived complexity.

Compared to the current UI, we'd then get rid of:

• The "Primary Display" combobox
• The "Enabled" checkbox"
• The "Orientation" combo because that would be on the screen
• The "Unify outputs" button

Or did the people who gave you that feedback explicitly complain about the box showing one display?
If I look at the current UI, it does look quite complex, but mostly because of all the stuff below that box, not the box itself.

displays on top of each other is a perfectly valid case, also with different resolutions, so I'm not sure this would

• work well
• be discoverable by users

I'd like to see if the offset solution I'm proposing would work. I can't tell that yet, but I don't really see why it wouldn't either. And having cloned displays stacked at the same position in the visualization is quite logical from a mental model perspective, isn't it?

For the interaction, what I have in mind is that people would just roughly drag one on top of the other (as the instructional text above says) and then it would snap to that offset stack visualization, where people could click any of the screens below to raise them to the top and select them.

The only downside I see there is that if you have several screens all cloned, you have to click through them to see which is which. I don't know if that is such a common usecase, however. The more common one seems to be to just clone two displays.

As to scaling the kscreen kcm ui live while dragging ... I'm not so sure about it. It does sound neat, but it also bears the risk of UI bits falling outside of the screen (and thus input area), window being repositioned (if we choose to do so), and at the very least the slider control slipping away under the mouse. Sounds like a nice idea in theory, but it has so many problems attached to it, I'm not sure we want to go down that route.

Alternative idea: Just replace the content of the box at the top with a scaling preview as long as the slider has focus?

I'm not convinced by the layering.

You say it matches the mental model, but I don't think that's actually the case: you normally drag the screens in the KCM to match how they're on your desk, not "create a large virtual display". To me, the fact that I could even put displays on top of each other wasn't evident until I fixed bugs where this case happened.

Also, I don't think it's intuitive at all, just a tad better than the current misaligned clone button, but not by much. The drag-and-drop interaction becomes more cumbersome on the other hand, because you have to re-layer and adjust z-index, etc. It won't be pretty is what I'm afraid of.

On the top of resolution vs. refresh: Yes, there's a clear case where this matters. Graphics cards support a maximum resolution at a specific refresh rate. If you lower the refresh rate, you can get higher resolutions (and sore eyes), if you decrease resolution (possibly below the display's native res), you can get higher refresh rates. They're really inter-dependent. (Think of the product of number of pixels and refresh rate, that's the maximum bandwidth the graphics card can push to the display.)

also note that with the current layout (allowing to drag panels on top of each other) is possible to have screens just partly overlapping, which can give really broken looking plasma setups (like half a panel floating in the middle of one screen) for which i have no solutions for, besides trying hard to end up with such setups

Sliders have focus technically, but I'm not sure users understand that they should focus something else to have the slider reveal. Perhaps showing some tooltip-like preview?

On the top of resolution vs. refresh: Yes, there's a clear case where this matters. Graphics cards support a maximum resolution at a specific refresh rate. If you lower the refresh rate, you can get higher resolutions (and sore eyes), if you decrease resolution (possibly below the display's native res), you can get higher refresh rates. They're really inter-dependent. (Think of the product of number of pixels and refresh rate, that's the maximum bandwidth the graphics card can push to the display.)

Sorry, misunderstanding. What I meant was "Is there a valid case to set the refresh rate independently of the resolution?" Since they are interrelated, why don't we just let the user drag one slider and inform them about the effect that would have on both resolution and refresh rate (which would always be the maximum possible with a given resolution), instead of having them set both independently?

That could work, but it needs a conscious choice if we allow the user to set up a sore eyes config (high res at low refresh rate).

I think right now, we just update the refresh combo and be done with it.

You say it matches the mental model, but I don't think that's actually the case: you normally drag the screens in the KCM to match how they're on your desk, not "create a large virtual display". To me, the fact that I could even put displays on top of each other wasn't evident until I fixed bugs where this case happened.

To find out whether it's intuitive or not, we can do some really simple user testing: Show people that mockup (without the annotations of course) and ask them what they'd do to clone a display. If they get what they need to do, it works, if not, we need something else. There is not even any interactive prototype needed to test that.

To test how well the interaction with the stack works in practice, some more interactive prototype would be needed, of course.

The thing is: I don't see a much more intuitive way to do this. If we do placement in general in the visual drag& drop widget, but cloning by a different means, we create a disconnect between the two, which would make setups like "Clone these two, but extend a third to the side" (which is a valid usecase if you e.g. want to have your primary action both on your display and on a projector, but have another small screen to show your notes) pretty difficult to do.

We could maybe do a different visualization in the detail, but I don't see a way around showing that two physical occupy the same place in your virtual screen.

That could work, but it needs a conscious choice if we allow the user to set up a sore eyes config (high res at low refresh rate).

I think we should allow it (while making the effect on the refresh rate clear to the user by showing the it right with the resolution slider), but if we don't want to, we should just limit the resolution slider to those values that allow max refresh rate and not show any info about refresh rates at all.

I think right now, we just update the refresh combo and be done with it.

We do, and that's a problem because that combo box is set to "Auto" by default so the user does not even see the change unless they click it.

As I said: If there is no reason to set the rate to anything lower than what's possible with the current resolution, we should just eliminate that combo box.

The max refresh rate isn't a fixed thing, really. There's certainly a sensible maximum refresh rate, that's 60Hz (since that's what KWin renders at), but there are people who want / need a higher refresh rate, gamers for example. So we either limit the slider combo to only resolutions that allow at least 60Hz, we'll limit people to operate their hardware on the resolution limit and won't allow to use a display at 30Hz. Perhaps the best is to show all resolutions, pick the max refresh rate for a given resolution (the current "auto" setting), but warn the user that this mode has a low refresh rate and advise to pick a lower res with a higher refresh rate? This would allow users to shoot themselves in the foot, but makes it a bit more intuitive to pick what's sensible for the eyes.

Perhaps the best is to show all resolutions, pick the max refresh rate for a given resolution (the current "auto" setting), but warn the user that this mode has a low refresh rate and advise to pick a lower res with a higher refresh rate? This would allow users to shoot themselves in the foot, but makes it a bit more intuitive to pick what's sensible for the eyes.

Sounds good! I'd still always show the actual refresh rate that you get with any given resolution, but showing an additional message when selecting a resolution that would result in a problematic refresh rate makes sense.

I've updated the main mock.
Changes:

• Disabled displays are now in a separate box. Rationale: A disabled screen cannot ever be part of the screen setup anyway
• Rotation is now done via rotate left/right buttons
• Setting Primary display is done via positioning it in a box in the center. Rationale is that in most cases, the primary display will be in the center of the physical setup as well. Of course one can decide to e.g. only put further screens to the right of the primary screen if one does not want the center screen to be the primary one
• Advanced section removed
• Refresh rate setting removed, is now integrated in resolution

The second image shows the scaling preview.
It should be shown while dragging the slider with the mouse, and if one focuses the slider with the keyboard in order to change it with the keyboard.
We could also show it when just hovering over the slider, but that might make it too busy when just moving the mouse around.

Is the design idea to be more simple and straight forward?

@mart The upside of that would certainly be a clean appearance, but the downside would be that what sebas described as a typical usecase - You only have one screen and want to change its resolution - would then be two clicks instead of one.

So basically it's a decision of whether we primarily want the KCM to appear simple, or whether we want typical usecases to take as few clicks as possible. That is a common decision, because a cleaner base UI can often mean that things take longer to do, because you have to un-hide hidden parts of the UI.
Both are perfectly valid angles, we just have to decide which to take.

On the other hand, we could open in the overlay mode for the single connected display when there's only one screen. When another screen gets attached, we remove the overlay and show the overview with positioning. I haven't made up my mind about that, but maybe it's a viable option down the road, so that's just a first shot.

Otherwise, I'm getting a good gripe on the direction we're going. Whether it's going to be (en evolution of) @colomar's current mockups or @mart's idea, both are going to require very similar changes in the code. Thanks for the mockups, @colomar!

I'm already quite happy with most aspects of these new designs, there's a sense of continuity and polish, but no major departure from its current design. Good work!
One thing that I'm not quite happy with is the primary display selection, I'll post a separate comment about that, as it's really a detail (albeit an important one).

I'll make some time towards the end of the week to look into code changes needed, the QtQuick/C++ bits in the kscreen kcm are a bit crufty, we need a new flag in libkscreen for per display scaling. The kcm is currently a mix of QWidgets and QtQuick, I'll probably want to port that to QtQuick-only. The more tricky bits already are QtQuick, luckily, I hope we can reuse most of that.
It may make sense to have a way of testing old and new alongside for a while, and kill the old version only once we're happy with the new one -- the last thing I want in kscreen is regressions.

On the other hand, we could open in the overlay mode for the single connected display when there's only one screen. When another screen gets attached, we remove the overlay and show the overview with positioning. I haven't made up my mind about that, but maybe it's a viable option down the road, so that's just a first shot.

Of course it would have to be tried out to see how well it works in practice, but it certainly sounds like it's at least worth exploring.