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

List:       kde-panel-devel
Subject:    Re: [RFC] New (QML) Desktop Containment
From:       Sebastian =?ISO-8859-1?Q?K=FCgler?= <sebas () kde ! org>
Date:       2012-11-22 12:05:05
Message-ID: 1618812.rrcvKzPqnZ () marvin
[Download RAW message or body]

Hi,

On Thursday, November 22, 2012 12:45:38 Aaron J. Seigo wrote:
> On Wednesday, November 21, 2012 20:10:06 Sebastian K=FCgler wrote:
> > * less visual clutter (especially caused by applet handle when unlocked)
> =

> how is it less visual clutter when the unlocked state, which is the defau=
lt
> state and should be encouraged as such for fairly obvious reasons, has
> frames and buttons around every single widget?

What are those "fairly obvious reasons"? =


The applet handle is not great yet, and needs further work.

> it also means that non-rectangular widgets are always rectangular. for
> things like the analog clock this makes them far less visually appealing.

The idea is to make locked mode the default, and encourage that. I agree =

there's too much visual clutter as it stands in the locked mode, and will b=
e =

working on that issue. Marco for example suggested to only use the extra fr=
ame =

for applets the mouse is hovering, which woud work from an interaction poin=
t =

of view -- something to be tried.

> .. and we're also back to "we have windows on the desktop" which means
> mixing metaphores pretty deeply and in a very non-obvious (to the average
> person) way. "what is the difference between the windows on my desktop and
> the windows that are floating?" (which rapidly becomes: "Why can't I do X
> with the ones stuck to the desktop that I can with the ones that float
> around?", or vice versa). we don't get this problem in plasma active's
> contour because there are no floating windows.

I was thinking about this as well, and for this PoC, I went with a fairly =

"windowy" metaphore. The applet handle does need some further design, but I =

wanted to collect feedback first.

> it loses rotation of items. yes, this is not an amazingly *functional*
> thing, but not all things in life that have value are functional. the # of
> layouts i've seen where people have taken the time to personally arrange
> photos, for instance, with rotation speaks to the (known and measured)
> concept that people feel more at home in a space they can freely remake
> even if it the result is less efficient than in a space that they can't,
> even if it is more efficient.

That's just a missing feature, not a design decision. Simply didn't get aro=
und =

to doing rotation yet. Therefore I listed it in my known issues section. =

(There are a few other actions missing, in the end I want them all back.

> on the whole, this strikes me as very techy-oriented and extremely non-
> organic.
> =

> showing the grid while moving things is also pretty .. ugh. on touch it
> makes sense for 2 reasons:

I think it's rather useful, since it provides immediate feedback where the =

widget ends up after being dropped. I've tried it a few times without, and =

this way feel a lot more predictable. We can

> * granularity of and visibility duing dragging with a finger is pretty po=
or
> * given the small screen real-estate and the effort needed to move things
> around, moving things to the nearest open space is pretty common
> =

> on desktop, i'd suggest trying to always drop things where they are placed
> by the user and never move it elsewhere for them. that may mean resizing
> other widgets.

I find this a bit tricky, which widgets to resize, how does the user predic=
t =

the result? Maybe it could be done, but it's probably not easy, and I'm not =

sure if the result won't just be frustrating for the user, as he doesn't ge=
t =

the impression that he needs to play some balance game between 2 or more =

widgets, but can correct the position and size one for one.

> one thing the grid also does is prevent overlap of widgets. this is fine =
for
> final results, but makes moving things around with the free space on scre=
en
> is small a right bitch. basically, it turns into a game of "15 puzzle"
> where the pieces can be resized. again, on active we get around this by
> providing infinite vertical heigh, which works because touch makes the
> scrolling very simple and intuitive.

That's an issue, yes. but on the other hand, we also move widgets in the =

current containment, the moving just seems a bit more unpredictable (you pl=
ace =

something, and then it slides to a different place. You often end up grabbi=
ng =

the same widget again, and placing it again. Handling the "layout correct" =

while the widget is being placed makes this process more effortless and les=
s =

trial and error.

> so .. the good:
> =

> * alignment made easy
> * it's very fluid looking
> * QML ftw :)

Thanks for the feedback,
-- =

sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9
_______________________________________________
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]