[Qt5-feedback] Thanks for your (FIRST round of... ) Mouse Button comments!

[Samuel Rødal]

On 07/29/2011 05:36 AM, ext Rick Stockton wrote:
> --- 1. The maximum number of buttons *WILL NEVER* exceed 32. ---
>
> --- 2. The Highest number of Buttons ever implemented under x11, so far,
> is 27. ---

Good to hear. So limiting the QMouseEvent API to 32 buttons doesn't 
sound too unreasonable.

> --- 4. IMO, we can and MUST keep BC while doing this. ---
> The 'broken compatibility' elements in qt5 should be minimized (each
> becomes a quagmire of creating, and then supporting, the "qt4
> compatability" library API as separate code.) We CAN do this without
> breaking BC, and my strategy provides for that goal. Most important of
> all: if we avoid BC breakage, we can implement it in qt4.... which, for
> many reasons, could be around for quite a while.
>
> Here are the key issues surrounding the BC requirement:
> *A* We cannot "stretch" the enumerated names past the one-byte boundary.
> (That would break on big-endian versus little-endian machines, because
> the 2nd byte "stretches" the enum byte field in opposite directions.)

I don't think that's an issue actually, since Qt (or the QPA plugin) is 
the one that translates from raw evdev / wayland or whatever events to 
the Qt enum values. That code is endian aware, so I don't see a problem 
with extending the MouseButton enum. Although, it might be a bit awkward 
to have to name them Button6 through Button32 or similar. (Shouldn't 
Button10 be Button6, since it's the sixth enum value and has the sixth 
bit set in the button mask?)

> *B* We cannot add the button number as an integer in the Event API (The
> change in Event signature would break BC, right? The event comes from
> below, so we can't use a caller's parameter Types to select an
> appropriate set of Event return values.)

Adding non-virtual functions doesn't break BC. Though I fear API changes 
to Qt 4.8 at this point would be met with resistance, as feature freeze 
has already passed.

> *C* We cannot increase the size of the mask byte within the event API
> (also breaks BC of the signature).
> With this design, we stay within one byte-- and the last bit value tells
> the programmer that he needs to call a function to obtain his button
> number. (That's a Task-State call into X11/Wayland/Whatever, but
> non-wheel button events are very stable in terms of Task versus Event
> State code priority. They don't happen "too quickly".)

How about QMouseEvent also reporting combinations of mouse buttons, 
should that only work up until the seventh button? If we limit the 
design to 32 buttons, one bit representing each, we can have both 
QMouseEvent::button() and QMouseEvent::buttons() return the correct 
values without having to add new API (apart from extending the enum).

> This design is extremely low risk, IMO. I feel it to be comparable to
> the adding of "BUTTON_BACK" and "BUTTON_FORWARD" in qt 4.7.  (We called
> them "XButton1" and "XButton2"; but, if we making the actual integer
> numbers available, badly-chosen names will not matter so much. And we
> can add extra names for the same enum bit field, as currently exists for
> "MiddleButton" and "MidButton". (I've already done that in my draft,
> adding names "BackButton" and "ForwardButton" as synonyms for these two
> "XButtons").

Having aliases sounds reasonable, but we shouldn't go too far there I guess.

--
Samuel