[Development] Bug#874054: Setting QT_LINUX_ACCESSIBILITY_ALWAYS_ON=1 has a huge negative performance impact, should not be always on

[Simon Hausmann]

On Mittwoch, 6. September 2017 19:24:53 CEST André Pönitz wrote:
> On Wed, Sep 06, 2017 at 07:17:02AM +0000, Simon Hausmann wrote:
> > Applications developed with Qt should be usable by users who do require
> > assistive technologies and users who don't, out of the box.
> 
> Is that meant as a general statement, along the lines of "Applications
> developed with Qt should be usable by users who do require X" or is that
> specific to X == "assistive technologies"?
> 
> I would disagree with both, but for different reasons.

I wrote "users who require assistive technologies" and that's how I meant it. 
No generalization is implied in the context of this thread/issue.
 
> > technologies and users who don't, out of the box.  That is not opt-in IMO.
> > 
> > It appears that this is feasible on Windows, macOS, iOS and hopefully
> > others, without compromising significantly on performance or memory
> > consumption.
> > 
> > If Qt applications on Linux cannot be made to work like that, then it is
> > our job to fix it on whichever level necessary (system, Qt, etc.) or pay
> > somebody to fix it.
> > 
> > If we choose not to fix this, then we are failing at our missing to make
> > life easier for application developers in this aspect, because at that
> > point it becomes the developer's job to achieve the same level of quality
> > as Qt offers on other operating systems, out of the box.
> 
> We are failing in this respect in a lot of other areas, too, so this
> hardly can be the only reason.

As a general statement I agree, but when taken into the context of 
accessibility I do think that it is a perfectly valid reason to address the 
issue.

Imagine Qt would suddenly stop accepting mouse input or render all text white 
on white background? It would make Qt applications unusable and require 
developers to write their own mouse input handling or change the text colors 
everywhere. It would not be acceptable and we would prioritize fixing this 
situation.

Similarly, the lack of support for screen reading out of the box makes the 
applications unusable for somebody who requires a screen reader in order to 
use the software. Given that it works out of the box on Windows, macOS and iOS 
(I haven't checked the others, hopefully there are more), I think it qualifies 
as a relevant reason for prioritizing it on our end to fix it.

I do think that this is an issue of different severity than say rendering the 
corners of buttons aliased when it should be anti-aliased. Or not supporting 
auto-repeat on the keyboard.



Simon