Alternative desktop applet interaction

[Eike Hein]

On 02/13/2015 04:27 PM, Marco Martin wrote:
> I don't think so, locked means locked.. especially for kiosk setups where it
> would be systemimmutable the expected behavior is that there should just not
> be any ways to move anything in any way

Yes, the concept of 'locked' needs to remain in the code
e.g. for the Kiosk use case. I'm just talking about the
UX here, and consider this implementation more of a thought
exercise. It's ignoring lock to allow you to get a feel for
how it is not to have to unlock first to move anything.

Another thing I like: You get to move applets immediately
relative to the position where you press down, no hovering
to reveal handle + moving to handle. It's kind of con-
venient to not have to aim.



> one thing is that it would break if any applet decides to manage press nad
> hold i guess (not any current applet i know, but since is a standard signal in
> MouseArea, hmm)

It don't think it would though: The MEL underneath the applet
gets the press and hold first (it's filtering child events)
and cancels the press, thus the child can't reach press-and-
hold. Even so, the MouseArea will run onCanceled so the code
gets a chance to do any cleanup it wants.



Cheers,
Eike