The State of the GUI
Adam Wilson
flyboynw at gmail.com
Wed Oct 24 06:20:05 UTC 2018
I was reading the hijacked JAXLondon thread about GUI's and started
replying but decided against hijacking the already hijacked thread again.
I've been working with UX toolkits since the earliest days of my career
and it was one of the first things I looked for when I started using D
in 2011. Needless to say I wasn't impressed. As a result I've done some
fairly extensive research over the years on, not just the effort
required to bring one to D, but also on what people are actually using.
This discussion invariably falls into a firefight between two camps,
native-widgets and non-native widgets. I know that this topic can bring
out the rage-trolls so I want to state upfront that the native widget
camp is the losing bet if we care about the future. Please allow me to
explain.
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.
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.
Somewhat unusually for Microsoft they recognized this shift in industry
early and starting with WPF in 2006 they have allowed you to completely
customize the look of widgets. WPF actually began as an (however
misguided) attempt to improve on the UX capabilities of HTML/CSS. They
continued this direction with Silverlight and most recently, UWP. UWP is
intended as the long-term replacement for the Win32 UX API's and
Microsoft is no longer developing the Win32 API's, it's just bug fixes now.
However, WPF suffers from it's own scope and Microsoft's inherent
myopia. WPF is massive, over 30,000 classes, it's Windows only, and it
can be agonizingly slow in certain usages. In theory it could be ported
to other systems, but it's heavily tied into DirectX so it would be an
enormous amount of work in practice. They addressed some of the problem
with Silverlight which worked on OSX (but only in Safari) and cut down
on the number of classes significantly. That said, Silverlight never
caught on as a replacement for HTML/CSS and was unceremoniously canceled
in 2011. Both projects were developed by DevDiv which meant that they
had great tooling but did not necessarily utilize the OS level API's
very well. UWP was developed by WinDiv as the next-generation UX API for
Windows.
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.
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.
The second is Electron. Electron is a terrible framework for a host of
reasons. But the one thing that it achieved is the
write-once-run-anywhere (WORA) desktop UX toolkit. If you use the native
toolkit you are stuck writing a different interface for each toolkit.
That again is cost prohibitive and indeed is a large part of the reason
that Microsoft dominated the desktop in the 90's and 00's. Companies
only wanted to build one UX so they built for the most common OS, which
at the time was Windows. Now with Electron you can design a UX once,
using all the HTML/CSS talent you already have an deliver to any
platform that Electron supports. VS Code looks and functions identically
on all three major platforms.
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.
Native toolkits are a dead-end. The future of non-Web UX is non-native.
So why doesn't D have ANY useful bindings UX library bindings?
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.
And it is for this reason that I understand why the native toolkit camp
pushes so hard for D to get a native widget toolkit. Somebody else has
done the hard work of building a C API for a high-quality toolkit. The
problem is that it's really a C+Preprocessor API. I maintain the only
current bindings to DirectX for D and even I haven't ported most of the
Macros. And Win32 is loaded with macros.
Then there is the fact that by definition, any UX toolkit requires an
absolutely gargantuan number of interfaces to achieve the desired
result. My DirectX interface is tiny compared to the Win32 UX
interfaces, and it's something like 16000 lines of D code, without macros.
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.
And that brings us to the final problem with UX in D. The amount of time
it takes to bring any UX toolkit into D is
Just before it's release Tim Sneath published a list of MSFT developers
who were actively blogging about WPF. There are 19, and I strongly doubt
that is everyone. But it would be fair to say that it took at least 20
people 5 years to develop WPF (2001-2006). WPF had MSFT, Qt had
Trolltech/Nokia/etc. Gnome has RedHat and more. Electron had GitHub.
The underlying theme here is that it takes an enormous pile of resources
to make a good UX toolkit. D has never had the kind of corporate backing
that the other toolkits have. So it should come as no surprise that
large scale projects, like UX have been unattainable to date.
The D community, for all it's wonderful attributes does not have a
"team" mindset. And this bears out if you audit code.dlang.org. The
projects are universally the herculean efforts of one person, and
occasionally a small number of secondary contributors.
The way I see it. We either pull together around a unified vision for a
UX toolkit written in D from the ground-up or we wait (im)patiently for
a benevolent corporate benefactor to appear. It's that simple.
I do have a vision for a non-native, WPF-like, UX toolkit written
entirely in D. I estimate that it will take a minimum of three extremely
dedicated, multi-disciplinary, individuals about three to five years to
complete with the help of a constellation of secondary contributors. I
have a rough design sketched out and I'd be happy to post it here but
this message is already getting to long.
This isn't the first time I've asked for help. And to be perfectly
honest, I expect the same crickets response I've gotten before, but if
you are interested and willing to dedicate yourself. Please let me know.
I firmly believe that a non-native, cross-platform, UX library will open
D up to a whole new market of users that are desperate for something
better than what they have now.
--
Adam Wilson
IRC: EllipticBit
import quiet.dlang.dev;
More information about the Digitalmars-d
mailing list