The State of the GUI

Neia Neutuladh neia at ikeran.org
Thu Oct 25 00:22:38 UTC 2018


On Wed, 24 Oct 2018 16:55:05 -0700, Adam Wilson wrote:
> My team at MSFT did accessibility work and we had to follow all the ADA
> guidelines, EU rules, and internal policies when creating our HTML based
> UX. What you are describing here is not a problem with any individual
> toolkit, but the inability or unwillingness of the individual teams
> implementing the UX to use the accessibility tools of their respective
> toolkits. WPF has expansive Accessibility tooling, and indeed, all of
> the work on WPF in the .NET 4.7.x series has been on Accessibility to
> enable MSFT to meet all applicable policies for it's own WPF based apps.
>
> The problems you describe with accessibility are not related to the type
> of toolkit used. Native or Non-Native, if they don't utilize the
> accessibility features of the toolkit, it won't work right for those
> requiring accessible interfaces. I can build a completely inaccessible
> UX in any toolkit. And indeed, I've built inaccessible UX's in both
> WinForms and WPF.

It would be great if the toolkit made it simple to meet those guidelines. 
Maybe you're using a framework built on top of HTML+CSS and it helps out. 
Maybe you're using GTK+ and it does a fair bit for you. Maybe you're using 
WinForms and it falls far short, forcing you to write a lot of code.

> Specifically the goal is consistency between apps *on that platform*.
> KDE apps look like crap on GNOME and vice versa. VS Code looks exactly
> the same everywhere.

Consistency between platforms makes it a little easier to write 
documentation. Users get annoyed by applications that don't work like 
other applications on their platform.

> Not going to disagree with HTML having a garbage box-model. But that
> doesn't stop it from being the most widely used model out there.

Right, but if I'm choosing what tools to use, I'm going to prefer to use 
good ones instead of garbage ones.

> GTK works where you can accept the limitations that system comes with.

That's suggestive of abnormal limitations, but since you haven't used 
GTK+, you presumably haven't encountered them.

> Other than that I don't see why GtkD wouldn't work in D. Although on the
> preceeding thread there were a bunch of people who were unhappy with it.
> Specifically there were complaints about how well it worked on macOS and
> Windows. I've used GTK apps on Windows before, and it was immediately
> obvious to me that it was a GTK app, and it wasn't good. It functioned
> but suffered from font sizing and box model problems. GTK is great if
> you live in GNOME, outside of it, not so much.

There's an obvious solution there...


More information about the Digitalmars-d mailing list