[RFC] New (QML) Desktop Containment

[Aaron J. Seigo]

On Thursday, November 22, 2012 14:28:24 Marco Martin wrote:
> On Thursday 22 November 2012, Marco Martin wrote:
> > forgetting for a while about the implementation, what would probably work
> > the best from an ui point of view is (not too unlike the current behavior,
> > but a bit fancier):
> > * plasmoids freely movable, if some conditions don't happen, they stay
> > exactly in the pixel they are dropped.
> > * the drop target doesn't show normally, it appears when an applet would
> > be
> > then moved or resized by the layout system (ie user is dragging one on top
> > of another)
> > * when put near another one, plasmoids snap at edges/corners to perfectly
> > align: the drop target appears also when a snap would occur
> 
> to go a bit more at impementation details vevel, to achieve something like
> that, it could be done:
> * maintain the same grid system 48x48 there is now

should this be based on screen resolution / dpi?

> * so when a plasmoid is dropped, those cells are marked as taken
> * but the plasmoid is not moved to be exactly in position and size grid
> aligned, the positioning is free
> * but the grid is still used to see if the dropped place is acceptable (or
> if it will cause a resize) when the final position will be in an area of
> the grid different to the one the plasmoid is being dragged right now, the
> drop target appears
> * snapping is a bit an unsolved problem. maybe enabling the full snap to
> grid behaviour when ctrl is pressed?

would prefer not. i think we need to make a decision one way or other -> snap 
or don't snap.

as an odd idea, it could be based on distance. things that are closer snap .. 
things that are further away don't. this would create areas of local order. a 
lot more complex to implement as it sounds though, as groups can grow towards 
each other and then what? :)

i'd like to see how a fine-grained grid works first (we may need to play with 
the size of the grid cells) and if it leaves something to be desired in 
practice, try more complex implementations such as what you suggest. (start 
simple work towads necessary complexity.)

let's also keep in mind that while we're focusing hard on this area of the UI, 
nobody using it should ;) we're not making a painting app, but a way to 
(experentially) loosely arrange items on screen. i'd give up some level of 
customiation here if it results in a large speed boost in usage.

-- 
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/e2dfab2b/attachment-0001.sig>