Extending QMouseEvent a SECOND time? (within Qt itself)

I'll ask here in the forum, because I keep "crazy" hours in comparison to EU. Thanks in advance for any-all comments and suggestions. This is in preparation for attempting a change in Qt itself, not in "user code".

When I'm done providing background information, the questions are very simple- but I just don't know the answers.

Within /src/kernel/gui/kernel/qevent, QMouseEvent is given multiple declarations, and it's re-cast dynamically. Here's the relevant snippet of the current (4.7.1) declarations in qevent.h, lines 82-105:

Code:

---

public:
    QMouseEvent(Type type, const QPoint &pos, Qt::MouseButton button,
                Qt::MouseButtons buttons, Qt::KeyboardModifiers modifiers);
    QMouseEvent(Type type, const QPoint &pos, const QPoint &globalPos,
                Qt::MouseButton button, Qt::MouseButtons buttons,
                Qt::KeyboardModifiers modifiers);
    ~QMouseEvent();
 
    inline const QPoint &pos() const { return p; }
    inline const QPoint &globalPos() const { return g; }
    inline int x() const { return p.x(); }
    inline int y() const { return p.y(); }
    inline int globalX() const { return g.x(); }
    inline int globalY() const { return g.y(); }
    inline Qt::MouseButton button() const { return b; }
    inline Qt::MouseButtons buttons() const { return mouseState; }
 
    static QMouseEvent *createExtendedMouseEvent(Type type, const QPointF &pos,
                                                 const QPoint &globalPos, Qt::MouseButton button,
                                                 Qt::MouseButtons buttons, Qt::KeyboardModifiers modifiers);
    inline bool hasExtendedInfo() const { return reinterpret_cast<const QMouseEvent *>(d) == this; }
    QPointF posF() const;
 
#ifdef QT3_SUPPORT
// followed by irrelevant QT3 constructors, etc.

---

The "Extended Info" was introduced with 4.4 (a "minor" Release), and it attempts to provide the new "Global Positioning" as a set of automatically-paired floating point values (rather than the int values in the previous constructor.) This is done dynamically via the "reinterpret_cast" test, SOMEHOW. The same thing is done with QKeyEvent at line 235 of the header file, adding declaration of three quint32 "native" data fields.
- - - -
Ultimately, my objective is the partial support of "gaming mice" buttons in the X11 platform. I can't do this, WITH backward compatibility, by simply using the current "button-causing-the-event" field as the unsigned integer which X11 actually provides to us. (Binary Qt programs created within a "Qt 4.8" environment would have different button numbers for the same bits in "Qt.MouseButton" enum provided by library code in boxes running 4.0 thru 4.7). Maybe I need to create and manipulate an "extended info" data field, of type quint32, to hold a compatible bit-mask enum wide enough to add buttons 10-32.

And if so: Can I add a SECOND *createExtendedMouseEventVersion2 signature, adding this field? And maybe also another boolean test function result, "hasExtendedInfoV2() ? If so, what kind of test can I do for a dynamic test to declare and utilize the field?

Please advise me of your ideas on "smart" ways to create this enhancement, while preserving BC with all previous QT4 Releases. And again, my thanks for your patience and expertise in giving me "a clue". :)

Actually I'd do it differently without any need to modify Qt's code. Let's see the current pattern in Qt - we QMouseEvent events that are related to mice and touch screens, we also have gesture events with QGestureEvent and QTouchEvent, tablet events with QTabletEvent and QWheelEvent for the mouse wheel. And of course there are QKeyEvent events for handling the keyboard. You may notice these are all subclasses of QInputEvent. So why not provide another type of event for your input device, implement event translation in the application object (you can subclass QApplication and handle native events as they come) and handle the events either in customEvent() or in event() reimplementations. No need to touch Qt and even if you really want to do that, there is a clean way to do this, simply add another event handler to QWidget API.

Great reply. But I failed to clarify - I did this for KDE frameworks and desktop, other KDE programmers, and other users of Qt (Not just for an Application of my own.)

It's done, and coming in Qt 5.0. :D