[krita] 3rdparty/ext_qt: Fix a "bended lines"+AMD+Qt5.6 bug
boud at valdyas.org
Thu Apr 21 09:07:16 UTC 2016
On Thu, 21 Apr 2016, Dmitry Kazakov wrote:
> I assume this is about the mouse positions on the window.
> Yes, exactly.
> Isn't there a way to read the X events directly? Not checked but perhaps you are doing something similar with
> wintab already?
> The funny thing we do read the X events almost directly. We read XCB packets, decrypt them and emit our own events. But
> we cannot read the XCB events queue directly (it is owned by Qt), therefore we use a special hook provided by Qt that
> allows us to process/filter the events coming through the queue.
> The problem is that inside Qt the filtering hook is set up *after* the compression code. It means that these "compressed"
> events will never reach our filters.
> Just another thing, this annoys me in many (if not all) programs. If you are using a tablet's stylus, it
> disables the mouse completely. This is not a good thing. Sometimes the tip of the stylus is not accurate
> enough, so better to use the stylus in proximity and press the buttons on the mouse. I'm left handed, so I'm
> holding the stylus in my left hand and the mouse in my right hand. It's very effective. I can use the wheel
> on the mouse the same way. This is not a technical limitation, I already made programs with this feature (but
> not with Qt...).
> I'm afraid this limitation is somewhat technical. The problem is that tablet generates Mouse(!) events too. And in most
> of the cases these mouse events do not correlate with what we get via native tablet events. It means that if we will
> start processing mouse events while tablet is in proximity, the lines will become dizzy, because of out-of-order events.
> What is more, in most of the cases we cannot distinguish real mouse events and the synthesized mouse events generated by
> the tablet. Right now people in Qt are working on distinguishing them but I'm not sure when and if it is going to work.
> There are too many variations where and how these synthesized events are generated.
Is that even true if we use a QAbstractNativeEventFilter?
> What I want to say is, maybe Krita's needs are too special about the mouse and the tablet events, so it's not
> a good idea to use Qt's solutions.
> Well, we cannot drop Qt entirely. And we already use our own forked tablet support. Just this time event processing got
> broken too deep in Qt.
> Dmitry Kazakov
Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
More information about the kimageshop