Details
-
Sub-task
-
Resolution: Invalid
-
Not Evaluated
-
None
-
None
-
In my opinion, this Sub-task constitutes the highest-risk portion of the parent project. I believe that all current Qt-X11 platforms provide 32-bit registers and address space (or larger). But that says nothing about whether Qt compilers may be compressing multiple objects into smaller address spaces, and then separating them via "Load Under Mask", or "Load then Shift", or similar instruction sequences when reading them into a 32-bit register. This issue also has risks for big-endian versus little-endian platform differences.
Thus, I feel that it's best to try the "widened" definition all by itself, before writing ANY code which attempts to use the new values. If the larger enum and Flag definition causes breakage all by itself, then I'll have to either give up, or design workaround code immediately.
I have no access to these other possible compilers and platforms. All I have is GCC on Linux (compiling for x86 or x86-64). If such testing from me is required before review and possible commit, then please advise how I may perform such testing.
In my opinion, this Sub-task constitutes the highest-risk portion of the parent project. I believe that all current Qt-X11 platforms provide 32-bit registers and address space (or larger). But that says nothing about whether Qt compilers may be compressing multiple objects into smaller address spaces, and then separating them via "Load Under Mask", or "Load then Shift", or similar instruction sequences when reading them into a 32-bit register. This issue also has risks for big-endian versus little-endian platform differences. Thus, I feel that it's best to try the "widened" definition all by itself, before writing ANY code which attempts to use the new values. If the larger enum and Flag definition causes breakage all by itself, then I'll have to either give up, or design workaround code immediately. I have no access to these other possible compilers and platforms. All I have is GCC on Linux (compiling for x86 or x86-64). If such testing from me is required before review and possible commit, then please advise how I may perform such testing.
Description
As of today, the current definition occurs within src/corelib/qnamespace.h starting at line 149:
enum MouseButton
{ NoButton = 0x00000000, LeftButton = 0x00000001, RightButton = 0x00000002, MidButton = 0x00000004, // ### Qt 5: remove me MiddleButton = MidButton, XButton1 = 0x00000008, XButton2 = 0x00000010, MouseButtonMask = 0x000000ff };
I propose the following replacement:
enum MouseButton
{ NoButton = 0x00000000, LeftButton = 0x00000001, RightButton = 0x00000002, MidButton = 0x00000004, // ### Qt 5: remove me MiddleButton = MidButton, XButton1 = 0x00000008, RawButton8 = XButton1, XButton2 = 0x00000010, RawButton9 = XButton2, RawButton10 = 0x00000020, RawButton11 = 0x00000040, RawButton12 = 0x00000080, RawButton13 = 0x00000100, RawButton14 = 0x00000200, RawButton15 = 0x00000400, RawButton16 = 0x00000800, RawButton17 = 0x00001000, RawButton17 = 0x00002000, RawButton17 = 0x00004000, RawButton17 = 0x00008000, MouseButtonMask = 0x0000ffff };
I understand why the names "XButton1" and "XButton2" were used (instead of "Back and Forward"). But over and over, at KDE, people show confusion about the equivalency between "XButton1", "XButton2", the left and right wheels, and how they all correspond to xev output. My "RawButtonxx" proposed naming convention is more clear, and easier to remember. (We keep the old names for BC, of course.)