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;

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;

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.

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.

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;

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.

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.

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;

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;

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?