[Development] QtQuick mouse event handling

[Filippo Cucchetto]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20160223/a34f9f4f/attachment.html>