Please, please, please don’t use a GUI toolkit like this, that draws its own widgets rather than using platform standard ones, when developing a plugin for a digital audio workstation (e.g. VST or Audio Unit), as this author is apparently doing. Unless someone puts in all the extra effort to implement platform-specific accessibility APIs for said toolkit. Inaccessible DAW plugins are a problem for blind musicians and audio engineers because of GUI toolkits like this one. Maybe screen readers will eventually use some kind of machine learning to provide access to otherwise inaccessible GUIs, but that’s probably still a long way off. So for now, we need application developers to do their part.
I don’t actually know what the best cross-platform solution is. Is wxWidgets fully functional in a context where it doesn’t own the event loop? I suspect not on Windows in particular. Yes, yes, I know it’s ugly 90s C++, but really, what’s more important, code aesthetics or usability?
Unfortunately, there’s no way to make platform standard widgets work in audio plugin UIs on Linux. On Mac and Windows, yes, you can do this, but I’m not aware of any company that does. Perhaps Sinevibes ships their Mac plugins with some custom skinning on top of AppKit widgets. On Linux, by the way, this is a combination of event loop issues and dynamic linking. Trying to run a GTK2 UI inside of a GTK3 app is apparently completely broken on account of this.
Aesthetics matter in these applications, and there are plugin companies that have built reputations on the back of their user interfaces (Fabfilter in particular comes to mind).
Say, for example, that I’ve developed a UI engine like this and I’d like to implement the platform-specific accessibility APIs for it. Do you have any good resources for what that code should look like?
Isn’t this just a matter of adding the necessary accessibility hooks in the widgets? No saying it is easy but surely there is a way to write a GUI library that draws directly to the screen and has good accessibility features.
In principle, yes. In practice it seems it’s a ton of work to DIY the integration with every platform’s hooks, and nobody has sufficiently abstracted the various a11y APIs to provide a simpler cross-platform library that you could plug into. As a result I believe the only non-native GUIs that have managed to produce decent cross-platform support for mapping their GUI widgets to the platform’s a11y systems are the major browsers, which are obviously huge codebases with a lot of dev resources.
There are some initial attempts in other toolkits, but I don’t think any of them work well on more than one platform. GNOME is cross-platform but has a good a11y story only on Linux, with a very basic start at porting any of it to Windows. Mono at various points had a start at hooking into things on multiple platforms, but I’m not sure what the current state of things in the post-Mono .NET world is.
Note that this would appear to be different from the QNX windowing system.
It’s really confusingly named.
Photon microGUI is registered trademark #2025191 in the US.
Joel is also author of C++ parser combinator
That was high enough architectural and implementation quality to be accepted into boost (I last used it about 10 years back) – not an easy feat…
He is asking for some hands to continue the framework on other platforms, I am sure whoever joins the project will pick up some exceptional modern C++ programming skills.