Display Management Design

todd rme toddrme2178 at gmail.com
Mon Jul 25 07:55:23 UTC 2011


On Sat, Jul 23, 2011 at 5:47 PM, Alex Fiestas <afiestaso at gmail.com> wrote:
> Hi there fellows: metalworkers/plasmafiers?/usabilitiers? xD
>
> Today we've started to draft what is going to be another Solid project,
> this time to improve the Display Management.
>
> As you may know, I have been working to fix the current code but as
> happened to me before (KBluetooth) I can't improve the existing codebase
> any further, so it is time to rewrite it.
>
> Also, as occurred in the KBluetooth times, after fixing it now I have a
> clearer idea of what we want and how we want it, and of course being a
> hard user of "Multi Display's" helped.
>
> So, this is the design so far:
> http://community.kde.org/Solid/Projects/DisplayManagement/Design
>
> Everything is open to changes, just say it and if everybody more or less
> agree it will be changed.
>
> Also, I like to consider this the first step towards KDE5 workspace, uh
> oh what, I'm crazy? yes I'm :D
> We've to update our guidelines about KCM's and unify them, right now all
> we have is a mess :D
>
> We have time to discuss the design I have a lot of work to do until I
> start to do the GUI bits.
>
> Cheers!

A few suggestions:

For the popup:

In the probably most common case, projectors, users probably don't
even care which side it is on.  Would it be possible to have a
"side-by-side" option, along with an arrow that pulls up a list of
orientations?  The primary display would also need to be set in this
mode.

Similarly, there could probably be a dropdown for the clone option to
decide whether you want to stretch the screen to match or trim one of
the screens (assuming your driver supports this).

I might change the "External only" to "Switch Screen". The reason for
this is because this dialog would probably not only be pulled up
automatically upon pluggin in a screen, but also when a user hits the
keyboard shortcut to switch display layouts (which pretty much every
laptop has).  This would make the two dialogs consistent (or better
yet just use the same dialog).  Users should be able to scroll through
the basic options by repeatedly hitting this button.

I might add an "advanced" button on the popup as well, which pulls up the KCM.

For the KCM:

Perhaps sliders should be used instead of dropdowns for the resolution
and refresh rate?  These are values with clear numerical precedence,
so I think that might be more intuitive for users.

I think the "rotation" interface needs to be fleshed out more.  Will
this be (0-365 degres) or just 4 values (0, 90, 180, and 270 degrees)?
 Would it be a dropdown or a slider?

I definitely think there should be a "DPI" interface as well, perhaps
also a slider.

Might we think about having a draggable interface in the window
instead of or in addition to textual interfaces?  Users could drag an
edge or corner to resize the screen, and there could be rotation
handles for angle (or some other draggable interface).  Enabled and
"set as primary" checkboxes could be embedded in the interface.  This
rewrite might provide an opportunity for a more substantial rethinking
of how such interfaces are done.  I am not sure the fairly classis
interface here is necessarily the most intuitive.

There are additional issues with the "clone" interface, as I mentioned
before, such as whether a screen is cropped or stretched.  These
options, at least, are often present on Windows, I don't know about
Linux.

I definitely do NOT think that things are stable enough to not have a
"click okay to keep this", I still have problems with that.  Perhaps
your hardware can handle it intelligently, but mine can't.  You could
have a "don't show this again" checkbox, though.

What is the story with backends?  Will this support different
multi-screen configuration backends?  This is probably a good idea,
just to be ready for Wayland.  And of course NVidia does not support
randr, although they claim they will (of course they have been saying
that for years).

-Todd


More information about the Plasma-devel mailing list