[krita] 3rdparty/ext_qt: Fix a "bended lines"+AMD+Qt5.6 bug

[Boudewijn Rempt]

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