On 01/28/2015 07:21 PM, Peter Hutterer wrote:
On Wed, Jan 28, 2015 at 01:09:09PM -0800, Bill Spitzak wrote:
I would greatly prefer to get an event when this happens. The user expects
something to happen when they push a button. You cannot just throw it away.
the alternative is leave button/key release behaviour up to the client,
resulting in duplicated code across the various clients/toolkits,
inconsistent behaviour across clients, increased chance of implementation
bugs, etc.
My main compliant is that I have to put this code in the client anyway,
therefore you have not saved me any effort, and you are throwing away
information that I *might* find useful.
It is very difficult to write a non-trivial client any other way. This
is because the client has it's own internal processing (such as
directing events to widgets) and it has to account for things like
widgets being destroyed while the mouse is down which may cause the
release event to go to a widget that did not get the press. For this
reason the widgets already deal with extra events. Trying to deal with
this at any higher level, such as event dispatch, introduces endless
complexity and bugs, as I think you are finding when you need to add
these patches.
a 11-line fix (times 2 for key events) doesn't strike me as "vastly
complicate the code".
Did you count how many patches are adding 11 lines? There have been
dozens posted on this list.
Anyway, you've made it clear multiple times in the past that you are a
proponent of laxer guarantees regarding paired events from the compositor
stack and leaving the messy details to the clients. It has been rejected
every single time so far, I think at this point you should either drop the
topic or spec out an implementation that explains why it is technically
superior and that actually convinces us.
If you send enter events for the next window before exit events for the
previous ones, a client can implement a non-flickering display without
having to peek ahead in the event queue. I think that is a pretty simple
example of a technical superiority.
_______________________________________________
wayland-devel mailing list
[email protected]
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
