Painting overlapping transparent controls with BGRA

[mse]

Having handles for each control simply allows assistive external software to cooperate better. And not just assistive software, also GUI testing software (the LCL is badly suited already with generic instead of class names for Windows classes, but at least it has handles per control).

Also on Qt?

[CCRDude]

Can't answer that yet (does that question point at handles, or assistive software, or GUI testing software, or class names?). Our main focus is still on the win32 widgetset (Delphi legacy), and I've just a few minutes ago for the first time compiled a new prototype with Lazarus on the Mac (carbon widgetset).

Due to the nature of our software (anti-malware), our main field will continue to be Windows, but when rewriting in Lazarus, I try to keep other platforms in mind.

[mse]

AFAIK Qt switched to a single handle per form some years ago.
http://blog.qt.io/blog/2007/08/09/qt-invaded-by-aliens-the-end-of-all-flicker/

MSEgui used that approach from start, see also the comments from Graeme and me.

[CCRDude]

Not sure if I follow your argument... does it make anything better that more are doing this?

Are you saying we should discriminate (I'm not implying that anyone here wants to do so) visually impaired people because more and more frameworks do it?

I probably need to set up a new virtual machine with proper screen reader software to test Qt, fpGUI, MSEgui apps, but I don't see any real argument in saying "but others don't do this as well"

Also, I know that automated GUI tests are not something done by most developers, but we're talking about a free software with tens of millions of users here. If we can automate UI tests in a good way, we'll save hours, days, possibly weeks of support work.

[mse]

The argument is that having a single handle per form has many advantages expecially for cross platform environments and designs with many widgets, see also:
http://blog.qt.io/blog/2011/02/23/alien-widgets-on-mac/
Transparency is another argument. ;-)
Just for  illustration, a MSEgui form with 10000 TButton:
http://mseide-msegui.sourceforge.net/pics/manybuttons.mpeg
This is on an aged AMD Athlon 64 X2 4000+ PC where the screen capture tool eats most of CPU power.
The project is here:
https://gitlab.com/mseuniverse/mseuniverse/tree/master/testcase/benchmark/runtimebutton

Screen reader interfaces don't necessarily need a handle per widget, there are other possibilities to implement the connection. MSEgui widgets for example implement "IAssistiveClient" so one could make a TAssistiveServer descendent which connects to standard screen readers.

[Graeme]

I know SAK, and have tested it before, and it's indeed excellent. Point is that it's a separate system. Visually impaired customers usually already have some kind of screen reader software. Forcing them to use something else is against all UX principles.

Then clearly you haven't been around on Linux, FreeBSD and Solaris much. Each of those have different assistive systems too - compared to Windows. Even under Linux I know of about 4 different systems - all pretty crappy if you ask me.

At least with SAK it is just as cross-platform as fpGUI - reducing the programming effort for the developer, and shorter time to get your product out there. At least having assistive support is better than nothing.

Having handles for each control simply allows assistive external software to cooperate better.

That's not a problem for fpGUI. Up to fpGUI v1.4.1, each widget has its own window handle. From fpGUI v2.0 onwards the framework now defaults to only top-level windows having a handle, but you can still toggle it so each widget has its own window handle again (but then you have reduced graphics capabilities).

[CCRDude]

I just have finished my test virtual machine with JAWS, the most widely spread screen reader software.

• I tested a few standard LCL apps and they were read correctly.
• I started MSEide, and it failed to speak anything other than mentioning I pressed the Tab key.
• I haven't yet tested a fpGUI app, since I didn't find any binaries and am working remotely today, so switching machines to try things takes time.

PS: The 10.000 button issue is a design (concept & UI) problem, not a framework problem, in my mind.

[mse]

• I started MSEide, and it failed to speak anything other than mentioning I pressed the Tab key.

Feel free to make a TAssistiveServer descendent which connects to JAWS or use SAK.

PS: The 10.000 button issue is a design (concept & UI) problem, not a framework problem, in my mind.

I know frameworks which have problems with much less than 10'000 buttons already. ;-)