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