Displays (WIP?)
Open, HighPublic

Description

Mockups

KScreen's current function and user interface is described in https://community.kde.org/Solid/Projects/ScreenManagement/Design

However the system settings module for (multi-) screen configuration is a bit dated, and it shows a number of problems in the UI that can be solved more elegantly:

  • The multi-screen configuration UI is shown even when there's only one screen, which results in a vertical scrollbar a lot of the time
  • It's not immediately clear that selecting one of the outputs in the upper drag and drop area selects the output to configure in the lower section
  • Nerdy and infrequently used settings like Refresh Rate and Resolution are displayed prominently, while the display scaling feature that we're trying to get people to use is hidden away behind a button
  • The drag and drop previews aren't very sexy
  • The window opened for scaling setting and preview is modal and suffers from bugs (the window grows automatically but doesn't shrink; scaling in the preview is applied twice when the display already scaled)
  • The on-screen display for output identification isn't plasma-themed like the other osds
  • There's no visual feedback or quick way to get to the configuration module when screens are plugged in

What would be needed for this task is:

  • Interaction design how these tasks can be done
  • Mockups that solve the above problems and look good
  • Icons / SVGs for common screen setups
  • SVG artwork for the new UI
davidedmundson triaged this task as High priority.Oct 23 2017, 7:53 AM
romangg updated the task description. (Show Details)Oct 26 2017, 5:16 PM
ngraham added a subscriber: ngraham.Nov 5 2017, 4:40 AM

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.

abetts added a subscriber: abetts.Jul 23 2018, 5:49 PM

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?

gladhorn added a comment.EditedJul 24 2018, 9:39 AM

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.

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?

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):


I'd maybe vote for having a label for all options, but in my opinion it covers the common use cases. So I wonder about adding a way of letting users either trigger the OSD from the KCM or integrating the two in some way and offering the drag and drop interface as more advanced option.

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).
ngraham updated the task description. (Show Details)Jul 24 2018, 3:42 PM

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.

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.

bruns added a subscriber: bruns.Sep 7 2018, 9:48 PM