Alternative desktop applet interaction

[Sebastian Kügler]

On Friday, February 13, 2015 23:55:24 Eike Hein wrote:
> > 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.

Whichever item gets the event doesn't really matter. The user wants only one 
of them to receive the event, for consistency, that's the "applet handle", but 
as soon as applets use pressAndHold themselves, it's either them not receiving 
this event (in this containment type!), or the applet handle not working.

I have experimented with the same in the (default) desktop containment, and I 
think it's quite easy to try with a small adjustment in the code (would need 
to look it up, I haven't touched that code in a while).

Cheers,
-- 
sebas

http://www.kde.org | http://vizZzion.org | GPG Key ID: 9119 0EF9