I think a more generous reading (and seems to be verified later in thread) is “I won’t be building … contributors wanted” instead of “No support planned”
There is still original Qt. I’m using Qt since more than twenty years and used the accessibility feature exactly one time (for a commercial application). If you think LeanQt cannot be without it, you are kindly invited to contribute it to the project; after all, that’s what open source is about.
There is still original Qt. I’m using Qt since more than twenty years
and used the accessibility feature exactly one time (for a commercial
application).
If anyone placed a default widget, they have used an accessibility feature.
Standard qt widgets can be operated through at-spi and are partially
self-describing.
That’s all somewhat recent development (maybe the last 10 years, even
5)? I remember that as late as the early 2010s the QT accessibility
story on Linux wasn’t great. It is much improved today, and I’ve had
good experiences using QT applications that use standard widgets with my
screenreader.
If so I recommend you stay with original Qt, or you can contribute the accessibility feature to LeanQt if you want.
I think people might be reading “No support planned” and reading that as “No support wanted”. Based on this feedback, it seems you are open to contributions just won’t be doing it yourself. Maybe rather than “No support planned” the same section could be “Looking for contributors to implement”. Suddenly instead of being the bad guy shutting out accessibility, you are just another incredibly overworked and underresourced open source developer who has to focus their time.
I would rather say that it is more indicative of a pretty patological zeitgeist that when you announce big volunteer efforts in this community, you don’t get a single positive feedback.
Disclaimer: I don’t intend to write any “native” GUI code in the future. I’ve used QT professionally.
But I hope to give this a little perspective:
you don’t get a single positive feedback
It’s sad to see this misunderstanding. To me your previous statements regarding a11y reads like you do not intend to have this in your project (maybe for staying lean), and you don’t view it as any kind of relevant feature.
If there is one thing I actually criticize personally on all rust UI frameworks, it’s the lack of a11y (and i18n).
I do totally get why they don’t include it (it’s a lot of work which you can’t see, literally), but this is what makes UI frameworks actually usable in more than toy projects (and rare exceptions). So in a sense people may see your work good enough to expect a11y. I’ve had my share of handicaps (I started to despise computer mice), so I do relate to friends which need voice input or screen readers to use modern apps and UIs, and which suffer from the amount of things that won’t work well for them (starting with mobile messengers). To me a11y is like DPI scaling - you want to have it, and you don’t want developers having to think about it for normal use cases. Otherwise it’ll always suck.
I think you’re doing a great job. We should just use something else if we want a11y. Maybe it’ll be added later, or someone creates a fork for that if they actually need it.
If anyone placed a default widget, they have used an accessibility feature. Standard qt widgets can be operated through at-spi and are partially self-describing.
If you just let it happen running defaults without special consideration for accessibility in your application the result is pretty useless for people depending on the screen reader.
“No support planned: accessibility”
That’s a real shame. LeanQt would be great. But making choices that intentionally leave people out in the cold isn’t very nice.
I think a more generous reading (and seems to be verified later in thread) is “I won’t be building … contributors wanted” instead of “No support planned”
Why do you mean? Do you need this feature?
Yes, if I want anyone to be able to use my software. Just because I’m not personally blind or disabled doesn’t mean I don’t want support.
There is still original Qt. I’m using Qt since more than twenty years and used the accessibility feature exactly one time (for a commercial application). If you think LeanQt cannot be without it, you are kindly invited to contribute it to the project; after all, that’s what open source is about.
To restate what @viraptor said up-thread:
That’s all somewhat recent development (maybe the last 10 years, even 5)? I remember that as late as the early 2010s the QT accessibility story on Linux wasn’t great. It is much improved today, and I’ve had good experiences using QT applications that use standard widgets with my screenreader.
I don’t think that; I’m just giving a reason one would not use LeanQt due to lack of accessibility support.
very motivating indeed.
Even more motivating, thank you so much.
Yes. Supporting people who need accessibility is important. And ruling out support for them entirely from the get go is a deal breaker for me.
What Qt apps are you developing? Have you ever used the accessibility features of Qt?
I have used the Qt accessibility features! I’ve done some ML for accessibility.
If so I recommend you stay with original Qt, or you can contribute the accessibility feature to LeanQt if you want.
I think people might be reading “No support planned” and reading that as “No support wanted”. Based on this feedback, it seems you are open to contributions just won’t be doing it yourself. Maybe rather than “No support planned” the same section could be “Looking for contributors to implement”. Suddenly instead of being the bad guy shutting out accessibility, you are just another incredibly overworked and underresourced open source developer who has to focus their time.
I would rather say that it is more indicative of a pretty patological zeitgeist that when you announce big volunteer efforts in this community, you don’t get a single positive feedback.
Disclaimer: I don’t intend to write any “native” GUI code in the future. I’ve used QT professionally.
But I hope to give this a little perspective:
It’s sad to see this misunderstanding. To me your previous statements regarding a11y reads like you do not intend to have this in your project (maybe for staying lean), and you don’t view it as any kind of relevant feature.
If there is one thing I actually criticize personally on all rust UI frameworks, it’s the lack of a11y (and i18n).
I do totally get why they don’t include it (it’s a lot of work which you can’t see, literally), but this is what makes UI frameworks actually usable in more than toy projects (and rare exceptions). So in a sense people may see your work good enough to expect a11y. I’ve had my share of handicaps (I started to despise computer mice), so I do relate to friends which need voice input or screen readers to use modern apps and UIs, and which suffer from the amount of things that won’t work well for them (starting with mobile messengers). To me a11y is like DPI scaling - you want to have it, and you don’t want developers having to think about it for normal use cases. Otherwise it’ll always suck.
I think you’re doing a great job. We should just use something else if we want a11y. Maybe it’ll be added later, or someone creates a fork for that if they actually need it.
If anyone placed a default widget, they have used an accessibility feature. Standard qt widgets can be operated through at-spi and are partially self-describing.
If you just let it happen running defaults without special consideration for accessibility in your application the result is pretty useless for people depending on the screen reader.
Thank you for this early holiday gift!
Welcome; glad if it is useful; also appreciate the first positive feedback so far.