widget snap

[Roman Shtylman]

Aaron:

I will make those style changes (was not aware of the coding style
page and tried to make it match as much as possible to what I saw).

The reason for the x1...y4 is to avoid doing the calculation twice (in
your example to fix it you still had the x1 there and that calculation
would have to be done twice). I make it const so that if anything the
compiler sees it won't change and might optimize something away. I
will change the usage of QPointF to just two qreal as that seems
perfectly reasonable considering how the QGraphicsItem api is.

The use of the 'mask' was the way I was able to get the plasmoids to
snap to the visible border. Just using the bounding rectangles
includes the frame which includes the frame shadow. I might have
missed it but there was no method to get the side for the part of the
frame without the shadow. I did look at the svg image and saw an item
called "hint-stretch-borders" that looked to be around the right size,
but was unsure. I could add that to the FrameSvg api to provide that
metric and then just use that. I am aware of the performance
implications of making those cached masks but without knowing more
about the "hint-stretch-border" item was hesitant to use it for sizing
and thus had to rely on the mask for the true visual coordinates to
snap to.

I would be happy to look at the handles further and see how they can
be improved/changed in their behavior and existence in the codebase.

I can't commit cause I don't have an svn account (thus I send the patches :)

In general I like the handles and I think that they could be used to
make the plasmoids more interactive for those that want it.

~Roman

On Sat, Jan 2, 2010 at 4:08 PM, Marco Martin <notmart at gmail.com> wrote:
> On Saturday 02 January 2010, Aaron J. Seigo wrote:
>> On January 1, 2010, Roman Shtylman wrote:
>> > I was sitting around trying to organize some of my plasmoids... and
>> > realized that you can't easily make a stack of plasmoids all exactly
>> > aligned ... at least not that I could figure out. I thought it would
>>
>> snapping is a nice idea. putting it in the handle is pretty much the "only"
>> way to do it right now, but it's not a great solution: it means that click-
>> dragging on applets that support that, which is many/most of them, will
>>  work differently than when dragging on the handle. i have already observed
>>  people not figuring out how to drag widgets from the desktop to the panel
>>  because of this "handles are magical" behaviour.
>>
>> it's also going to break / do unhappy things for any containment that
>>  doesn't (for whatever reason) want such behavior.
>>
>> this really does belong to the Containment, but it needs support in the
>> handle. adding to this mess is that the handle is in libplasma at all: it
>> isn't used by all Containments (think of panels, for instance, or amarok).
>>
>> so, what are the handles for then? well, they do two things:
>>
>> * provide quick and discoverable access to features like resize, remove and
>> configuration
>>
>> * guarantee that we have a click-and-drag surface for applets that may not
>> provide one
>>
>> the handle can't simply be moved into, e.g., DesktopContainment as really
>>  all plasma-desktop "desktop" containments should have them. to me, it
>>  sounds like we need to think about how handles are done and do them
>>  better. they need to be:
>>
>> * sharable between Containments (for consistency and code sharing)
>>
>> * allowed to be specific to the application or the Containment
>
> sick idea: how about making handles plugins? the base is really minimal, so
> most of the implementation could be shipped alongside the workspace..
>
>> * be able to coordinate with the Containment on layout issues
>
> i don't know if something could be shared in really different situations (free
> layout vs panel, could it be any code sharing at all?)
>
>> * have logic for things like "moving to another Containment" moved outside
>>  the handle to API that is available to the handle but which is actually
>>  "native" to the Applet class so that we get rid of the "when you use the
>>  handle, it behaves this way; when you click on the applet it behaves that
>>  way" behaviour
>>
> that also reminds me how bad at the moment Applet::registerAsDragHandle()
> works..
> now if there is for instance the analog clock in the newspaper is possible to
> drag the whole page around out of the supposed boudaries by dragging the clock
> around, ir really ugly but didn't find a way at all to prevent it
>
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel
>