The State of the GUI

Adam Wilson flyboynw at gmail.com
Wed Oct 24 23:55:05 UTC 2018


On 10/24/18 12:48 PM, Neia Neutuladh wrote:
> On Tue, 23 Oct 2018 23:20:05 -0700, Adam Wilson wrote:
>> At this point in time HTML/CSS/JS is by far the most prevalent UX
>> toolkit in use today and not a single modern website uses the native
>> widget theme. The bare minimum is Bootstrap.
> 
> This is terrible. As an end user, no webapp I've ever used offers a better
> experience than native applications.
> 
> I have eyesight issues that mean I need high-contrast text. I can't just
> disable CSS for your webapp, but I can and do use a GTK+ theme that offers
> sufficient contrast for me to work.
> 
> I need large text. I can trivially adjust my system's font settings to
> accommodate me. It's a lot harder to get a webapp to work properly when I
> set devPixelsPerPixel or minFontSize in Firefox.
> 
> I use the keyboard a lot. I can't rely on your webapp to use taborder
> properly, but GTK+ apps almost always have correct tab order without the
> developer putting in any effort. I also can't rely on your webapp to show
> selected items in some sensible manner, but I can in the very worst case
> make a GTK+ theme that clearly shows that.
> 
> Webapps might have largely won, but that's not good for end users.
> 
> HTML is a mildly bad format for programmatic creation and consumption of
> mixed media documents, and CSS papers over some of its missing features.
> This isn't a good basis for a widget toolkit.
> 
>> In terms of the usage of publicly available software to sample the HTML
>> stack is utilized more than all other stacks combined. Next up is mobile
>> apps, but even here usage of the default theme is in the trivial
>> minority, the vast majority of mobile apps use themes that closely match
>> the websites they are derived from.
>>
>> I think this is a key point. The theme itself is now part of a brand and
>> using the native toolkit would be a branding disaster. American Express,
>> Facebook, or Google aren't in the business of showcasing Microsoft's,
>> GNOME's, or Apple's branding, they want their apps to showcase their own
>> brands.
> 
> I don't want their branding to interfere with my experience. Right now, I
> have to browse with CSS turned off in order to read most sites, and then
> they're horribly broken.
> 
> My ideal world would give them an icon, a banner, maybe a window border
> color. Everything else would be under my theme's control.
> 

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.

>> I've never used GTK or QT, but my understanding is that both have
>> retrofitted some amount of theming into their toolkits but neither
>> approach the capabilities of WPF or HTML/CSS.
> 
> Right, because UI consistency between applications is an explicit goal of
> most native toolkits, and making normal layouts simple is a greater focus.
> 

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.

>> There are other reasons that native toolkits died however. The first is
>> data visualization. What can be expressed in 10 lines of WPF code would
>> take anywhere from 100-1000 of Win32 code to depending on the
>> visualization. Non-native toolkits allow UX designers to express the
>> data using the most intuitive visualization for that data, without being
>> constrained by the native widget toolkit, and often allow the designer
>> to do so in a trivial fraction of the time. The amount of time required
>> to implement the best visualizations can easily be cost-prohibitive.
> 
> This could really use a more concrete example. SVG is a pretty
> straightforward format (if you stick to the simple parts) that has allowed
> me to create visualizations easily. It's not that much code to display an
> SVG.
> 
> Maybe if you're talking about interactivity? At that point, my instinct
> would be to try embedding SDL, but I haven't even looked at this in the
> past.
> 

The last time I tried it was a decade ago, shortly before I gave up and 
switched to WPF. But I have written custom WinForms controls, and it 
ended up being hundreds of lines of code to do what 10 lines of WPF did. 
I can't give the example because it is a proprietary in-house app.

>> Another is that in my experience even native toolkits, such as DWT, that
>> can be used to build cross-platform interfaces tend to produce mixed
>> results. You run into a plethora of minor issues surrounding differing
>> Fonts/Paddings/Margins etc. So even though the toolkit itself may be
>> cross platform you still need to create three separate interfaces to
>> iron out these small but noticeable details. Electron and non-native
>> widgets solve these problems entirely.
> 
> My experience is that flex layouts greatly reduce this problem, while
> pixel layouts give you this problem in spades. When using Windows Forms, I
> had a lot of padding issues, but with GTK+, I've only looked at padding on
> rare occasions.
> 

That is true, but most are not implemented that way in practice. At 
least in my experience.

> But HTML seems to have garbage defaults, and it's awkward to work with
> CSS, so I've had a decent amount of annoyance working with padding and
> margins in HTML.
> 
> And with web applications, my experience is that they use Chrome-only
> features often enough to cause problems using any other browser.
> 

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.

>> Native toolkits are a dead-end. The future of non-Web UX is non-native.
> 
> HTML-based UIs seem to be quite popular, certainly.
> 
>> So why doesn't D have ANY useful bindings UX library bindings?
> 
> GtkD is quite useful, I'd say.
>  >> The answer, I think, is that almost every case, the UX toolkit in
>> question was designed for a specific language, Qt->C++,
>> GTK/MacOS/Win32->C, SWT->Java, WPF->.NET, etc. and these toolkits are
>> often deeply integrated with the languages they are implemented in.
> 
> GTK+ integrates well with a decent variety of languages. They created a
> system to handle this called GObject Introspection, which is a
> programmatically consumable set of interfaces that you can use to
> construct a binding to a GTK+ style library. GtkD uses this to do the vast
> majority of its work (maybe 15KLOC hand-written, over 400KLOC generated),
> and I've previously used the binding generator to get bindings to
> libwebkit2gtk.
> 
> SWT integrates with JVM languages, so you could use it with Javascript,
> Python, or Ruby in addition to the JVM-specific languages. That's not a
> huge set and ties you to that platform, so it's not something you can just
> integrate into an existing workflow that doesn't involve the JVM.
> 
>> And none of this is even counting the tooling ecosystem that would be
>> recreate from scratch. Qt has QML, WPF and UWP have different flavors of
>> XAML. There are special pre-compilers. The list goes on. So when
>> individual sets out to bind a UX toolkit they inevitably flame-out
>> because the amount of effort required to get something simple working is
>> enormous.
> 
> Again, GTK+. The tooling is just a user interface designer, Glade. It's an
> independent application that gives you an XML file describing your UI. You
> can trivially use it in a GTK+ application written in C, C++, Python, D,
> Vala, Rust, R, Lua, Javascript, even FreeBASIC.
> 
> This isn't as awesome as it could be because it doesn't have that language
> integration, but fixing that is straightforward. It's about 150 lines of
> code that I should clean up and PR for GtkD:
> 
> https://git.ikeran.org/dhasenan/muzikilo/src/branch/master/source/muzikilo/
> fasado.d#L537
> 

GTK works where you can accept the limitations that system comes with. 
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.

-- 
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;


More information about the Digitalmars-d mailing list