[Development] [QtQuick] Mouse/Touch handling from Qt CS

[Shawn Rutledge]

On 25 July 2013 18:06, Alan Alpert <416365416c at gmail.com> wrote:
> On Thu, Jul 25, 2013 at 1:14 AM, Rutledge Shawn
> <Shawn.Rutledge at digia.com> wrote:
>>
>> On 24 Jul 2013, at 5:45 PM, Alan Alpert wrote:
>>
>>> Qt CS had a discussion on how to handle mouse and touch event
>>> conflicts in QtQuick going forwards.
>>>
>>> An interesting idea came up that the existing model might be
>>> salvageable if we fix multi-cursor support.
>>
>> I suggested that idea 2 years ago, but I was told authoritatively at that time that realistically, Qt will never support multiple cursors, because the idea of a single cursor, single grab, single focus, etc. is so pervasive in Qt.
>
> Two years ago, was capacitive multi-touch an essential feature for
> UIs?

Yes, it became an essential feature for mobile device UIs suddenly in
2007.  But the point is not whether or not to have multi-touch, but
whether we can pretend that multi-touch and multi-mouse are the same
thing.  I don't think we can because
1) it's the hard way to get there, due to Qt legacy
2) the use cases aren't really the same
3) multiple mice implies multiple users, multiple active windows,
multiple focus, etc.

> It will be easier to fix in QtQuick than in Widgets. Hopefully.
> Realistically, we probably don't have the capacity to fix it in
> widgets anyways. If it is indeed too hard to fix, then we'll just
> implement mouse and touch handling for now and we'll continue
> researching the ultimate solution for Qt 6 ( or QtQuick 3 ).

I expect that's how it will turn out.

>> If not, it would still be nice if QtQuick could short-circuit some of the event delivery path.  I've been wondering if it could interface directly to QPA.  Probably it would have profound effects on our chances of properly nesting QtQuick and widgets in the same application.  (Which is problematic anyhow, due to the fact that OpenGL rendering always requires its own window.)  But it would also provide a chance to handle multiple cursors in QtQuick only, without making incompatible changes in all the other layers.
>
> I'd have to see a prototype to understand how that would help...

Me too.  ;-)  If everyone thinks it's a hopeless idea, then I suppose
it's not worth trying.  But I think it would be a nice optimization to
cut down on the number of layers, event type conversions and queueing
involved.

> Most people seem to have discarded the idea as impractical approx. 45
> years ago. Without a screen the size of a house

The size of a table or some part of a wall is big enough to start.
It's been possible to buy such a thing for a long time already.

Game consoles have always been multi-user, they just don't usually use
conventional pointing devices.

> (which we only just now have with 4K Projectors), you get in each others way and there
> isn't even the physical volume of fingers to help stop that.

Hardware limitations tend to get solved eventually.  I think bigger
screens are inevitable; next, multi-user applications might start to
become more common.  So we would do well to preemptively start
removing obstacles ahead of time, even if it doesn't seem urgent.