Setting "Done" stuff to Resolved. (PS: Sorry if this generates email spam..)

Setting "Done" stuff to Resolved. (PS: Sorry if this generates email spam..)

Setting "Done" stuff to Resolved. (PS: Sorry if this generates email spam..)

In D3192#59769, @antlarr wrote:

@hpereiradacosta thanks for reviewing this. Can you cherry-pick the commit for Plasma/5.8?

@hpereiradacosta thanks for reviewing this. Can you cherry-pick the commit for Plasma/5.8?

Thanks !

• Increase width by MenuButton_IndicatorWidth+2 instead of adding a new enum entry

Hi,
I am fine with the commit (especially since it fixes a bug which I have had no time to reproduce)
Now since indeed 2 more pixels are needed on top of the ones from the MenuButton_IndicatorWidth, I would be inclided to just change
size.rwidth() += Metrics::ComboBox_IndicatorWidth into
size.rwidth() += Metrics::MenuButton_IndicatorWidth+2 (with a comment)
rather than adding a new enum in Metrics.
The idea with this enum is that you can in principle change all the values without breaking anything, which is not the case here.
The alternative would be to make the enum be:
ComboBox_IndicatorWidth = MenuButton_IndicatorWidth+2

I will assume this task is done now... or is there more?

Added a secondary suggestion for OSD icons.

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.

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.

@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.

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

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

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.

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.

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

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.

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

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

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?

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

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

I'm not convinced by the layering.

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.

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...

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

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.

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

I have added a mock of a redesign proposal (wireframe status).

Yes, I've looked into the OSD, and it will need almost a rewrite before we can use it sensibly. First, technical issue: the layout to switch to is only known once we switch, and at that point, the screen flickers, so the OSD is barely visible. Then, we can't choose yet, and the whole thing doesn't work on Wayland.

any feedback about the icons?

Where will battery status be shown? Right now we can't really show volume or other info in there but battery is a must imho.

https://dl.dropboxusercontent.com/u/1642456/VDG/Screenshot_20160823_012226.png

I would suggest to make two icons for each state. or if you have more than 2 monitors you can add for each monitor an icon.