[RFC] New (QML) Desktop Containment

[Aaron J. Seigo]

On Thursday, November 22, 2012 13:05:05 Sebastian Kügler wrote:
> > 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
> around to doing rotation yet.

ah, cool.
 
> > 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. 

one reason i probably feels more predictable is that the current algorithm is 
very *unpredictable*. the feedback at least lets the containment says "this is 
the odd thing i'm about to do to your widget". you can see this in your screen 
cast at one point where you are moving a widget and it keeps wanting to put it 
in an empty area to the left, even though the widget is definitely nearer other 
open spaces.

another potential improvement would to keep drop target feedback, but make it 
far less intrusive. since we don't have fingers and hands in front of the 
screen, a simple spotlight / spotshadow that moves around tracking the center 
of the drop zone could be enough.

the drop zone should also have less lag. i'm guessing on Active that was done 
due to the low graphics power of QGraphicsView on devices. we don't have that 
issue on desktop; with small spotlight / spotshadow it would be less 
repainting anyways; with QML2 and openGL this will probably become a 
completely non-issue.

> > * granularity of and visibility duing dragging with a finger is pretty
> > poor
> > * 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 predict
> the result?

perhaps by live resizing of the stationary widgets as the target widget is 
moved around? this would give direct feedback as to the results.

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

yes, the current desktop containment also sucks. better yet it accomplishes 
this with overly complex code. :P

-- 
Aaron J. Seigo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20121122/714f6231/attachment.sig>