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

You're writing all about UX (User eXperience), but naming a few UI (User Interface) libraries...

On Wednesday, 24 October 2018 at 13:13:53 UTC, drug wrote:
> 24.10.2018 16:00, Guillaume Piolat пишет:
>> - 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.

I'd be against using those API for GUI. Something like ImGui and Nuklear are made specifically for games in mind. For rapid prototyping and debugging. The GUI can be constructed and manipulate the logic in-place. What it does not do well is efficiency. The GUI is reconstructed from scratch every frame. This is not needed for most GUIs, that is incredibly inefficient. It suites games as you are already rendering a new frame every 16ms or so. Qt uses OpenGL I think, but it doesn't render every frame. It'll optimize to try to reduce how many frames it has to create and it doesn't re-render anything it doesn't have to.

On 24.10.2018 22:27, luckoverthere wrote:
> On Wednesday, 24 October 2018 at 13:13:53 UTC, drug wrote:
>> 24.10.2018 16:00, Guillaume Piolat пишет:
>>> - 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.
> 
> I'd be against using those API for GUI. Something like ImGui and Nuklear are made specifically for games in mind. For rapid prototyping and debugging. The GUI can be constructed and manipulate the logic in-place. What it does not do well is efficiency. The GUI is reconstructed from scratch every frame. This is not needed for most GUIs, that is incredibly inefficient. It suites games as you are already rendering a new frame every 16ms or so. Qt uses OpenGL I think, but it doesn't render every frame. It'll optimize to try to reduce how many frames it has to create and it doesn't re-render anything it doesn't have to.

You are wrong about immediate mode a little bit. Yes, someone use it like you described above. But nothing prevent you from building efficient application. You can even build retained gui using immediate one. Moreover immediate mode is more efficient than retained in some cases.

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

On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
> [...]

By the way, I develop a fork of DlangUI for a while. It is pretty raw and doesn't have some important features, has no tutorials and tooling yet.
https://github.com/dayllenger/atoll

My ideas on its design:
- use CSS for deep visual customization
- there is no fixed set of CSS properties - widgets can define their own
- mimicry to native controls with several themes
- create few powerful layouts, which will satisfy 99% of demands - free (with manual positioning), stack (with inline flow), grid layout (with fixed, percent and automatic sizes, with cell alignments, with switchable row/column alignments, etc.)
- make a possibility to embed the library into existing applications, like game engines or games themselves

For now I am collecting information to decide what kind of markup language to use, or do not use it at all. I don't really understand necessity of HTML- or QML-like languages in this situation. They facilitate app development, but wait - design may be created in Designer tool, and logic is anyway done in the D language.

On Wednesday, 24 October 2018 at 22:09:24 UTC, dayllenger wrote:
>I don't really understand necessity of HTML- or QML-like languages
> in this situation

There are lots of web developers and using HTML for native apps is not amazing but its the devil you know.

On 10/24/18 4:41 AM, Kagamin wrote:
> 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?

Yes. All of those are server-side technologies. How does that relate to a discussion about GUI technologies?

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

On 10/24/18 7:15 AM, 0xEAB wrote:
> On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
>> 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.
> 
> You're writing all about UX (User eXperience), but naming a few UI (User Interface) libraries...

UX is used here as an overarching term, many of those libraries go beyond the traditional UI capabilites with things like Audio/Video. Device integration (cameras, etc). So yes, I am listing libraries that have UX capabilities.

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

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;

On 10/24/18 1:35 AM, Dejan Lekic wrote:
> 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...

How do you know they are personal opinions and not representative of the current state of fact?

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

I don't know that a full-blown DIP is required since this will never end up in Phobos, but something like a working group might be helpful. That said even the ISO C++ Standards Committee's SG13 has been struggling with graphics for the past 7 years. Although, given that this is a C++ ISO group, that could easily be the result of non-technical factors.

I'm willing to the D Foundations point person for GUI matters, if that ends up being a thing at all.

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