October 26, 2018
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?




October 26, 2018
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).

October 26, 2018
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.

October 26, 2018
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. :-)

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



October 26, 2018
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!
October 27, 2018
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.
October 27, 2018
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?

October 27, 2018
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."
October 27, 2018
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;
October 27, 2018
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;