Hi all, i want to talk about the mouse event handling in QtQuick. From my experience mouse event handling is rather unflexible. The current implementation is straightforward: the events are propagated from the top mousearea until accepted. This is fine however consider the common scenario of an item delegate for a row in a view (be it a TableView or TreeView) that needs to listen for mouse events: 1) The user put a MouseArea inside the item delegate 1.a) if the user is only interested in the press event the solution is simple: handle the onPress event in the MouseArea and simply propagate the event by setting "mouse.accepted = false" 1.b) if the user need to listen for the click event he can't reject the press event. This in turn break the view selection handling and maybe more. AFAIK there's no way to temporary store the mouse events and later propagate them beneath. The user has to reimplement most of the event handling in the item delegate (like handling selection/multi selection). 2) Rely on the view signals. Some view exposes some mouse signals like clicked and doubleClicked etc. Most of the implementations in QtQuickControls are not sufficient. For example they lack of the button pressed or mouse positions. Furthermore most of the view signals are for composed events (clicked) and so there're no press and release events. One could argue that most of the implementations expose the view mouseArea (__mouseArea) so a user can connect to it through a Connection object. This is a partial solution because the press[release] event is sent after the view handled it and again the user act after the view already handled it (so there's no way to swallow it). Another downside of option (2) is that most of the times the user need to do some actions on the item delegate. So from the view onClicked we must obtain the itemDelegate. This imply one these solutions: 1) the existance of a itemAt(index) or itemAt(row) function (AFAIK there isn't right now) 2) Each item delegate connect to the clicked signal of the view To me both solutions are ugly. First they have an overhead: connections costs in the delegate item construction and also finding an item could be expensive. Keep in mind that solution (1.b) is simpler since we handle the event directly in the delegate.
What do you think about it? Do you have a solution for this kind of problems? 1) One possible solution could be exposing the views event handlers like callable functions ( onPressed, onRelease etc.) In this way with solution (1.b) we can both accept the mouse event and also propagate it to the view. i.e. MouseArea { onPressed: { mouse.accepted; view.onPressed(...) } } 2) Other frameworks like WPF has the notion of "handledEventsToo" where basically you let propagate an event even if it has been handled 3) Another solution could to remove the need of accepting the press event for having the notification for the click event. Most of the times the user just need to know that an item delegate has been clicked without swallowing it. But for receiving the click event he must swallow (accept) the press event. -- Filippo Cucchetto
_______________________________________________ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development