[Development] 31 mouse buttons in Qt 5.0

[Thiago Macieira]

On Monday, 24 de October de 2011 15.14.23, Rick Stockton wrote:
>         (A) obtain the full mask automatically, and setting
> Qt::MouseButtons accordingly; or
>         (B)  leave high-order bits unset in events, returning the full
> mask as the value of a SEPARATE function call.
> 
> I feel that alternative (A) is far less confusing, and have been advised
> by some X11 experts (Peter H., Daniel S.,) that the overhead and
> reliability of mixing a query-state function call (i.e., to get the
> mask) into the code path of this Event processing is a non-issue -- as
> long as we avoid doing it with every single XCB event which occurs on on
> Wheel "Buttons". (Wait until we're done compressing these lower-level
> events, and acquire the current mask field when we're preparing to
> create the QWheelEvent.)

Are you proposing opening and checking /dev/input/mice for each mouse / wheel 
event that is about to be delivered? That's a definite NO-GO.

Get the information from XCB or Wayland. If they don't give that information, 
fix them and then update the Lighthouse plugin.

> The need for this 'enhancement' seems to be even more severe than it
> appeared to be a year ago -- our current 5.0 Wayland/evdev plugin code
> actually REDUCES the number of Qt-supported buttons, from 5 to 3. We're
> losing the "Back" and "Forward" buttons, AKA "XButton1" and "XButton2".
> (IMO, That's not a healthy direction; Qt becomes less attractive for
> writing web Browsers, FIle Managers, and etc.)
> 
> This would be my first submission of code into Qt. If it's no-go, please
> advise: What are the problems with this approach, and are there ways to
> avoid the problems which I don't yet see?

Modify the Lighthouse plugin to get the information from the correct source: 
the windowing/compositing server. Reading from /dev/input is *wrong*.

This information should be included in the native event handle obtained from 
the server. If it's not included, then you should query the server *using* the 
same event pointer, as we need to obtain the state at the time the event was 
generated, not at the time it was processed.

If those systems do not include said information in any form, then you should 
consider that this information does not *exist*. If you feel strongly about 
the case, prepare patches for those systems and update their API to include 
the extra information. Only then can you update the Lighthouse driver to 
deliver more information.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel Open Source Technology Center
      PGP/GPG: 0x6EF45358; fingerprint:
      E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 190 bytes
Desc: This is a digitally signed message part.
URL: <http://lists.qt-project.org/pipermail/development/attachments/20111025/7829bbbc/attachment.sig>