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 _______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
