The State of the GUI

[Neia Neutuladh]

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.

> 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.

> 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.

> 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.

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.

> 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