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;

A few notes:

1. I would caution against necessarily conflating "current direction of trends" with "the future."

2. I would caution against viewing "what the future holds" as a single entity to be guessed at and later revealed, rather than as "what we, the creators, CHOOSE for it to be."

3. Transitively, I would caution against conflating "current direction of trends" with "what we, the creators, should be doing." We're the developers. We're the creators. Leave the bandwagon-chasing and circular-tail-sniffing-fests to the MBAs.

4. I would caution against taking myopic, self-absorbed corporate-interest motivators (such as "our branding before the platform's branding") as higher-priority than *THE USER'S BEST INTEREST* when creating a product *FOR THE USERS TO USE*.

5. In any endevour of creation, at some point, you have to ask yourself: "Who is this being creating for? For myself/ourselves, or for the people who we HOPE will actually CHOOSE to use it?" Maybe the answer really is door #1 instead of door #2, but if so, that's when we know it's time to retire the "creator" hat, don an overpriced suit, go to MBA school, sit in a padded office, and stay far out of the way of those under you who have REAL expertise and REAL work to do.

6. I've noticed that your entire several-page post and you're entire argument regarding user-interface decisions makes absolutely ZERO mention whatsoever of THE USER (aside from misusing the term "UX" to mean "GUI API"), let alone ANY attempt at analysis whatsoever of what is better or worse for a user.

Summary: This is exactly what's wrong with technology.

Addendum: I *do* grant you make some interesting points, definitely worth being aware of. I just find that failing to relate them to the actual user in any way renders the analysis purely academic and the conclusions to be of questionable relevance.

I will concede that I'm a native-UI proponent, and that I would have been less motivated to say anything had your conclusions been the opposite. However, FWIW, I do also believe the objection I raise above would still stand regardless of the original post's conclusion.

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
> 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.

How? I'm the author of a native UI toolkit and I've no idea how many people are using it. But I know a lot of people are though. Most people will never tell you they use your stuff.

https://github.com/nomad-software/tkd

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

I disagree and this is impossible to measure. Don't confuse web with native both have use-cases.

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

I would have thought this would have been included in any 'research' you've done?

> There are other reasons that native toolkits died however.

What? Native toolkits haven't died.

> Native toolkits are a dead-end. The future of non-Web UX is non-native.

I think this is more of an opinion than concrete fact.

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

It took me 6+ months (part-time) for the above linked toolkit. You just need dedicated hard work.

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

I don't believe this at all. We just need better documentation for the native libraries we have available.

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
> I was reading the hijacked JAXLondon thread about GUI's and started replying but decided against hijacking the already hijacked thread again.
>
> [...]

Bunch of personal opinions I mostly disagree with...

The only thing I *do* agree however is that D community deserves a GUI toolkit similar in power and design to the JavaFX or WPF (as you obviously like it, and I do not deny that WPF is designed awesomely).

I use DlangUI at the moment for small things, but in all honesty it can't compare with JavaFX/Swing (that I am most familiar with).

Unfortunately it seems that D GUI community is diverse, interested in different things, and have different ideas how the *retained* GUI should be implemented.
I used to be FLTK developer in the past and know perfectly how even very small community can have different opinions that result in various forks or even worse lose of interest.

The only way forward, IMHO, is to make a huge DIP for the retained GUI toolkit and ask the existing D GUI community members to participate and once the design is clear participate in the implementation.

To be frank, I think the D Foundation should drive this and help with establishing and maintaining these kind of "working groups" (similar to how Java community process works)

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
> Native toolkits are a dead-end. The future of non-Web UX is non-native.

Last I checked Microsoft bets its money on cloud, asp.net core and typescript. See where the wind blows?

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
> So why doesn't D have ANY useful bindings UX library bindings?
>

There are: https://github.com/DerelictOrg/DerelictCEF

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

Without too much resources to invest topdown it's about building-blocks that multiple individuals can create.

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

Indeed, but all it takes is that each individual separates its herculean efforts in sub-packages, decouple them, and publicize them so that harder and harder projects can be built on top (with respecting SemVer and not staying in 0.x.y).

It's only slightly harder and the project usually benefit from decoupling.

One of the problem is the DUB registry search doesn't work.

That's why a registry-global search of symbols is so important, and two people have one solution to this: Adam and Webfreak.


> This isn't the first time I've asked for help.


Honestly UI toolkits are indeed coupled, perhaps unnecessarily, and I think we could strive to find something much more "Design by Introspection":


color abstraction (eg: `std.experimental.color`) <= image abstraction (eg: `ae.utils.graphics`)
image abstraction <= image decoder (eg: `imageformats`)
windowing (eg: dplug.window or something stealing it and making it SDL-like) <= Canvas renderer (eg: `printed`)
Canvas renderer + open-methods/ECS <= widget library (for a UI you need widgets that don't depend to the rendering method, and that's an open-method problem)
layout-system (something CSS-like) <= widget-library

Every one of these packages can work without the others, and essentially is not so opinionated.

(Anything based on OpenGL would be hopeless I think. But anything GPU-based and not OpenGL need some kind of shader compiler which is also too much work. So I think for the purpose of practicality it can be left as an exercise)

This would give a very basic portable GUI, without forgetting our big DbI principles, and the BIG work would be to make all this modules work well with each other. For example libraries need to be maintained to newer compilers, bug fixed, major tag respected.

24.10.2018 15:30, Guillaume Piolat пишет:
> Honestly UI toolkits are indeed coupled, perhaps unnecessarily, and I think we could strive to find something much more "Design by Introspection":
> 
> 
> color abstraction (eg: `std.experimental.color`) <= image abstraction (eg: `ae.utils.graphics`)
> image abstraction <= image decoder (eg: `imageformats`)
> windowing (eg: dplug.window or something stealing it and making it SDL-like) <= Canvas renderer (eg: `printed`)
> Canvas renderer + open-methods/ECS <= widget library (for a UI you need widgets that don't depend to the rendering method, and that's an open-method problem)
> layout-system (something CSS-like) <= widget-library
very interesting, I thought about it but without details like you

> 
> Every one of these packages can work without the others, and essentially is not so opinionated.
> 
> (Anything based on OpenGL would be hopeless I think. But anything GPU-based and not OpenGL need some kind of shader compiler which is also too much work. So I think for the purpose of practicality it can be left as an exercise)
> 
Why opengl based would be hopeless? Could you elaborate?

On Wednesday, 24 October 2018 at 12:43:52 UTC, drug wrote:
> very interesting, I thought about it but without details like you

It's like solving climate change with ocean alcalinisation: it seems doable, but will require unnatural degrees of _collaboration_. Hence why it's difficult.


>> Every one of these packages can work without the others, and essentially is not so opinionated.
>> 
>> (Anything based on OpenGL would be hopeless I think. But anything GPU-based and not OpenGL need some kind of shader compiler which is also too much work. So I think for the purpose of practicality it can be left as an exercise)
>> 
> Why opengl based would be hopeless? Could you elaborate?


There is a host of reasons:

- Because every OpenGL driver is deeply broken. (i've been a professional OpenGL developer for years)

- Because if you properly abstract 3D rendering you come to something like bgfx, which is a multi man-years project in itself. Because bgfx is not a simple API but the 2D APIs are. If bgfx had a shader compiler embedded at runtime it will be a good solution, for now it's an offline tool hence coupling is huge.

- OpenGL does not "work everywhere". It's deprecated on macOS. In general portable APIs don't make any giant any money: the trend is fragmentation hence why abstraction over specific APIs is a must: that's where Unity was better than anyone else.

24.10.2018 16:00, Guillaume Piolat пишет:
> On Wednesday, 24 October 2018 at 12:43:52 UTC, drug wrote:
>> very interesting, I thought about it but without details like you
> 
> It's like solving climate change with ocean alcalinisation: it seems doable, but will require unnatural degrees of _collaboration_. Hence why it's difficult.
Unfortunately, I am totally agree. In fact collaboration will be really difficult.

> There is a host of reasons:
> 
> - Because every OpenGL driver is deeply broken. (i've been a professional OpenGL developer for years)
> 
> - Because if you properly abstract 3D rendering you come to something like bgfx, which is a multi man-years project in itself. Because bgfx is not a simple API but the 2D APIs are. If bgfx had a shader compiler embedded at runtime it will be a good solution, for now it's an offline tool hence coupling is huge.
> 
> - OpenGL does not "work everywhere". It's deprecated on macOS. In general portable APIs don't make any giant any money: the trend is fragmentation hence why abstraction over specific APIs is a must: that's where Unity was better than anyone else.
> 
So, nothing specific to OpenGL (it can be related to any other technology). But in general I am agree with again - renderer shouldn't be fixed. I recently started using `nuklear`, immediate gui c library. it's totally platform and renderer agnostic. We could use this way.