www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - The State of the GUI

reply Adam Wilson <flyboynw gmail.com> writes:
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;
Oct 23 2018
next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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 

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.
Oct 24 2018
next sibling parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
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.
Oct 24 2018
prev sibling parent reply rjframe <dlang ryanjframe.com> writes:
On Wed, 24 Oct 2018 03:29:58 -0400, Nick Sabalausky (Abscissa) wrote:

 3. Transitively, I would caution against conflating "current direction
 of trends" with "what we, the creators, should be doing." [snip...]
 
 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?" [snip...]
 
 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
I agree with what you're saying, but could you elaborate as to what you see that is being ignored? Other than performance considerations (which is why I'll never even consider Electron), I don't see much in that post that would have a direct and major impact on end-users -- though there would be many followup conversations that would need to. I guess I think of a UI toolkit's primary audience being the developers, and the developer's audience is the end-user; there are things the UI toolkit needs to do for the end-user, but ultimately UX is up to the application developer. -Ryan
Oct 25 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 26/10/2018 12:09 AM, rjframe wrote:
 I guess I think of a UI toolkit's primary audience being the developers,
 and the developer's audience is the end-user; there are things the UI
 toolkit needs to do for the end-user, but ultimately UX is up to the
 application developer.
If a GUI toolkit does not interact with the system's accessibility API's it isn't the developers which suffer its the end-users. But I agree with you that the GUI toolkit developers are ultimately not responsible for the UX of a GUI. But they can certainly do a lot to make it more likely to be correct for the end user.
Oct 25 2018
prev sibling next sibling parent reply Gary Willoughby <dev nomad.uk.net> writes:
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.
Oct 24 2018
parent Adam Wilson <flyboynw gmail.com> writes:
On 10/24/18 1:14 AM, Gary Willoughby wrote:
 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
Asking is often a terrible way to discover things. For example, I can instantly tell if it's an Electron app (CPU spikes and memory usage is atrocious). WPF apps often have text rendering issues because they forgot to opt-in the improved text rendering modes, or the app has a non-native look and isn't obviously a UWP app (UWP apps are installed differently so they are ridiculously easy to differentiate). GTK apps often look non-native on KDE/Windows/macOS, where Qt apps often look non-native in GNOME/Windows/macOS. On the mobile world, just go to the apps store and look at the screenshots of the top 100. None of them use the native interface widgets. And I haven't visited a website that used native widgets since the early 2000's. So in that respect, a simple passive survey can cover a statistically useful sample. Note that I cannot always pinpoint precisely which toolkit was used, but enough to know whether or not it is native or non-native and whether or not it is native to that OS/DE is trivial.
 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.
If by died you mean disappeared than I agree. But dead can also mean "no significant new work". In so far as no major new apps are being developed using native toolkits, and in the age of HTML and Mobile apps I think this is undeniably the case.
 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.
How so? Show me a popular mobile app that uses the default widget set. Show me a new large scale desktop app that uses the native. I have done my best to provide examples, but since I can't post pictures to forum messages I am asking for a little bit of googling. :)
 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.
Indeed. That was kind of my point. Especially the dedicated part. :)
 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.
Well, D has GtkD, DlangUI, and others. I imagine that the GTK docs are sufficient to working well enough, so I do seriously doubt that quality docs are the *only* thing holding back D GUI's, it certainly would not hurt to have better docs. But given that most of the available toolkits are bindings, pretty good docs already exist. -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 24 2018
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
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)
Oct 24 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
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;
Oct 24 2018
parent Dejan Lekic <dejan.lekic gmail.com> writes:
On Thursday, 25 October 2018 at 00:00:49 UTC, Adam Wilson wrote:
 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.
Precisely! I am not sure D community at current state would more than what C++ people tried to do... It requires huuuuge effort to come up with solution that is agreeable upon by all interested parties. Not impossible, but problem is - this requires a full-time job, IMHO.
Nov 19 2018
prev sibling next sibling parent reply Kagamin <spam here.lot> writes:
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?
Oct 24 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
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;
Oct 24 2018
parent reply Kagamin <spam here.lot> writes:
On Wednesday, 24 October 2018 at 23:30:50 UTC, Adam Wilson wrote:
 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?
They have corresponding client-side technologies, which are the GUI. Web is the better solution for all problems you speak about. On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
 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.
If only web did it right. In theory it can, but in practice it does it rarely. https://abload.de/img/tmpfzfuo.png is https://www.webbyawards.com/winners/ - a web design awards site, see the fonts and margins. And most cheap sites including google do it like this.
Oct 25 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/25/18 1:47 AM, Kagamin wrote:
 On Wednesday, 24 October 2018 at 23:30:50 UTC, Adam Wilson wrote:
 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?
They have corresponding client-side technologies, which are the GUI. Web is the better solution for all problems you speak about. On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
 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.
If only web did it right. In theory it can, but in practice it does it rarely. https://abload.de/img/tmpfzfuo.png is https://www.webbyawards.com/winners/ - a web design awards site, see the fonts and margins. And most cheap sites including google do it like this.
No arguments from me. So let's do it right. -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 27 2018
parent reply Kagamin <spam here.lot> writes:
On Sunday, 28 October 2018 at 05:56:21 UTC, Adam Wilson wrote:
 No arguments from me. So let's do it right.
https://newsroom.ibm.com/2018-10-28-IBM-To-Acquire-Red-Hat-Completely-Changing-The-Cloud-Landscape-And-Becoming-Worlds-1-Hybrid-Cloud-Provider
IBM To Acquire Red Hat, Completely Changing The Cloud Landscape 

Most significant tech acquisition of 2018 will unlock true value 
of cloud for business
IBM and Red Hat to provide open approach to cloud, featuring 
unprecedented security and portability across multiple clouds
Deal accelerates IBM's high-value business model, making IBM the 

Red Hat to operate as a distinct unit within IBM's Hybrid Cloud 
team
$34 billion were just launched into cloud, not Qt, not UWP. $1 trillion growth market.
Oct 29 2018
parent Paolo Invernizzi <paolo.invernizzi gmail.com> writes:
On Monday, 29 October 2018 at 15:15:44 UTC, Kagamin wrote:
 On Sunday, 28 October 2018 at 05:56:21 UTC, Adam Wilson wrote:
 No arguments from me. So let's do it right.
https://newsroom.ibm.com/2018-10-28-IBM-To-Acquire-Red-Hat-Completely-Changing-The-Cloud-Landscape-And-Becoming-Worlds-1-Hybrid-Cloud-Provider
IBM To Acquire Red Hat, Completely Changing The Cloud Landscape 

Most significant tech acquisition of 2018 will unlock true 
value of cloud for business
IBM and Red Hat to provide open approach to cloud, featuring 
unprecedented security and portability across multiple clouds
Deal accelerates IBM's high-value business model, making IBM 

market
Red Hat to operate as a distinct unit within IBM's Hybrid Cloud 
team
$34 billion were just launched into cloud, not Qt, not UWP. $1 trillion growth market.
Someone is not so happy about that move: as usual, a news is a news, and you can extract whatever you want from it. https://www.zerohedge.com/news/2018-10-28/desperation-move-ibm-buys-red-hat-34-billion-largest-ever-acquisition https://www.zerohedge.com/news/2018-10-29/ibm-bond-yields-default-risk-spike-after-red-hat-deal
Oct 29 2018
prev sibling next sibling parent reply Guillaume Piolat <spam smam.org> writes:
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.
Oct 24 2018
parent reply drug <drug2004 bk.ru> writes:
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?
Oct 24 2018
parent reply Guillaume Piolat <spam smam.org> writes:
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.
Oct 24 2018
parent reply drug <drug2004 bk.ru> writes:
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.
Oct 24 2018
parent reply luckoverthere <luckoverthere gmail.cm> writes:
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.
Oct 24 2018
parent reply drug <drug2004 bk.ru> writes:
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.
Oct 24 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/24/18 12:39 PM, drug wrote:
 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.
You are both technically correct, but the word "efficiency" can be used in two different ways here. Immediate mode can be incredibly efficient from a rendering performance standpoint. But in general they are much less efficient than retained mode from a developer standpoint. So the question is, what kind of efficiency is more important? My vote is for developer efficiency. Most UX's need a minor fraction of what even an Intel GMA 3000 can pump out, much less that of what a Vega64 or GeForce RTX 2080 Ti. I only have a Radeon Pro WX4100 because of the fact that it has four DP1.2 outputs in a half-height form factor. I certainly never get with a parsec of actually stressing the capacity of rendering silicon. But if I can do something with 10 lines of code over 1000 lines of code I will take that option ever single time. My time is WAY more expensive than some GPU time. -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 24 2018
next sibling parent drug <drug2004 bk.ru> writes:
25.10.2018 03:24, Adam Wilson пишет:
 You are both technically correct, but the word "efficiency" can be used 
 in two different ways here. Immediate mode can be incredibly efficient 
 from a rendering performance standpoint. But in general they are much 
 less efficient than retained mode from a developer standpoint. So the 
 question is, what kind of efficiency is more important?
 
 My vote is for developer efficiency. Most UX's need a minor fraction of 
 what even an Intel GMA 3000 can pump out, much less that of what a 
 Vega64 or GeForce RTX 2080 Ti. I only have a Radeon Pro WX4100 because 
 of the fact that it has four DP1.2 outputs in a half-height form factor. 
 I certainly never get with a parsec of actually stressing the capacity 
 of rendering silicon.
 
 But if I can do something with 10 lines of code over 1000 lines of code 
 I will take that option ever single time. My time is WAY more expensive 
 than some GPU time.
 
Combining power of D metaprogramming and immediate gui I have both developer efficiency and rendering performance efficiency. For example I failed to implement custom tree view using Gtk and Qt/Qml and it was really simple to do it using immediate gui. But I see drawbacks of immediate gui too.
Oct 25 2018
prev sibling parent reply Willow <me not.here> writes:
On Thursday, 25 October 2018 at 00:24:42 UTC, Adam Wilson wrote:
 On 10/24/18 12:39 PM, drug wrote:

 You are both technically correct, but the word "efficiency" can 
 be used in two different ways here. Immediate mode can be 
 incredibly efficient from a rendering performance standpoint. 
 But in general they are much less efficient than retained mode 
 from a developer standpoint. So the question is, what kind of 
 efficiency is more important?
Having never used retained mode Im struggling to understand how it's going to result in a vast saving in terms of code you have to write. I mean somewhere someone has to write the code that draws the widget, i dont see how immediate mode makes that any different. Also I kind of hate the fact that alot of modern apps have such laggy GUIs, I mean it's seriously fucking pathetic that with all the silicon we have simple apps like spotify are laggy when drawing. Even VS Code feels laggy to me.
 My vote is for developer efficiency.
My vote would be choice, if you force one mode or the other then you will lose people, and you need people, developers and users.
 Most UX's need a minor fraction of what even an Intel GMA 3000 
 can pump out, much less that of what a Vega64 or GeForce RTX 
 2080 Ti. I only have a Radeon Pro WX4100 because of the fact 
 that it has four DP1.2 outputs in a half-height form factor. I 
 certainly never get with a parsec of actually stressing the 
 capacity of rendering silicon.
Will all the rendering be on the GPU? My experience is that in a lot of cases 2D rendering is done on the CPU. Font rendering is generally still done on the CPU afaik.
 But if I can do something with 10 lines of code over 1000 lines 
 of code I will take that option ever single time. My time is 
 WAY more expensive than some GPU time.
Ok, so it's retained mode and GPU rendering. A bunch of people just left the room. And you seriously think it's 10 lines vs 1000 lines? I'm asking not criticising since I dont really know how retained mode works tbh.
Oct 25 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/25/18 1:53 AM, Willow wrote:
 On Thursday, 25 October 2018 at 00:24:42 UTC, Adam Wilson wrote:
 On 10/24/18 12:39 PM, drug wrote:

 You are both technically correct, but the word "efficiency" can be 
 used in two different ways here. Immediate mode can be incredibly 
 efficient from a rendering performance standpoint. But in general they 
 are much less efficient than retained mode from a developer 
 standpoint. So the question is, what kind of efficiency is more 
 important?
Having never used retained mode Im struggling to understand how it's going to result in a vast saving in terms of code you have to write. I mean somewhere someone has to write the code that draws the widget, i dont see how immediate mode makes that any different. Also I kind of hate the fact that alot of modern apps have such laggy GUIs, I mean it's seriously fucking pathetic that with all the silicon we have simple apps like spotify are laggy when drawing. Even VS Code feels laggy to me.
Completely agree, and both of those are Electron which is just Chrome with some fancy packaging. Electron is a memory hog. We can do better than that. Much better.
 
 My vote is for developer efficiency.
My vote would be choice, if you force one mode or the other then you will lose people, and you need people, developers and users.
And that is exactly what non-native toolkits provide, you can either use the packaged themes that match the DE or you roll your own. Custom styling a native widget toolkit is possible but significantly more involved.
 
 Most UX's need a minor fraction of what even an Intel GMA 3000 can 
 pump out, much less that of what a Vega64 or GeForce RTX 2080 Ti. I 
 only have a Radeon Pro WX4100 because of the fact that it has four 
 DP1.2 outputs in a half-height form factor. I certainly never get with 
 a parsec of actually stressing the capacity of rendering silicon.
Will all the rendering be on the GPU? My experience is that in a lot of cases 2D rendering is done on the CPU. Font rendering is generally still done on the CPU afaik.
That depends on the API, on Windows you have DirectWrite which renders fonts on the GPU.
 
 But if I can do something with 10 lines of code over 1000 lines of 
 code I will take that option ever single time. My time is WAY more 
 expensive than some GPU time.
Ok, so it's retained mode and GPU rendering. A bunch of people just left the room. And you seriously think it's 10 lines vs 1000 lines? I'm asking not criticising since I dont really know how retained mode works tbh.
I don't think. I know. I get paid to do it. :) -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 25 2018
parent Willow <me not.here> writes:
On Thursday, 25 October 2018 at 09:26:38 UTC, Adam Wilson wrote:
 On 10/25/18 1:53 AM, Willow wrote:
 
And that is exactly what non-native toolkits provide, you can either use the packaged themes that match the DE or you roll your own. Custom styling a native widget toolkit is possible but significantly more involved.
I mean people should be able to choose immediate mode GUI.
 Will all the rendering be on the GPU? My experience is that in 
 a lot of cases 2D rendering is done on the CPU. Font rendering 
 is generally still done on the CPU afaik.
 
That depends on the API, on Windows you have DirectWrite which renders fonts on the GPU.
Does it actually render the fonts on the GPU or does it render on the CPU and blit them with the GPU?
 Ok, so it's retained mode and GPU rendering. A bunch of people 
 just left the room.
 
 And you seriously think it's 10 lines vs 1000 lines? I'm 
 asking not criticising since I dont really know how retained 
 mode works tbh.
 
I don't think. I know. I get paid to do it. :)
Can you not achieve the same and still have immediate mode graphics? I mean does the technology that saves all the coding actually require the gui be retained mode?
Oct 26 2018
prev sibling next sibling parent reply 0xEAB <desisma heidel.beer> writes:
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...
Oct 24 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
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;
Oct 24 2018
parent "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 10/24/18 7:33 PM, Adam Wilson wrote:
 
 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.
 
That's all still UI. UX means "User Experience". Ie, quite literally, the experience from the user's perspective. It's an abstract concept. The concrete details of the UX are what we call UI.
Oct 24 2018
prev sibling next sibling parent reply Neia Neutuladh <neia ikeran.org> writes:
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
Oct 24 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
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;
Oct 24 2018
parent reply Neia Neutuladh <neia ikeran.org> writes:
On Wed, 24 Oct 2018 16:55:05 -0700, Adam Wilson wrote:
 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.
It would be great if the toolkit made it simple to meet those guidelines. Maybe you're using a framework built on top of HTML+CSS and it helps out. Maybe you're using GTK+ and it does a fair bit for you. Maybe you're using WinForms and it falls far short, forcing you to write a lot of code.
 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.
Consistency between platforms makes it a little easier to write documentation. Users get annoyed by applications that don't work like other applications on their platform.
 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.
Right, but if I'm choosing what tools to use, I'm going to prefer to use good ones instead of garbage ones.
 GTK works where you can accept the limitations that system comes with.
That's suggestive of abnormal limitations, but since you haven't used GTK+, you presumably haven't encountered them.
 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.
There's an obvious solution there...
Oct 24 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/24/18 5:22 PM, Neia Neutuladh wrote:
 On Wed, 24 Oct 2018 16:55:05 -0700, Adam Wilson wrote:
 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.
It would be great if the toolkit made it simple to meet those guidelines. Maybe you're using a framework built on top of HTML+CSS and it helps out. Maybe you're using GTK+ and it does a fair bit for you. Maybe you're using WinForms and it falls far short, forcing you to write a lot of code.
 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.
Consistency between platforms makes it a little easier to write documentation. Users get annoyed by applications that don't work like other applications on their platform.
I've see this assertion made many times usually by developers who've never worked on a UX for non-technical people and always without any corroborating evidence. The following is my credentials in the UX space. I took a UX design class from Billy Hollis, a well known (in the Microsoft space) UX designer. And I've study the psychology of UX design ever since then by reading a number of books on the subject. I've also designed a UX for use by non-technical people that is still in use today. One thing I can say with confidence is that the average user wants each app to behave consistently regardless of where they using them. The human mind is an excellent pattern matching system. It turns out that as long as certain affordances (UX designer speak for something that signals deeper, possibly hidden, meaning) follow the same conventions, how they look (theme) on a given platform is irrelevant. An example of an affordance is a blinking cursor, which signals that you can type here. Or a drop-shadow on a button. Or a menu across the top, or the ubiquitous "hamburger icon" in mobile apps. As long as these affordances function the way their look suggests they do (by convention) then the specifics of how they are colored or drawn (themes, drop-shadows, etc) is functionally irrelevant to the human brain. This is because the brain creates mental "shortcuts" that map to these affordances and once the brain has perceived the affordance, it stops processing the particulars of how it is drawn. (The exception to this rule is those who have more aggressive forms of Autism Spectrum Disorder. The reason is that those individuals have difficulty, or are even incapable of not processing. They see *everything*. The trouble here is that apps that an ASD person can use are nearly unusable to non-ASD people who are relying on the affordance shortcuts. So we don't do that.) However, if I design an app that looks the same and functions the same across platforms (mobile, web, desktop) then the brain develops shortcuts for things like button color, menu ordering, etc. But the most important shortcut the brain can take is that of learning. For example, my American Express app is just a limited version of the website. I can't do everything the website can but what I can do works the same way on both, same affordances, same scheme, same layouts (within reason). I only have to learn the UX once. In the UX class I took one of the first lessons was the order in how the the human brain perceives the elements an image. Colors Shapes Text The first thing that registers in our brains is color. So for example, if we did an American Express app using the native widgets with default colors. Samsung's Android would be white-on-black, but Googles Pixel would be black-on-white. Now our brains have work harder to recognize the app we are using because the colors changed. So then we start looking at the shape on the screen, but those too have changed, Samsung uses different sized buttons for example, so the layout got pushed around. And they use different default fonts, so now the font shapes are different. So our brain slows down even more and starts processing the text on the screen and then we start to slide into our routines. Each one of these increases the total cognitive load, and even if you switch between platforms many times a day, such that you get used to it, your brain still has to do this "context switch". It is simply unavoidable. You might get faster at it the more you do it, but the cognitive load is *always* higher. The cool psychology part of this is that this increased cognitive loading produces an increase in stress level (cortisol). (So do square corners) Again the exception is folks on the Autism Spectrum, they never stop processing, so that don't really benefit from the shortcuts. And I'd even agree that having an environment consistent UX for ASD folks would be better than a task specific UX. Based on my understanding of how ASD people process information. And that is why UX teams are developling apps that look the same across devices, it literally de-stresses their users, which is a good thing if you're trying to sell something. Corporations do things that benefit their bottom-lines sure, but that's doesn't mean that those things are inherently at odds with what users want. A corporation can only make money from happy people. So they tend to do what makes the largest number of people happy.
 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.
Right, but if I'm choosing what tools to use, I'm going to prefer to use good ones instead of garbage ones.
"Good" is often a matter of preference. I don't like WinForms, GTK, or HTML, but I do like WPF. Does that bias me, I'm sure it does, but it doesn't change the direction that the industry at large is headed.
 GTK works where you can accept the limitations that system comes with.
That's suggestive of abnormal limitations, but since you haven't used GTK+, you presumably haven't encountered them.
I'll admit that I haven't used GTK, but I've used apps that use it, and the thing is, what I consider a limitation you might not. Since that's subjective it's probably best that we table further discussion on it since it comes down a matter preference.
 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.
There's an obvious solution there...
... if I'm thinking what you're thinking, that is a pipe dream. I use GNOME too but sometimes we just have to accept that even if we're technically correct, it doesn't matter. :D -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 24 2018
next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On 10/24/18 6:39 PM, Adam Wilson wrote:

 human mind is an excellent pattern matching system. It turns out that as 
 long as certain affordances (UX designer speak for something that 
 signals deeper, possibly hidden, meaning) follow the same conventions, 
 how they look (theme) on a given platform is irrelevant.
Meant to say that whether or not they match the given platforms theme is irrelevant. -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 24 2018
prev sibling next sibling parent Neia Neutuladh <neia ikeran.org> writes:
On Wed, 24 Oct 2018 18:39:20 -0700, Adam Wilson wrote:
 (The exception to this rule is those who have more aggressive forms of
 Autism Spectrum Disorder. The reason is that those individuals have
 difficulty, or are even incapable of not processing. They see
 *everything*. The trouble here is that apps that an ASD person can use
 are nearly unusable to non-ASD people who are relying on the affordance
 shortcuts. So we don't do that.)
Oh. Well, there's my problem. (My case isn't particularly aggressive and I've made full accommodations, but it still affects me.)
Oct 24 2018
prev sibling next sibling parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 10/24/18 9:39 PM, Adam Wilson wrote:
 
 The following is my credentials in the UX space. I took a UX design 
 class from Billy Hollis, a well known (in the Microsoft space) UX 
 designer.
Well there's your problem. It's been a long time since MS was known for UIs that *aren't* a complete clusterf*ck, so it's difficult to assume anything they're relying on is necessarily reputable. Besides, "I took a class" hardly counts as credentials.
Oct 24 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/24/18 7:44 PM, Nick Sabalausky (Abscissa) wrote:
 On 10/24/18 9:39 PM, Adam Wilson wrote:
 The following is my credentials in the UX space. I took a UX design 
 class from Billy Hollis, a well known (in the Microsoft space) UX 
 designer.
Well there's your problem. It's been a long time since MS was known for UIs that *aren't* a complete clusterf*ck, so it's difficult to assume anything they're relying on is necessarily reputable. Besides, "I took a class" hardly counts as credentials.
He doesn't work for MSFT, he just works with their tools because they offer the best (by his standards) ecosystem that isn't HTML. Ok, what you got? I took a class is much better than "I don't like what you said so you're wrong." -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 25 2018
parent reply "Nick Sabalausky (Abscissa)" <SeeWebsiteToContactMe semitwist.com> writes:
On 10/25/18 4:04 AM, Adam Wilson wrote:
 On 10/24/18 7:44 PM, Nick Sabalausky (Abscissa) wrote:
 On 10/24/18 9:39 PM, Adam Wilson wrote:
 The following is my credentials in the UX space. I took a UX design 
 class from Billy Hollis, a well known (in the Microsoft space) UX 
 designer.
Well there's your problem. It's been a long time since MS was known for UIs that *aren't* a complete clusterf*ck, so it's difficult to assume anything they're relying on is necessarily reputable. Besides, "I took a class" hardly counts as credentials.
He doesn't work for MSFT, he just works with their tools because they offer the best (by his standards) ecosystem that isn't HTML.
I wasn't implying he did. You implied that he's well-appreciated in MS circles. I'm saying that doesn't necessarily mean a whole heck of a lot.
 Ok, what you got? I took a class is much better than "I don't like what 
 you said so you're wrong."
"I took a class" isn't anything at all. It's negligable, near-zero. Both of us have real-world experience that absolutely dwarfs "I took a class". And, no, I'm *not* saying "You're wrong *because* the credentials are meaningless." I'm saying "You're wrong, *and* meaningless credentials are meaningless."
Oct 27 2018
parent Adam Wilson <flyboynw gmail.com> writes:
On 10/27/18 6:06 PM, Nick Sabalausky (Abscissa) wrote:
 On 10/25/18 4:04 AM, Adam Wilson wrote:
 On 10/24/18 7:44 PM, Nick Sabalausky (Abscissa) wrote:
 On 10/24/18 9:39 PM, Adam Wilson wrote:
 The following is my credentials in the UX space. I took a UX design 
 class from Billy Hollis, a well known (in the Microsoft space) UX 
 designer.
Well there's your problem. It's been a long time since MS was known for UIs that *aren't* a complete clusterf*ck, so it's difficult to assume anything they're relying on is necessarily reputable. Besides, "I took a class" hardly counts as credentials.
He doesn't work for MSFT, he just works with their tools because they offer the best (by his standards) ecosystem that isn't HTML.
I wasn't implying he did. You implied that he's well-appreciated in MS circles. I'm saying that doesn't necessarily mean a whole heck of a lot.
 Ok, what you got? I took a class is much better than "I don't like 
 what you said so you're wrong."
"I took a class" isn't anything at all. It's negligable, near-zero. Both of us have real-world experience that absolutely dwarfs "I took a class". And, no, I'm *not* saying "You're wrong *because* the credentials are meaningless." I'm saying "You're wrong, *and* meaningless credentials are meaningless."
I'll admit it's not a great argument. As I mentioned elsewhere in the thread I've been paid to do UI design for years. And classes do count as formal training. My only purpose was to establish that I have some idea of what we're talking about here. You haven't offered anything beyond "your wrong". That's great, but it's also just an opinion. Tell me how I am wrong. So far the sum total has been "MSFT makes crap UI's so anybody associated with MSFT UI's is automatically bad at UI." I have nothing further to say until you offer up some constructive criticism. -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 27 2018
prev sibling next sibling parent reply dayllenger <dayllenger protonmail.com> writes:
On Thursday, 25 October 2018 at 01:39:20 UTC, Adam Wilson wrote:

 However, if I design an app that looks the same and functions 
 the same across platforms (mobile, web, desktop) then the brain 
 develops shortcuts for things like button color, menu ordering, 
 etc.
What if someone makes an application only for one platform, or only for desktop or mobile? Or someone needs to quickly create a simple utility and assumes that there is a good default theme - native, which looks and behaves similarly as in that whole platform, utilizing "mental shortcuts" of that environment.
Oct 24 2018
parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/24/18 7:45 PM, dayllenger wrote:
 On Thursday, 25 October 2018 at 01:39:20 UTC, Adam Wilson wrote:
 
 However, if I design an app that looks the same and functions the same 
 across platforms (mobile, web, desktop) then the brain develops 
 shortcuts for things like button color, menu ordering, etc.
What if someone makes an application only for one platform, or only for desktop or mobile? Or someone needs to quickly create a simple utility and assumes that there is a good default theme - native, which looks and behaves similarly as in that whole platform, utilizing "mental shortcuts" of that environment.
Then it is almost entirely up to what you are quickest with. Personally I can knock together a UI in WPF about 3x faster than I can in WinForms. If you know that you are only going to be supporting one platform (as is often the case for internal biz apps) go ahead and use whatever allows you to get it out quickly, because you aren't trying to cater to the masses. More generally, I think there is this stubborn misconception out there that just because the toolkit is non-native that it is unable and unwilling to display the system theme. This could not be further from the truth. By default WPF display whichever theme that you happen to be using, even custom ones (it hooks the System color palette). So to use the native theme in WPF you have to do ... nothing. It's only when you want to use a custom theme that you need to do styling work. In the case of UX/UI toolkits, I would strongly argue that the more the toolkit can do, the more people can use it, the more adoption it will see. Every time you remove functionality, you remove people who can use it. This is why I think that native toolkits are in the process relegated to in-house tools and maintenance of pre-non-native toolkit apps. You can never expand your market-share by focusing on a shrinking market. And there are two ways a market segment can shrink (absolute). It can get smaller itself (absolute), or it can just not grow while the overall market expands (relative). I think native toolkits are shrinking relative to the overall market. But either way, never chase the shrinking market. Especially when the tool that supports the growing market is a superset of the shrinking tool. There is absolutely no reason that a D based non-native toolkit could not be used to mimic the native theme at a pixel level. WPF does it, so we *know* it can be done. Easy, no. Possible, absolutely. :) -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 25 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/10/2018 9:06 PM, Adam Wilson wrote:
 There is absolutely no reason that a D based non-native toolkit could 
 not be used to mimic the native theme at a pixel level. WPF does it, so 
 we *know* it can be done. Easy, no. Possible, absolutely. :)
We can do better than just the visual attributes. Hook in the accessibility API's of the platform and we'd be significantly better off than libraries like nuklear or imgui. But first, we have to decide to actually engineer a solution and not just hack one together like dlangui.
Oct 25 2018
next sibling parent Adam Wilson <flyboynw gmail.com> writes:
On 10/25/18 1:13 AM, rikki cattermole wrote:
 On 25/10/2018 9:06 PM, Adam Wilson wrote:
 There is absolutely no reason that a D based non-native toolkit could 
 not be used to mimic the native theme at a pixel level. WPF does it, 
 so we *know* it can be done. Easy, no. Possible, absolutely. :)
We can do better than just the visual attributes. Hook in the accessibility API's of the platform and we'd be significantly better off than libraries like nuklear or imgui. But first, we have to decide to actually engineer a solution and not just hack one together like dlangui.
Absolute 100% agreement. A project of this scope needs more than a caffeine fueled hacker (no disrespect to caffeine fueled hackers). -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 25 2018
prev sibling parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 25 October 2018 at 08:13:38 UTC, rikki cattermole 
wrote:
 On 25/10/2018 9:06 PM, Adam Wilson wrote:
 There is absolutely no reason that a D based non-native 
 toolkit could not be used to mimic the native theme at a pixel 
 level. WPF does it, so we *know* it can be done. Easy, no. 
 Possible, absolutely. :)
We can do better than just the visual attributes. Hook in the accessibility API's of the platform and we'd be significantly better off than libraries like nuklear or imgui. But first, we have to decide to actually engineer a solution and not just hack one together like dlangui.
People needs to work together, forget their little person, make concessions. "Cool kids" have begun to build desktop apps using web technologies, that's imo impossible to accept. We need to stop being some stupid / classic asocial system programmers. I'm part of the many who tried to build his own little GUI framework and finally gave up because a GUI framework requires many knowledge in many domain (i.e you want to to work on a GUI but you have to loose your time on learning how clipboard works on X...). It's time to move on. When you'll have finished the core (windowing, message loop) it will be time to build something serious on top. I think that something like the Lazarus widgetset system may work. People just need to start working together. Talents are here but fragmented.
Oct 25 2018
next sibling parent reply Adam Wilson <flyboynw gmail.com> writes:
On 10/25/18 2:14 AM, Basile B. wrote:
 On Thursday, 25 October 2018 at 08:13:38 UTC, rikki cattermole wrote:
 On 25/10/2018 9:06 PM, Adam Wilson wrote:
 There is absolutely no reason that a D based non-native toolkit could 
 not be used to mimic the native theme at a pixel level. WPF does it, 
 so we *know* it can be done. Easy, no. Possible, absolutely. :)
We can do better than just the visual attributes. Hook in the accessibility API's of the platform and we'd be significantly better off than libraries like nuklear or imgui. But first, we have to decide to actually engineer a solution and not just hack one together like dlangui.
People needs to work together, forget their little person, make concessions. "Cool kids" have begun to build desktop apps using web technologies, that's imo impossible to accept. We need to stop being some stupid / classic asocial system programmers. I'm part of the many who tried to build his own little GUI framework and finally gave up because a GUI framework requires many knowledge in many domain (i.e you want to to work on a GUI but you have to loose your time on learning how clipboard works on X...). It's time to move on. When you'll have finished the core (windowing, message loop) it will be time to build something serious on top. I think that something like the Lazarus widgetset system may work. People just need to start working together. Talents are here but fragmented.
+1 -- Adam Wilson IRC: EllipticBit import quiet.dlang.dev;
Oct 25 2018
parent reply drug <drug2004 bk.ru> writes:
25.10.2018 12:45, Adam Wilson пишет:
 I'm part of the many who tried to build his own little GUI framework 
 and finally gave up because a GUI framework requires many knowledge in 
 many domain (i.e you want to to work on a GUI but you have to loose 
 your time on learning how clipboard works on X...). It's time to move 
 on. When you'll have finished the core (windowing, message loop) it 
 will be time to build something serious on top. I think that something 
 like the Lazarus widgetset system may work.

 People just need to start working together. Talents are here but 
 fragmented.
+1
I'm agree too. I see a few people here who thinks like you. So probably all we need is just to start collaborating? For example create some working group here or there?
Oct 25 2018
parent reply Basile B. <b2.temp gmx.com> writes:
On Thursday, 25 October 2018 at 10:03:27 UTC, drug wrote:
 25.10.2018 12:45, Adam Wilson пишет:
 I'm part of the many who tried to build his own little GUI 
 framework and finally gave up because a GUI framework 
 requires many knowledge in many domain (i.e you want to to 
 work on a GUI but you have to loose your time on learning how 
 clipboard works on X...). It's time to move on. When you'll 
 have finished the core (windowing, message loop) it will be 
 time to build something serious on top. I think that 
 something like the Lazarus widgetset system may work.

 People just need to start working together. Talents are here 
 but fragmented.
+1
I'm agree too. I see a few people here who thinks like you. So probably all we need is just to start collaborating? For example create some working group here or there?
Me and Alphaglosined are often on IRC but maybe mail will be better until something start to live since there are probably many design choices to discuss, IRC is better for small simple issues. A niche news group here would be nice too and it was asked at least two times in the past. We can make a GH organization too even if there's nothing to wok on so far.
Oct 25 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/10/2018 11:10 PM, Basile B. wrote:
 I'm agree too. I see a few people here who thinks like you. So 
 probably all we need is just to start collaborating? For example 
 create some working group here or there?
Me and Alphaglosined are often on IRC but maybe mail will be better until something start to live since there are probably many design choices to discuss, IRC is better for small simple issues. A niche news group here would be nice too and it was asked at least two times in the past. We can make a GH organization too even if there's nothing to wok on so far.
We already have one. Devisualization. I really need somebody to take ownership of the image library as I really just don't have passion for it. Image: https://github.com/Devisualization/image Windowing: https://github.com/Devisualization/spew
Oct 25 2018
parent reply drug <drug2004 bk.ru> writes:
25.10.2018 13:21, rikki cattermole пишет:
 We already have one. Devisualization. I really need somebody to take 
 ownership of the image library as I really just don't have passion for it.
 
Sorry, but Devisualization isn't suitable because it's a one developer product. We need to start from scratch to discuss different variants and first of all establish a way to let different developer collaborate to create complex software.
Oct 25 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/10/2018 11:31 PM, drug wrote:
 25.10.2018 13:21, rikki cattermole пишет:
 We already have one. Devisualization. I really need somebody to take 
 ownership of the image library as I really just don't have passion for 
 it.
Sorry, but Devisualization isn't suitable because it's a one developer product. We need to start from scratch to discuss different variants and first of all establish a way to let different developer collaborate to create complex software.
No. If a better solution exists from which is in my repositories, then present it. There is no wall stopping this from happening except people's willingness to take ownership of problems.
Oct 25 2018
parent reply drug <drug2004 bk.ru> writes:
25.10.2018 13:34, rikki cattermole пишет:
 No. If a better solution exists from which is in my repositories, then 
 present it. There is no wall stopping this from happening except 
 people's willingness to take ownership of problems.
 
That the first example of importance of Basile phrase: "People just need to start working together". There is no need to force people do what you want. There is a need to start working together.
Oct 25 2018
next sibling parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 25/10/2018 11:40 PM, drug wrote:
 25.10.2018 13:34, rikki cattermole пишет:
 No. If a better solution exists from which is in my repositories, then 
 present it. There is no wall stopping this from happening except 
 people's willingness to take ownership of problems.
That the first example of importance of Basile phrase: "People just need to start working together". There is no need to force people do what you want. There is a need to start working together.
Exactly. I was offering full reign over those repositories to anybody who actually desired to work on it. If that meant deleting code and starting from scratch, then so be it. Even if my wording didn't quite make that clear enough, that was my intention.
Oct 25 2018
parent drug <drug2004 bk.ru> writes:
25.10.2018 13:53, rikki cattermole пишет:
 I was offering full reign over those repositories to anybody who 
 actually desired to work on it. If that meant deleting code and starting 
 from scratch, then so be it. Even if my wording didn't quite make that 
 clear enough, that was my intention.
Well, I do not want to continue specific work of other developer. Just because I have my own to complete. But I'd like to discuss with others how can we developing independent packages create consistent system to build gui and other graphics. And you just force others to take your point of view how it should be done. Of course I can't say for others but in my case it doesn't work.
Oct 25 2018
prev sibling parent Basile B. <b2.temp gmx.com> writes:
On Thursday, 25 October 2018 at 10:40:11 UTC, drug wrote:
 25.10.2018 13:34, rikki cattermole пишет:
 No. If a better solution exists from which is in my 
 repositories, then present it. There is no wall stopping this 
 from happening except people's willingness to take ownership 
 of problems.
 
That the first example of importance of Basile phrase: "People just need to start working together". There is no need to force people do what you want. There is a need to start working together.
I agree to start on Alphaglosined org for SPEW and his other stuff. Repos are easily movable on GH. Unless there's a necessity to start windowing from scratch **again**. Also we need the color module that was a PR for phobos.
Oct 25 2018
prev sibling parent reply drug <drug2004 bk.ru> writes:
25.10.2018 13:10, Basile B. пишет:
 
 Me and Alphaglosined are often on IRC but maybe mail will be better 
 until something start to live since there are probably many design 
 choices to discuss, IRC is better for small simple issues. A niche news 
 group here would be nice too and it was asked at least two times in the 
 past.
 
 We can make a GH organization too even if there's nothing to wok on so far.
Probably the first thing to do is to find optimal place to share our thoughts. because there are so many way like irc, gh, discord, mail etc... For me gh seems to be optimal because almost all of D developers use it.
Oct 25 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 25/10/2018 11:26 PM, drug wrote:
 25.10.2018 13:10, Basile B. пишет:
 Me and Alphaglosined are often on IRC but maybe mail will be better 
 until something start to live since there are probably many design 
 choices to discuss, IRC is better for small simple issues. A niche 
 news group here would be nice too and it was asked at least two times 
 in the past.

 We can make a GH organization too even if there's nothing to wok on so 
 far.
Probably the first thing to do is to find optimal place to share our thoughts. because there are so many way like irc, gh, discord, mail etc... For me gh seems to be optimal because almost all of D developers use it.
https://github.com/Devisualization/workgroup Done.
Oct 25 2018
prev sibling parent reply Guillaume Piolat <contact spam.org> writes:
On Thursday, 25 October 2018 at 09:14:08 UTC, Basile B. wrote:
 On Thursday, 25 October 2018 at 08:13:38 UTC, rikki cattermole 
 wrote:
 On 25/10/2018 9:06 PM, Adam Wilson wrote:
 There is absolutely no reason that a D based non-native 
 toolkit could not be used to mimic the native theme at a 
 pixel level. WPF does it, so we *know* it can be done. Easy, 
 no. Possible, absolutely. :)
We can do better than just the visual attributes. Hook in the accessibility API's of the platform and we'd be significantly better off than libraries like nuklear or imgui. But first, we have to decide to actually engineer a solution and not just hack one together like dlangui.
People needs to work together, forget their little person, make concessions. "Cool kids" have begun to build desktop apps using web technologies, that's imo impossible to accept. We need to stop being some stupid / classic asocial system programmers. I'm part of the many who tried to build his own little GUI framework and finally gave up because a GUI framework requires many knowledge in many domain (i.e you want to to work on a GUI but you have to loose your time on learning how clipboard works on X...). It's time to move on. When you'll have finished the core (windowing, message loop) it will be time to build something serious on top. I think that something like the Lazarus widgetset system may work. People just need to start working together. Talents are here but fragmented.
I also have homemade UI widgets and windowing and now need a CSS equivalent! This story is familiar it sounds. I don't think it will be easy to serve many use cases but it's probably worth it to try. I'll gladly participate in such a work-group (wherever it is on Github) and can provide some native Cocoa backend help (amongst other), preferably if led with a top-down vision by Adam Wilson (yup). I think enough people around here can deal with the bottom-up aspects of such an endeavour. Btw I agree with the assessment that CSS+HTML is where it's at currently. It's not that it's best but browsers are about the only thing that can display multi-lingual text correctly.
Oct 25 2018
parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 25 October 2018 at 11:23:27 UTC, Guillaume Piolat 
wrote:
 Btw I agree with the assessment that CSS+HTML is where it's at 
 currently. It's not that it's best but browsers are about the 
 only thing that can display multi-lingual text correctly.
Why would you say that bo toolkits (HTML is no toolkit!) can render multilingual text? Some of them most definitely can. If programs fail to support it, it is mostly because some of the required international work cannot be abstracted away and has to be performed in a domain-specific way by the application developer. And that is hard. And I have to put my foot down hard and tell you that HTML for desktop UIs is just inadequate and wrong. D as a language is strongest when performance matters. That includes applications that need very involved GPU accelerated rendering and visualizations. Webkit or Blink would imply that WebGL is required for rendering. And that is a toy API compared to what is available in DirectX, OpenGL or Vulkan and comes with severe limitations.
Oct 25 2018
prev sibling parent reply Joakim <dlang joakim.fea.st> writes:
On Thursday, 25 October 2018 at 08:06:32 UTC, Adam Wilson wrote:
 You can never expand your market-share by focusing on a 
 shrinking market. And there are two ways a market segment can 
 shrink (absolute). It can get smaller itself (absolute), or it 
 can just not grow while the overall market expands (relative). 
 I think native toolkits are shrinking relative to the overall 
 market. But either way, never chase the shrinking market. 
 Especially when the tool that supports the growing market is a 
 superset of the shrinking tool.
When reading this thread, I was going to make the same point about shrinking markets, except towards the opposite aim that the GUI toolkit market itself is not worth pursuing. The software market that is actually growing worldwide is one stripped of chrome, where you simply build a software service on an existing text or voice-based platform, like WeChat in China or Alexa/Google-Assistant in the west: https://qz.com/1331650/an-app-built-just-for-wechat-hints-at-googles-new-china-plan/ Attempts have been made to replicate WeChat's success in other countries, such as with the Google Assistant, Allo, or Siri, but obviously it hasn't taken off in the US... yet: https://www.wired.com/2015/08/time-to-ditch-texting/ Everybody believes that is just a matter of time though, and with speakers and other home-based connected hardware taking off, the importance of voice-driven software interaction is only increasing. That's why people are now writing strategic analyses of how the big players are doing in this fast-growing and important market: https://stratechery.com/2018/the-battle-for-the-home/ Building your own GUI toolkit is very much an '80s or '90s mindset, back when that was paramount. It isn't anymore, and would be a waste of time to try with D. Of course, there's always going to be a small and lucrative niche of people using old-fashioned apps written with a GUI toolkit, just as there's still people running COBOL, so if you really want to build for that shrinking market, go for it. But I think it would be a mistake for the D community to spend too much of its meager resources on that backward-looking market.
Oct 28 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 28/10/2018 8:03 PM, Joakim wrote:
 Building your own GUI toolkit is very much an '80s or '90s mindset, back 
 when that was paramount. It isn't anymore, and would be a waste of time 
 to try with D.
WIMP dates back to the 60's in a fully functional state. It isn't going anywhere.
Oct 28 2018
parent reply Joakim <dlang joakim.fea.st> writes:
On Sunday, 28 October 2018 at 07:08:33 UTC, rikki cattermole 
wrote:
 On 28/10/2018 8:03 PM, Joakim wrote:
 Building your own GUI toolkit is very much an '80s or '90s 
 mindset, back when that was paramount. It isn't anymore, and 
 would be a waste of time to try with D.
WIMP dates back to the 60's in a fully functional state. It isn't going anywhere.
Oh, I never said it is: I explicitly said it will always be around like COBOL. When's the last time you wrote any COBOL or interviewed for a COBOL job? Exactly. :)
Oct 28 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 28/10/2018 8:12 PM, Joakim wrote:
 On Sunday, 28 October 2018 at 07:08:33 UTC, rikki cattermole wrote:
 On 28/10/2018 8:03 PM, Joakim wrote:
 Building your own GUI toolkit is very much an '80s or '90s mindset, 
 back when that was paramount. It isn't anymore, and would be a waste 
 of time to try with D.
WIMP dates back to the 60's in a fully functional state. It isn't going anywhere.
Oh, I never said it is: I explicitly said it will always be around like COBOL. When's the last time you wrote any COBOL or interviewed for a COBOL job? Exactly. :)
The last time I worked with COBOL was 4 years ago when I wrote a parser for it. There is still a very large market for COBOL developers: https://www.cobol-it.com/
Oct 28 2018
next sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Sunday, 28 October 2018 at 07:19:11 UTC, rikki cattermole 
wrote:
 
 The last time I worked with COBOL was 4 years ago when I wrote 
 a parser for it.

 There is still a very large market for COBOL developers: 
 https://www.cobol-it.com/
I just had vision of Andrei, waking up after a nightmare, pouring with sweat and his wife says to him 'whats wrong, what's wrong' and he says 'i had a nightmare. D reached 1 million developers' and she says ' I thought that's what you wanted' and he says 'they were all ex-COBOL developers'
Oct 28 2018
parent reply rikki cattermole <rikki cattermole.co.nz> writes:
On 28/10/2018 8:27 PM, Abdulhaq wrote:
 
 I just had vision of Andrei, waking up after a nightmare, pouring with 
 sweat and his wife says to him 'whats wrong, what's wrong' and he says 
 'i had a nightmare. D reached 1 million developers' and she says ' I 
 thought that's what you wanted' and he says 'they were all ex-COBOL 
 developers'
That is certainly chuckle worthy. But at least the foundation would have a lot of money to splash around giving them what they want!
Oct 28 2018
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Sunday, 28 October 2018 at 07:30:54 UTC, rikki cattermole 
wrote:
 On 28/10/2018 8:27 PM, Abdulhaq wrote:
 
 I just had vision of Andrei, waking up after a nightmare, 
 pouring with sweat and his wife says to him 'whats wrong, 
 what's wrong' and he says 'i had a nightmare. D reached 1 
 million developers' and she says ' I thought that's what you 
 wanted' and he says 'they were all ex-COBOL developers'
That is certainly chuckle worthy. But at least the foundation would have a lot of money to splash around giving them what they want!
So was the COBOL parser for profit or pleasure? Was a compiler ever written? What did you write the parser in? I did a COBOL training course in Chicago in 1986 and wrote the programs on a type of grid paper. I guess it's changed a bit since then :-).
Oct 28 2018
parent rikki cattermole <rikki cattermole.co.nz> writes:
On 29/10/2018 9:28 AM, Abdulhaq wrote:
 On Sunday, 28 October 2018 at 07:30:54 UTC, rikki cattermole wrote:
 On 28/10/2018 8:27 PM, Abdulhaq wrote:
 I just had vision of Andrei, waking up after a nightmare, pouring 
 with sweat and his wife says to him 'whats wrong, what's wrong' and 
 he says 'i had a nightmare. D reached 1 million developers' and she 
 says ' I thought that's what you wanted' and he says 'they were all 
 ex-COBOL developers'
That is certainly chuckle worthy. But at least the foundation would have a lot of money to splash around giving them what they want!
So was the COBOL parser for profit or pleasure? Was a compiler ever written? What did you write the parser in? I did a COBOL training course in Chicago in 1986 and  wrote the programs on a type of grid paper. I guess it's changed a bit since then :-).
Both profit and pleasure (never completed it). It meant I didn't have to manually port some code. And yeah its changed a bit, quite a few different specs all quite different in slight ways.
Oct 28 2018
prev sibling parent Joakim <dlang joakim.fea.st> writes:
On Sunday, 28 October 2018 at 07:19:11 UTC, rikki cattermole 
wrote:
 On 28/10/2018 8:12 PM, Joakim wrote:
 On Sunday, 28 October 2018 at 07:08:33 UTC, rikki cattermole 
 wrote:
 On 28/10/2018 8:03 PM, Joakim wrote:
 Building your own GUI toolkit is very much an '80s or '90s 
 mindset, back when that was paramount. It isn't anymore, and 
 would be a waste of time to try with D.
WIMP dates back to the 60's in a fully functional state. It isn't going anywhere.
Oh, I never said it is: I explicitly said it will always be around like COBOL. When's the last time you wrote any COBOL or interviewed for a COBOL job? Exactly. :)
The last time I worked with COBOL was 4 years ago when I wrote a parser for it.
Then you're the exception, as I suspect most programmers are like me and have never even seen it.
 There is still a very large market for COBOL developers: 
 https://www.cobol-it.com/
I agree that it's still a surprisingly large market, as COBOL is still part of key infrastructure, particularly in finance and government: "In the US, around 80 percent of in-person transactions and 95 percent of ATM swipes are based on programs written in COBOL. The problem is there’s not enough people to maintain the current COBOL-based systems. According to Reuters, around three trillion dollars in daily commerce flow through COBOL systems. Many major financial corporations and some parts of the federal government have built their entire infrastructure on COBOL bases from the 70s and 80s." https://thenextweb.com/finance/2017/04/10/ancient-programming-language-cobol-can-make-you-bank-literally/ Similarly, I think WIMP will be around for decades for certain kinds of software, but it will simply be dwarfed by sales of software that's driven by voice, just as mobile device sales now dwarf PC sales: https://twitter.com/lukew/status/842397687420923904 So like Adam said, should D focus on that shrinking GUI market or the growing text/voice mobile market? Obviously the latter deserves much more emphasis. That doesn't stop Adam or anyone who wants to do GUIs or COBOL from going their own way, I'm just cautioning that it wouldn't be a good direction for the D community to pour much resources into, ie the 5 paid developers he references.
Oct 28 2018
prev sibling parent rjframe <dlang ryanjframe.com> writes:
On Wed, 24 Oct 2018 18:39:20 -0700, Adam Wilson wrote:

 On 10/24/18 5:22 PM, Neia Neutuladh wrote:
 Consistency between platforms makes it a little easier to write
 documentation. Users get annoyed by applications that don't work like
 other applications on their platform.
 
I've see this assertion made many times usually by developers who've never worked on a UX for non-technical people and always without any corroborating evidence.
...
 One thing I can say with confidence is that the average user wants each
 app to behave consistently regardless of where they using them. [snip...]
 
...
 
 However, if I design an app that looks the same and functions the same
 across platforms (mobile, web, desktop) then the brain develops
 shortcuts for things like button color, menu ordering, etc.
Yes and no. These design elements are most important for people that use an app on multiple devices - which is often less common that we tend to think (at least for the next 2-3 years). But there are UI adjustments that need to be system-specific. I'm sysadmin/helpdesk; I'm the one that helps people save their email attachments, extract files from a zip archive, explains why they didn't actually save that document because the OK and Cancel buttons are in the wrong order... Whenever people struggle to understand how something works, I ask them to describe what they expect. People tend to have pretty reasonable expectations -- the way people want the software to work often makes more sense than the actual design. I've come to see non-technical people that just want to get some task done as more reliable designers than those of us to can fall into the habit of making the tech itself the important thing. For major elements, like descriptions, menu order, button color, yes, the application on every platform needs to be consistent *if* it's a multi- platform application; otherwise it should definitely follow system guidelines (on macOS, the OK button should be blue). In other areas, design elements need to be adjusted by that platform. Windows places OK on the left, Cancel on the right; macOS is the reverse - and if you're application gets it wrong, your end-user will not be happy with you. --Ryan
Oct 25 2018
prev sibling next sibling parent reply dayllenger <dayllenger protonmail.com> writes:
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.
Oct 24 2018
next sibling parent welkam <wwwelkam gmail.com> writes:
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.
Oct 24 2018
prev sibling parent reply aberba <karabutaworld gmail.com> writes:
On Wednesday, 24 October 2018 at 22:09:24 UTC, dayllenger wrote:
 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
This is exactly what DlangUI should have aimed to be like. Its still chasing after the old GUI path which is an already dying trend. DlangUI is a very impressive achievement and I'm very glad the developer is doing such massive work. However, the direction it's going in terms of layout and theming doesn't meet modern demands. I think CSS/subset of it, is perfect for customization. That's exactly the direction GTK+ is going after years of chasing the layout approach of Qt and other previous Windows toolkits.
 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.
I think layout languages haven't really taken off in most toolkits that have them...relative to the use of the APIs themselves. Its a niche thing IMO. A well designed (clean, consistent, simplistic) API should be enough for most needs. Another thing worth considering is a reactive GUI approach. Most modern toolkits are aiming for reactivity. Its something that can be attached as an opt-in (See RX in D: https://code.dlang.org/packages/rx) or used as a fundamental architecture. It makes so much sense. Overview by looking at drawback of current OOP approach: https://eugenkiss.com/b/overview-of-reactive-gui-programming The concept using a demo approach (must read): https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
Nov 21 2018
parent dayllenger <dayllenger protonmail.com> writes:
On Wednesday, 21 November 2018 at 08:25:03 UTC, aberba wrote:
 Another thing worth considering is a reactive GUI approach. 
 Most modern toolkits are aiming for reactivity. Its something 
 that can be attached as an opt-in (See RX in D: 
 https://code.dlang.org/packages/rx) or used as a fundamental 
 architecture. It makes so much sense.

 Overview by looking at drawback of current OOP approach: 
 https://eugenkiss.com/b/overview-of-reactive-gui-programming

 The concept using a demo approach (must read): 
 https://gist.github.com/staltz/868e7e9bc2a7b8c1f754
Thanks for the links. I thought about reactivity, and there is a lot of stuff to comprehend.
Nov 21 2018
prev sibling next sibling parent reply Abdulhaq <alynch4047 gmail.com> writes:
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.

 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.
I think I can contribute something useful to this too. I've worked with MFC, Visual Basic from 1.0, Paradox, Delphi (1,2,3, I actually paid for this with my own money, and it was worth it), SQLWindows, Oracle*Forms, ActiveX/COM/OLE2, Swing, Qt Widgets (not QML) (C++ and Python), wxWidgets, JavaFX, DHTML/Javascript/CSS, Android UI and probably others I've forgotten.
 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.
Yes, because the web is close to a universally available platform, running everywhere. No one who knows Qt or JavaFX would choose the dogs breakfast of accidental software DHTML/Javascript/CSS/Ajax etc. if Qt or JavaFX was equally universally available/distributable on all platforms.
 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.
What has a companies brand got to do with a widget theme? Anyway, it doesn't matter. BTW JavaFX has excellent CSS based widget/scene graph node themeing.
 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.
Many many years of MS chopping and changing their recommended UI development platform (Silverlight is a great example) have taught me not to build on MS's latest and greatest UI platform - whatever that is this month.
 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.
 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.
Qt works brilliantly from python too, not just C++. It could easily be used from D and other languages too, if there was a binding. How come no one has mentioned Calypso in these two GUI threads? The Qt binding is just about complete with Calypso, as far as I can tell. Russel also suggested creating a binding a la sip/PyQt. I started something based on the same architecture as PyQt in 2014, it's probably crap, but it's not that far off providing something that works. I stopped because Calypso looked so good.
 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.
No, Phil Thompson wrote PyQt on his own. Something similar for D/Qt is not impossible, I have (had) a working core to prove it. Calypso is much better, but frankly, no one seems interested. It's more fun to bikeshed about writing an entire UI toolkit from scratch.
 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.
 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.
If you seriously want a good UI toolkit for D then write a wrapper for Qt. It's very feasible. it would be tremendously useful. Writing something even half as good as Qt? I admire your ambition but there is simply no chance of it happening. None. BTW, an aside, I was very surprised that for a large family of applications, JavaFX is even better than Qt. Just an aside for those who have C++/Python/Java as potential options for their next masterpiece. Abdulhaq
Oct 25 2018
next sibling parent Gregor =?UTF-8?B?TcO8Y2ts?= <gregormueckl gmx.de> writes:
On Thursday, 25 October 2018 at 19:28:44 UTC, Abdulhaq wrote:
 How come no one has mentioned Calypso in these two GUI threads? 
 The Qt binding is just about complete with Calypso, as far as I 
 can tell.
I would have mentioned it if I had known about it. It never showed up in my searches for some reason. I will go and check it out.
Oct 25 2018
prev sibling next sibling parent reply Laurent =?UTF-8?B?VHLDqWd1aWVy?= <laurent.treguier.sink gmail.com> writes:
On Thursday, 25 October 2018 at 19:28:44 UTC, Abdulhaq wrote:
 Qt works brilliantly from python too, not just C++. It could 
 easily be used from D and other languages too, if there was a 
 binding. How come no one has mentioned Calypso in these two GUI 
 threads? The Qt binding is just about complete with Calypso, as 
 far as I can tell.
Calypso is one specific compiler AFAIK. Something like a GUI library shouldn't be tied to using a specific compiler.
Oct 26 2018
parent Abdulhaq <alynch4047 gmail.com> writes:
On Friday, 26 October 2018 at 07:44:03 UTC, Laurent Tréguier 
wrote:
 On Thursday, 25 October 2018 at 19:28:44 UTC, Abdulhaq wrote:
 Qt works brilliantly from python too, not just C++. It could 
 easily be used from D and other languages too, if there was a 
 binding. How come no one has mentioned Calypso in these two 
 GUI threads? The Qt binding is just about complete with 
 Calypso, as far as I can tell.
Calypso is one specific compiler AFAIK. Something like a GUI library shouldn't be tied to using a specific compiler.
Yes, you are right. But if you really want to write a fast, rich GUI application using D, then LDC/LLVM/Calypso is probably the closest you can currently get. I'm very curious if anyone here has actually tried to use it in the last couple of years, and if they were successful or not.
Oct 26 2018
prev sibling parent reply Bastiaan Veelo <Bastiaan Veelo.net> writes:
On Thursday, 25 October 2018 at 19:28:44 UTC, Abdulhaq wrote:
 If you seriously want a good UI toolkit for D then write a 
 wrapper for Qt. It's very feasible. it would be tremendously 
 useful.
If I had time on my hands, I'd investigate to what extent dpp can be applied to access Qt. Whatever the moc does could possibly be accomplished using D meta programming.
 BTW, an aside, I was very surprised that for a large family of 
 applications, JavaFX is even better than Qt.
In what way? (I never used Java).
Oct 26 2018
parent reply Abdulhaq <alynch4047 gmail.com> writes:
On Friday, 26 October 2018 at 11:35:26 UTC, Bastiaan Veelo wrote:
 On Thursday, 25 October 2018 at 19:28:44 UTC, Abdulhaq wrote:
 BTW, an aside, I was very surprised that for a large family of 
 applications, JavaFX is even better than Qt.
In what way? (I never used Java).
What I like about JavaFX is the way that the window is constructed with a scene graph. Each Node in the scene graph can have, as you might expect, a 3D transform applied to it. Nodes can be widgets, meshes etc. A rich implementation of CSS can be applied to each node allowing good visual customisation. Combine that with a pretty decent UI construction tool and you've got a great platform for developing more modern UIs (modern widgets, animations, visual effects etc.). Java itself (JDK8) is a totally different beast from the much hated early versions, and provides a very rich platform (decent language + great libraries and excellent tooling) with excellent build facilities. Hard to believe, I know, but as a development experience it's very good.
Oct 26 2018
parent reply Russel Winder <russel winder.org.uk> writes:
On Fri, 2018-10-26 at 13:13 +0000, Abdulhaq via Digitalmars-d wrote:
=20
[=E2=80=A6]
 Java itself (JDK8) is a totally different beast from the much=20
 hated early versions, and provides a very rich platform (decent=20
 language + great libraries and excellent tooling) with excellent=20
 build facilities. Hard to believe, I know, but as a development=20
 experience it's very good.
OpenJDK11 and OpenJFX JDK8 is long, long ago. :-) --=20 Russel. =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D Dr Russel Winder t: +44 20 7585 2200 41 Buckmaster Road m: +44 7770 465 077 London SW11 1EN, UK w: www.russel.org.uk
Oct 26 2018
parent Abdulhaq <alynch4047 gmail.com> writes:
On Friday, 26 October 2018 at 14:12:06 UTC, Russel Winder wrote:
 On Fri, 2018-10-26 at 13:13 +0000, Abdulhaq via Digitalmars-d 
 wrote:
 
[…]
 Java itself (JDK8) is a totally different beast from the much 
 hated early versions, and provides a very rich platform 
 (decent language + great libraries and excellent tooling) with 
 excellent build facilities. Hard to believe, I know, but as a 
 development experience it's very good.
OpenJDK11 and OpenJFX JDK8 is long, long ago. :-)
Slightly disturbing that this passed me by!
Oct 26 2018
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
On 10/23/2018 11:20 PM, Adam Wilson wrote:
 [...]
I must say, that was a well-written and enjoyable article. Thanks!
Oct 26 2018
prev sibling next sibling parent Jacob Shtokolov <jacob.100205 gmail.com> writes:
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.
Sorry, I didn't read the entire thread (it's kinda big), but I would agree that HTML (and its derivatives) is the most flexible and most popular UI layout concept nowadays. Even GTK (and so GNOME) is going this way using CSS and JavaScript. If you guys are really discussing the possible future GUI toolkit, I have some ideas in regards to this topic. I see a lot of discussions there about OpenGL support, etc. There is a really good project that is possible to use as a basis: EFL toolkit. Currently it is sponsored by Samsung, but it has the MIT license (the core parts: Evas, Ecore, etc.) and is written in the bare C. It's possible to take Evas as a basic stateful canvas to build something HTML-like (or web-like). It supports different rendering backends such as OpenGL, SDL, software rendering (CPU) and is memory and CPU efficient. So there is no need to build it from scratch. Another thing is that web is moving towards component-oriented concepts. The known examples are React.js, Vue.js, Google Flutter, etc. Imagine the UI framework that combines EFL's Edje functionality with component-based concepts from Vue.js (for example). For instance, take a look at this page: https://vuejs.org/v2/guide/single-file-components.html and imagine Dlang instead of JavaScript there (one-file components are not so cool though, but it's possible to separate them into *.html, *.css and *.js). Component-based architecture automatically means that if you don't use the Audio or Video elements (components), they will not be compiled into your application, unlike CEF and other Chromium-based frameworks where the things are already there no matter if you use them. This combination of libraries and concepts will give an advantage to compile and run this code on all popular platforms (of course if LDC project will finally add a stable iOS support). Just a proposal.
Oct 27 2018
prev sibling next sibling parent Thomas Mader <thomas.mader gmail.com> writes:
On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
 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.
We seem to share similar opinions when it comes to UI libs. I need to say that I don't have any experience with WPF but mostly with Qt, SWT and a little GTK and Swing. Conrod [1] is something that goes into that direction and you might be interested in it if you haven't heard about it. I found it because I once was interested if someone is working on a lib in a compiled language featuring reactive programming with a modern Vulkan backend and without any web technologies. [1] http://docs.piston.rs/conrod/conrod/guide/chapter_1/index.html I don't have any practical experience with the reactive pattern as of yet but it seems to be a good thing. Even though we share similar opinions I have some questions. 1) How do you expect to find 5 people who are working for at least 5 years as fully committed full time developers without payment? 2) Let's say the project is successful and offers advantages to other UI libs and the web stack but dlang still hasn't got any major momentum and backing. Many might not consider the UI lib as a good candidate just because of that reason. Why do you think this UI lib might change the perception of dlang?
Oct 27 2018
prev sibling next sibling parent John Carter <john.carter taitradio.com> writes:
On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
 I know that this topic can bring out the rage-trolls
Not a rage troll, just a sad troll. One that remembers a time when graphics and visualization and UI design was fun and easy to do.
 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.
Sadly, true. Standardization was abandoned, killed, stabbed in the back. And now we live in the worst of all worlds. You need to understand a vast pile of standards, and a vast pile of half documented 3rd party libraries on top of the standards... and like hapless princesses in distress, we're left to cry "Help me Stack Overflow, you're my only Hope".
 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.
Ah yes, the pixel pushers. Sadly, they have won.
 *At first I hoped that such a technically unsound project would 
 collapse but I soon realized it was doomed to success. Almost 
 anything in software can be implemented, sold, and even used 
 given enough determination. There is nothing a mere scientist 
 can say that will stand against the flood of a hundred million 
 dollars. But there is one quality that cannot be purchased in 
 this way - and that is reliability. The price of reliability is 
 the pursuit of the utmost simplicity. It is a price which the 
 very rich find most hard to pay.*
 Tony Hoare
 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.
D3.js has this property too.... but I despair of it. If you peek under the hood of D3 or WPF to try and understand why something isn't working the way you thought it should..... "Help me please Stack Overflow, you're my only Hope".
 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.
Once there was a vision, a brilliant vision, semantic markup to describe the parts of a document, style sheets to guide the presentation, and rendering engine to make it look "fairly" good on any display, any aspect ratio, any display any user choice of font and fontsize. And then the "Optimized for 800x600, must be pixel perfect always!" crowd came along. And WORA cease to mean WORA. It mean must do exactly the same pixel perfect things everywhere. Ah! I remember the glory days of The Zen Garden of CSS.... anything could be achieved by styling. Except they lied, under the hood it was all <div>'s and images.
 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.
And there the brilliant vision is lost. Instead of semantic markup and styling hints, rendered "Good Enough" everywhere, the demand for pixel perfect rendition, pixel identical everywhere and the users preferences be damned.
 Native toolkits are a dead-end. The future of non-Web UX is 
 non-native.
As I say, I'm not a rage troll. I am a sad troll. I am sad and miss the good old days when tossing off a visualization was ten minutes work, simple and fun, and I could peek under the hood all the way down to the machine code and understand what was going on. And fix it.
 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.
The saddest day of my programming life was when Windows 3 came out and I found out how much cruft I had to write to say "Hello World" These days I keep as far away from UX gargantua as I can.... because touching it will swallow months of economic effort for very very little useful return.
 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.
Or consciously relinquish the pursuit of pixel perfection and "the theme itself is now part of a brand" and aim for semantic simplicity. And make programming fun and useful again.
 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.
Good luck Sir Knight, that windmill you are charging is vast and unforgiving.
Oct 28 2018
prev sibling next sibling parent aberba <karabutaworld gmail.com> writes:
On Wednesday, 24 October 2018 at 06:20:05 UTC, 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.

 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 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 believe most people in this community are not designers primarily so this might not seem like a "very worth it" goal to reach. But its clearly obvious to me...cus I've been doing web development and used GTK+ and some native GUI tookits for development...I use Linux a s my primary desktop. I also fairly know about how Android's UI works. Its clear that all new and most used GUI tookits are those that allow customization and abstract low-level details across platforms. Native tookit works really well when targeting a single platform which D already has a couple.
 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 couldn't agree more. When you look at apps in Play Store or Apple's app store (Mac & iOS), you'll see the most popular apps are those designed and themed to look nice CROSS PLATFORM (for them most part). The thing with native toolkits is each platform is designed to look and work differently...you find yourself implementing hacks...lots of work...and what happens when OS vendor stop developing it like Window's often does for the new thing.
 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.
That doesn't really matter much IMO. Most of these toolkits have such layout languages but they are not often used much beyound some niches...but its worth it though. The most important part is a well designed and simplistic APIs...and something like being able to customize UI elements/nodes with something like a subset of CSS...which GTK+ does really well. See elementary OS (elementary.io) for how beautiful GTK+ can be themed/customized. Anther is Using SVG for icons and graphics by DEFAULT to simplify things...like scaling. It's about time we settle down and talk about a solid, written in D GUI toolkit that is modern. Something that will compel mass adoption of D to build native apps...where it makes sense. At least, native apps are still relevant today...even for those of us doing more web apps.
Nov 20 2018
prev sibling next sibling parent Daniel <daniel daniel.daniel> writes:
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.
FYI, Microsoft just announced the open sourcing of WinForms, WPF and WinUI: https://blogs.windows.com/buildingapps/2018/12/04/announcing-open-source-of-wpf-windows-forms-and-winui-at-microsoft-connect-2018/ Daniel
Dec 05 2018
prev sibling parent Guillaume Piolat <first.last gmail.com> writes:
On Wednesday, 24 October 2018 at 06:20:05 UTC, Adam Wilson wrote:
 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.
UP Some of us are unhappy with the situation and created a Working Group towards that more or less same goals https://github.com/DlangGraphicsWG Anyone can make proposals and vote there. Disagreement is exposed (reified) and process, requirements, and vision are 100% modifyable ; if you get the favour of the voting process. It will still take a whole pile of effort (at least 3 man years at the very least), but it seems all the scraps and pieces are there in some D code form already, and getting to agree on things is imho the limiting factor. It turns out it's a controversial and intricated domain. The workgroup is composed of mainly "bottom-up" library writers people and it will be great to have more "top-down" people with an UX vision - this vision will have to be sold to others.
Dec 18 2018