© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
513534c
demo site
(Get the code!)
>> My concern with adding cancellation behaviour is that there'll be no existing client or toolkit that expects it, and we can't make it opt-in (like the opt-in touch cancellation support).
>That's a good point but extra events are kind of opt-in already with zero code change for most clients. If clients see an event they don't understand they should ignore it and not treat it as an error.
Yeah, they (probably) won't crash; they'll just have broken behaviour. Failure to act on a BUTTON_CANCEL means that the client is erroneously treating that button as pressed, with whatever behaviour that entails. Which is exactly this bug; adding BUTTON_CANCELLED support won't actually fix this bug without also fixing clients :)
As you note in your subsequent responses, the click-move-release case is handled explicitly, either in the application or sometimes in the toolkit (for the “clicked” event). If we add a KEY_CANCELLED state to the existing KEY_DOWN/KEY_UP states, we'll likewise need to fix the rest of the universe, starting with the toolkits and moving up :)