[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-panel-devel
Subject:    Re: Display Configuration KCM design review
From:       Dan =?ISO-8859-1?Q?Vr=E1til?= <dvratil () redhat ! com>
Date:       2012-10-04 8:49:21
Message-ID: 1381141.cBbWH34Fxd () odin
[Download RAW message or body]

On Tuesday 02 of October 2012 16:23:02 Aaron J. Seigo wrote:
> On Tuesday, October 2, 2012 14:29:24 Dan Vr=E1til wrote:
> > I'm now working on new KCM.
> =

> code
> ------
> where is the code currently? i find it is often a lot easier to comment =

(and
> help out) when i can build and try the code directly

Hi,

the code is on git.kde.org/scratch/dvratil/displayconfiguration.git, you al=
so =

need git.kde.org/scratch/dvratil/libkscreen-clone.git, it was linked in the =

original email  ;-)

> =

> =

> duality in interaction
> --------------------------
> my first thought is: why are there two areas for interaction?
> =

> all the informaton is currently shown on the screens in the preview area,
> and i have to interact with the preview area to move or rotate a screen .=
..
> =

> ... but if i want to change other information i see there, then i have to =

go
> to the bottom area (after noticing that they are connected :), find the
> matching information and then change it there.
> =

> why can't i just change which is the primary monitor by pressing on the =

star
> (or whatever it eneds up being) in the preview area?
> =

> why not be able to change the resolution and refresh by pressing on the
> information in the monitor itself?
> =

> having some interaction in one area and some in another feels scattered. i
> find my eyes (and mouse) going back and forth a lot. that some things are
> able to be configured in both the preview and the details below
> demonstrates some additional inconsistencies.
> =

> perhaps the nicest thing about having the previews where configuration
> happens is that one does not need to "translate" between the representati=
on
> (the preview on screen) of the real thing (the actual screen) and a furth=
er
> abstraction (the collection of widgets at the bottom). it's one layer of
> mental re-direction less.

I originally written the KCM without the bottom panel, but then I had to ad=
d =

it because all the controls won't just fit into the monitor rectangle when =

it's too small (1024x768 is already problematic), so right when the rectang=
le =

becomes too small, I just hide or scale some of the controls there and rely =

on those in the pane below.

> =

> layout finesse
> ------------------
> =

> i'll echo the suggestion to put a little bit of space between the monitor=
s.
> yes, the screens are "connected" in the "real" world in that the graphics
> they show are connected (though in the "real" "real" world, there is alwa=
ys
> some separation, if only by the bezel). however, visually in the settings
> it doesn't look ellegant but like someone forgot a margin somewhere :)
> nobody will end up confused or balk a the lack of literal pixel truth if
> there is a nice little margin between the screens. if anything, it is
> likely to help people see that they are separate things more easily, usef=
ul
> when the screens are otherwise identical.

Ok :)

> =

> i do prefer the two rotation arrows over the one rotation icon as seen in
> http://i.minus.com/j0jCsZ3DaQQPO.jpg .. it's fewer clicks to get what i =

want
> and very clear what will happen.
> =

> it would be nice to find a prettier way to show the bottom of the monitor
> than dark line (which isn't obvious at all at first to me?) ... probably
> will require an artist's intervention ;)

As some suggested, the arrows for rotation could be always attached to the =

bottom side of the monitor, so that when you rotate the monitor by 90 =

degrees, the arrows would be on the left side. I think that could be obviou=
s =

enough?

> =

> the on/off checkbox is perhaps one of the few perfect times to use the
> toggle switch QML Component on the desktop as it is rather literall "on" =
or
> "off" :)

\o/ I like the switch!


Cheers,
Dan


> =

> =

> thanks for working on this :)
> =

> --
> Aaron J. Seigo
-- =

--
dvratil@redhat.com | Associate Software Engineer / BaseOS / KDE, Qt
GPG Key: 0xC59D614F6F4AE348
Fingerprint: 4EC1 86E3 C54E 0B39 5FDD B5FB C59D 614F 6F4A E348
_______________________________________________
Plasma-devel mailing list
Plasma-devel@kde.org
https://mail.kde.org/mailman/listinfo/plasma-devel
[prev in list] [next in list] [prev in thread] [next in thread]