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
_______________________________________________ Development mailing list [email protected] http://lists.qt-project.org/mailman/listinfo/development
