[Development] Input events handling ideas and feedback

[Filippo Cucchetto]

hi everyone,
this is going to be a lengthy email so i'd like to thank those
who will read it and maybe give me their opinions.
The topic here is throwing some ideas for improving QtQuick event
handling (both for mouse and keyboard).
First let's take a look at some simple/silly keyboard examples that will
make us introduce the main topic and some issue with the current way of
handling
events.
First example (here)[http://pastebin.com/jiGJimGS]. Here the user would
like to
count how many times the right key has been pressed. Try it and you will
see that
the Keys.onPressed handler will be called twice when the caret is at the end
of the TextField but it will work when the caret moves inside the text. I
know
that once the final user discover this, he can workaround it and fix the
counter but
this is not the point. The reason why the Keys.onPressed is called twice
is caused by the TextField implementation. In fact a TextField is a
composed Control
made of a TextInput plus a Text. At the same time, the end user doesn't
know this and
he can only interact with the whole TextField (in theory he doesn't have to
know that
the TextField contains a inner TextInput). For this reason the developer of
the TextField
control added a Keys.forward[root] inside the inner TextInput toward the
parent TextField.
This is correct in the current state of things because this allows the end
user to override
the key handling of the the TextField. But why we see two events? This
comes by the fact that:
1 The right pressed event is delivered to the inner TextInput (because it
has activeFocus)
2 The event is forward to the TextField before being processed by the
TextInput (because of Keys.forward[])
3 The TextField calls the Keys.onPressed handler of the user (that simply
ignores the event)
4 The event is processed by the TextInput that ignores it (because the
caret is at the end)
5 The event bubble up to the TextField again and the Keys.onPressed event
handler will be called for the second time.
This example shows us that the actual way of handling events doesn't play
well with item composition.
Furthermore the event forwarding is very error prone given that without
attention is very easy to create
loops or unexpected chain of calls (due to bubbling and forwarding).
Obviously there could be several ways to solve this, for example
1) Find some way of disabling the call to the event handler (during
bubbling) since it has been called once
2) Find some way for making a complex object (made of sub controls) to be
seen as a unique entity for the sake
of event handling
3) Let the user monitor the events before they reach a child.
4) <--- your ideas here
Let's take a look to another example (here)[http://pastebin.com/9s36E6bm].
Here the user would like to disable
the ComboBox event handling, for example because the ComboBox is inside a
ListView or TableView and he doesn't
want to break the View event handling (up ad down keys). If you try it you
will see that it doesn't work. Even if
the events are accepted they're still delivered to the ComboBox. This is
due (probably) by the fact the a Keys.forward[]
directive is missing inside the ComboBox implementation.
Another broader example is allowing a ListView to handle mouse clicks and
events even if the delegate has a MouseArea on top.
This letter case can be implemented by using the filterChildMouseEvents api.
I've taken a look at what other frameworks do, in particular WPF (this
doesn't mean the design of WPF is better or clever).
In WPF it seems there are three mechanism
1) Event tunneling. The events first make a down path from the UI root node
to the target node
2) Event bubbling. The events are bubbled from the target node up to the UI
root node
3) Event flagged as handled (accepted) still make their way up (bubbling)
because some nodes could be interested in a event
even if it has been flagged (rare ma usefull).
Point 1 it's basically a child monitor. Point 2 is what we already do.
Point 3 is usefull because at point 1 you know that
an event is being delivered to a child but you don't know if it'll be
accepted or not. Point 3 can be used for this purpose.
Just for fun i pushed two wip code reviews for event tunneling for keys
events: one in QtCore https://codereview.qt-project.org/#/c/163502/
and one in QtDeclarative https://codereview.qt-project.org/#/c/163502/
With this patch the example 1 and 2 can be written like this:
http://pastebin.com/t0ewNrxC and http://pastebin.com/LqvPZkZN
Further informations about tunneling and wpf event handling can be found
here
https://msdn.microsoft.com/it-it/library/ms742806(v=vs.110).aspx#how_event_processing_works
My patches are just wips and if there's interest i can work further on
them. For example i would like
to have some sort of Mouse attacched object, like Keys and implementing
bubbling even for handled events.
Finally maybe we need some sort of QEP for writing long term ideas and
discuss them in public.


Best regards,
F
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160625/05600947/attachment.html>