www.digitalmars.com         C & C++   DMDScript  

digitalmars.D.learn - wanting to try a GUI toolkit: needing some advice on which one to

reply someone <someone somewhere.com> writes:
Yes, I know this is a question lacking a straightforward answer.

Requirements:

- desktop only: forget about support for mobile tablets whatever

- wide cross-platform support not needed at all: linux and/or 
some BSD distro like FreeBSD/DragonFlyBSD and that's all; don't 
care at all for the Windows platform.

- Wayland support will be a plus.

- HiDPI support will be a plus.

What I like/dislike:

- like a simple classical UI: favored over any modern one:

   - eg: my daily-driver workstation is running the MATE desktop 
configured as unobtrusive and minimal as possible and I am quite 
happy with it; needless to say I hate modern gnome and KDE 
desktops not to mention unity and family.

   - eg: hate the dconf-editor controls styles (GTK).

   - eg: like ClawsMail [https://www.claws-mail.org/] classic 
style.

   - eg: currently using the xfe file manager 
[http://roland65.free.fr/xfe/] (which follows the early Windows 
File Explorer design) which is written in C++ and is built 
against the minimal Fox GUI toolkit [http://fox-toolkit.org/].

- like fast native compiled fast responsive minimal apps; say, 
what used to be the common way back on the 90s; eg: Windows forms 
over COM ... fast instantly-opening windows (providing the 
program itself do not make them lag of course).

- dislike the way modern toolkits like gnome/KDE rely on CSS to 
render the controls making the toolkits heavy on resources; 
prefer more traditional ones, but this is not a requirement, it 
is my preference.

What I know so far:

- I assume using the FOX library will be more or less a 
straighforward process since it is written in C++; ie: no 
bindings needed at all ... am I correct ?

- using the GTK toolkit within D requires the GTKD binding 
library.

Any comments are welcomed, even any comments regarding anyone 
experience with GUI development within D, no matter whether the 
answer would be relevant to my specific question seeking a choice 
or not.
May 26 2021
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:

 - like a simple classical UI: favored over any modern one:


My minigui is a thing of beauty. Behold:

http://arsdnet.net/minigui-linux.png
http://arsdnet.net/minigui-sprite.png

its docs:
http://dpldocs.info/experimental-docs/arsd.minigui.html

It is quick to open and quick to compile (the whole thing is 
contained in just three source file that build from scratch in 
about a quarter second).

Pity is sucks. More below.


 - using the GTK toolkit within D requires the GTKD binding 
 library.


Well, you don't strictly have to use gtkd, you can always just 
extern(C) define the stuff yourself (or only use them from gtkd's 
generated files) and call them. But if you do use gtk, I'd 
suggest just sticking to the gtkd wrapper.

But I hate gtk so I made my own thing from scratch on nothing but 
X which might amuse you. (I loathe that useless wayland trash and 
will never support it. X is so much better.)

However my text edit widget sucks. It barely works. Really slow 
and buggy. I've been slowly trying to find the time to rewrite it 
but wow the text edit is harder than literally everything else 
combined and since I have so many other things to do it still 
sucks. I have been doing a bit of a 2.0 rewrite lately (recent 
blogs: 
http://dpldocs.info/this-week-in-d/Blog.Posted_2021_05_03.html 
and 
http://dpldocs.info/this-week-in-d/Blog.Posted_2021_05_17.html 
describe it, though the doc link from before has info too)

So I probably wouldn't seriously recommend my thing right now on 
Linux. (On Windows, it is fine - it just uses the OS-provided 
control. But you don't care about Windows so that's irrelevant... 
unless you wanna wine.)


Ironically the biggest thing I changed in the recent 2.0 work is 
a style delegate that makes it possible to do some kind of css 
thing. But since I also think css is bloated I'm just putting 
hooks in the core so it is an optional feature, just like the xml 
and script stuff. Turns out that was easier than fixing text 
bugs. And besides people love their dark modes lol.


Anyway if you can stand gtk, gtkd really isn't bad and its text 
widget works. Just don't use the file dialog lololol.
May 26 2021
next sibling parent reply someone <someone somewhere.com> writes:
On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote:

 Well, you don't strictly have to use gtkd, you can always just 
 extern(C) define the stuff yourself (or only use them from 
 gtkd's generated files) and call them. But if you do use gtk, 
 I'd suggest just sticking to the gtkd wrapper.


Crystal clear.

On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote:

 But I hate gtk so I made my own thing from scratch on nothing 
 but X which might amuse you. (I loathe that useless wayland 
 trash and will never support it. X is so much better.)


No. It doesn't amuse me at all. X11 was/is a wonder in many 
respects. The problem with X11 nowadays is that it is getting 
abandoned. I don't recall the name right now, but I read an 
extensive article the past year (or the other one) in which its 
primary maintainer claimed it lost interest in it (or whatever) 
and the project lacks the resources to get well maintained and so 
and so. So the writing is on the wall. I think Wayland started 
its project seeking tear-less windows but evolved a far-cry from 
there. But like it or not, for the worst or the better, 
everything will be Wayland-centric/dependent a few years from 
now, relegating X11 to a niche. That's my two cents, which can be 
far away from reality, of course.

On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote:

 But since I also think css is bloated I'm just putting hooks in 
 the core so it is an optional feature, just like the xml and 
 script stuff. Turns out that was easier than fixing text bugs. 
 And besides people love their dark modes lol.


CSS was/is an excellent tech for rendering web pages while 
splitting data and style, at least, valid until CSS1. The latter 
CSS version are bloated to the bone. They were developed for the 
ad industry and not for viewing documents which is what the net 
was invented for to begin with. I think if early on the reference 
and commercial webs were developed separately we would end spared 
the XHMTL->HTML4 wars and everything related. CSS to render a 
desktop is overkill, no matter what. Gnome2 with all its 
shortcomings was snappy as hell.

On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote:

 Anyway if you can stand gtk, gtkd really isn't bad and its text 
 widget works. Just don't use the file dialog lololol.


The file dialog is one of the worse things indeed.

Let me clarify a bit:

I am not against innovation and/or change, quite the opposite, I 
love things improving all the time; what I can't bear is change 
for the sake of change, change because the developer/s is/are 
bored and this/that is trendy and sooo cool right now, 
engineering has a de-facto motto: if it works, don't fixit !

That being said, I think GUI design reached a climax between the 
Windows 95/98 and Windows XP era, everything that came afterward 
was, mainly, downhill. What Windows got right on that time-frame 
was the GUI, furthermore, the consistency of the GUI system-wide, 
all programs (errr, what now are called apps) behaved and looked 
the same way, that was the goal, you learned one app, you learned 
them all, nothing deviated from the GUI development guidelines, 
and what deviated was considered subpar. Even the documentation 
(excellent Microsoft manuals on dead-tree media, what-else) on 
GUI development, the what and what not to do was excellent. 
Microsoft got that right. After Windows XP came Vista, and from 
then on, it was primarily Microsoft that demolished all the 
advise published so far by itself -those were the Steve Ballmer 
years (developers ! developers ! developers !) and clearly marked 
a point of inflection.

The early 2000s brought us app skins, and with it, everything 
looked (and started to behave) differently, ending with monsters 
like Cannonical Unity GUI, and meanwhile, destroying perfectly 
working desktops such as gnome 2 (the epitome of user friendly 
design in linux in my view) with gnome 3, all justified on the 
basis that mobile/touch should be integrated to the same base 
instead of developing something specific for it. That left us 
with CSS rendering our desktops ala-browser-engines and 
everything evolved from snappy to quite-a-few-seconds-lag to open 
even a bare window.

End of rant. Excuse me. But I think the above clarifies what I am 
searching for for a GUI toolkit in D. After all, I landed on D 
for its speed besides its cleanliness/power/features.

On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote:

 My minigui is a thing of beauty. Behold:


I'll probably check it out tomorrow since I am going to bed right 
now.

Thanks for your detailed response and for taking your time to 
advise me. I really appreciate that 🙂 !
May 26 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 27 May 2021 at 04:01:31 UTC, someone wrote:

 On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote:

 [...]


 Crystal clear.

 On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote:

 [...]


 No. It doesn't amuse me at all. X11 was/is a wonder in many 
 respects. The problem with X11 nowadays is that it is getting 
 abandoned. I don't recall the name right now, but I read an 
 extensive article the past year (or the other one) in which its 
 primary maintainer claimed it lost interest in it (or whatever) 
 and the project lacks the resources to get well maintained and 
 so and so. So the writing is on the wall. I think Wayland 
 started its project seeking tear-less windows but evolved a 
 far-cry from there. But like it or not, for the worst or the 
 better, everything will be Wayland-centric/dependent a few 
 years from now, relegating X11 to a niche. That's my two cents, 
 which can be far away from reality, of course.

 [...]


I would like to recommend DlangUI [1], but we have tried now for 
months to get in contact with the owner of it (to take over 
development) and are getting no reponse.

1. https://github.com/buggins/dlangui
May 27 2021
next sibling parent someone <someone somewhere.com> writes:
On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote:


 I would like to recommend DlangUI [1], but we have tried now 
 for months to get in contact with the owner of it (to take over 
 development) and are getting no reponse.


Thanks a lot for your info :) !

I want you to know that I am replying to myself on the first post 
summarizing what I already learned researching the subject 
starting with the tips provided by you as well as anyone else 
that replied to my post. Please, if you want and have the time, 
check my last post and let me know anything I got wrong.
May 28 2021
prev sibling parent reply Chris Piker <chris hoopjump.com> writes:
On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote:

 I would like to recommend DlangUI [1], but we have tried now 
 for months to get in contact with the owner of it (to take over 
 development) and are getting no reponse.

 1. https://github.com/buggins/dlangui


Of the 107 forks of dlangui last seen on github, do you know if 
any contain more recent changes/features than the buggins 
original repo? If there's a quick way to check without paging 
through all of them I'm curious to know how it would be done.

I'm using D for efficient server-side processes only, since at 
work we're heavily invested in Java for our end-user GUIs, but 
I'm curious about the state of D GUI toolkits nonetheless.
May 30 2021
next sibling parent evilrat <evilrat666 gmail.com> writes:
On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote:

 On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote:

 I would like to recommend DlangUI [1], but we have tried now 
 for months to get in contact with the owner of it (to take 
 over development) and are getting no reponse.

 1. https://github.com/buggins/dlangui


 Of the 107 forks of dlangui last seen on github, do you know if 
 any contain more recent changes/features than the buggins 
 original repo? If there's a quick way to check without paging 
 through all of them I'm curious to know how it would be done.

 I'm using D for efficient server-side processes only, since at 
 work we're heavily invested in Java for our end-user GUIs, but 
 I'm curious about the state of D GUI toolkits nonetheless.


"Insights -> Network" will show branching overview where you can 
clearly observe what changes were made on each fork

https://github.com/buggins/dlangui/network

DlangUI is somewhat primitive but I like it that way, one can 
quickly hack up pretty much any widget (including graphics) 
without too much hassle, just subclass suitable widget for the 
base, override few methods and start hacking.

Of course I would like it to be real MVVM with view/data 
separation, visual/logical hierarchy separation, data bindings, 
UI automation and stuff. Maybe I'll fork it one day to make it 
that way, but at this moment I already have too much stuff to do.
May 30 2021
prev sibling next sibling parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote:

 On Thursday, 27 May 2021 at 07:00:32 UTC, Imperatorn wrote:

 I would like to recommend DlangUI [1], but we have tried now 
 for months to get in contact with the owner of it (to take 
 over development) and are getting no reponse.

 1. https://github.com/buggins/dlangui


 Of the 107 forks of dlangui last seen on github, do you know if 
 any contain more recent changes/features than the buggins 
 original repo? If there's a quick way to check without paging 
 through all of them I'm curious to know how it would be done.

 I'm using D for efficient server-side processes only, since at 
 work we're heavily invested in Java for our end-user GUIs, but 
 I'm curious about the state of D GUI toolkits nonetheless.


I'm 100% positive you can do good ui using D, but, I'm not sure 
what I'd choose because of the fragmentation.
May 30 2021
parent reply someone <someone somewhere.com> writes:
On Sunday, 30 May 2021 at 11:10:31 UTC, Imperatorn wrote:


 I'm 100% positive you can do good ui using D, but, I'm not sure 
 what I'd choose because of the fragmentation.


Of course you can do a good UI on D, C, C++, Rust, or any other 
system programming language. That is not disputed. From my humble 
point of view, the problem, seems to be that everybody is 
attempting to reinvent gun powder for whatever reasons, many 
maybe valid ones, but the lot of them I think not. This left us 
(as a community) with those statements that you came across on 
any given distro overview/features/wiki page saying something 
like: for doing such thing you have a lot of apps; being those 
blah blah blah ... and of course, none of them work and/or 
accomplish what you want to do because ... a lot of reasons that 
doesn't matter here. There are **lots** of really good apps in 
the open source world: comes to mind (from what I use) postgreSQL 
with its undisputed high quality code/documentation and its 
"sane" community, QGIS, etc, but every such statement should have 
a footnote more or less in the following terms: let's stop 
fooling ourselves.
May 31 2021
parent reply Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Tuesday, 1 June 2021 at 03:32:50 UTC, someone wrote:

 [...]


Yeah, "fragmentation" is a problem. We do a lot of things 90%. We 
need more "100% projects" that are just plug n play rather than 
plug n pray
May 31 2021
parent reply Ola Fosheim Grostad <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 05:27:41 UTC, Imperatorn wrote:

 On Tuesday, 1 June 2021 at 03:32:50 UTC, someone wrote:

 [...]


 Yeah, "fragmentation" is a problem. We do a lot of things 90%. 
 We need more "100% projects" that are just plug n play rather 
 than plug n pray


The solution is to reduce the scope of projects, but that 
requires design and planning. Hobby projects tend to be 
experiments that evolve over time.
May 31 2021
next sibling parent reply evilrat <evilrat666 gmail.com> writes:
On Tuesday, 1 June 2021 at 06:31:28 UTC, Ola Fosheim Grostad 
wrote:

 On Tuesday, 1 June 2021 at 05:27:41 UTC, Imperatorn wrote:

 On Tuesday, 1 June 2021 at 03:32:50 UTC, someone wrote:

 [...]


 Yeah, "fragmentation" is a problem. We do a lot of things 90%. 
 We need more "100% projects" that are just plug n play rather 
 than plug n pray


 The solution is to reduce the scope of projects, but that 
 requires design and planning. Hobby projects tend to be 
 experiments that evolve over time.


Would like to pay for something that's not exists where there is 
already like 10 "good enough"(tm) alternatives? How much people 
actually use D and willing to pay for that?
That's the chicken-egg problem - no funding because no decent 
solutions, no decent solutions because such enormous effort 
requires compensation.

Another issue is that these hobby projects are not state of the 
art solutions, they stuck in early 90's (ok, maybe late 90's), 
where the rest of the world using different architectures and 
approaches that was evolved several times from then.
And yet people who asks for UI libraries goes like "nah, no fancy 
schmancy CSS, and no markup. gimme good ol' programmatical 
approach" or "bloat bloat bloat, no thanks"
Jun 01 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 10:11:25 UTC, evilrat wrote:

 Another issue is that these hobby projects are not state of the 
 art solutions, they stuck in early 90's (ok, maybe late 90's), 
 where the rest of the world using different architectures and 
 approaches that was evolved several times from then.
 And yet people who asks for UI libraries goes like "nah, no 
 fancy schmancy CSS, and no markup. gimme good ol' 
 programmatical approach" or "bloat bloat bloat, no thanks"


Yes, I agree. I think Flutter forced Apple's hand, so they made 
SwiftUI? It is tempting to think that UI-specification is a 
mature field, but apparently not. It is still evolving.

I think the best approach is to create an UI for a specific 
application and then later turn it into a library. Then one at 
least have experience and can sort out weak spots before handing 
it to others.

Maybe if DPlug had more users something interesting would emerge? 
DPlug is the only framework I find interesting with D right now.
Jun 01 2021
parent reply someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 10:53:54 UTC, Ola Fosheim Grøstad 
wrote:


 It is tempting to think that UI-specification is a mature 
 field, but apparently not. It is still evolving.


It is a mature field, they peaked in the late 90s early 00s. What 
came afterwards was mainly decoration/cosmetics because the 
hardware evolved to being able to handle it. But the concepts, 
what a combo-box is, how it works, etc, remained set on stone. Of 
course new controls were invented but most of them were for 
corner-cases or things quite specific like a UI for a pro-audio 
console mixer.


 I think the best approach is to create an UI for a specific 
 application and then later turn it into a library. Then one at 
 least have experience and can sort out weak spots before 
 handing it to others.


I second that providing you use a language like C/C++/D/Rust but 
not something more high-level. One thing is UI 
design/specifications, and the other, the implementation is quite 
a different matter: native vs CSS-style driven etc ... this is 
where things starts to making conflicts.


 Maybe if DPlug had more users something interesting would 
 emerge? DPlug is the only framework I find interesting with D 
 right now.


Will look for it, didn't know of it till now.
Jun 01 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 15:38:51 UTC, someone wrote:

 It is a mature field, they peaked in the late 90s early 00s. 
 What came afterwards was mainly decoration/cosmetics because 
 the hardware evolved to being able to handle it. But the 
 concepts, what a combo-box is, how it works, etc, remained set 
 on stone. Of course new controls were invented but most of them 
 were for corner-cases or things quite specific like a UI for a 
 pro-audio console mixer.


I don't really agree with this, most of the interesting things 
for specifying UIs are happening in web-frameworks/web-standards 
nowadays. But it doesn't matter...

If I were to make a desktop application in D today then I would 
have chosen to either embed a browser-view and use that for 
interface, or electron. Not sure if has been mentioned already, 
but it is an option.
Jun 01 2021
next sibling parent reply IGotD- <nise nise.com> writes:
On Tuesday, 1 June 2021 at 16:20:19 UTC, Ola Fosheim Grøstad 
wrote:

 I don't really agree with this, most of the interesting things 
 for specifying UIs are happening in 
 web-frameworks/web-standards nowadays. But it doesn't matter...

 If I were to make a desktop application in D today then I would 
 have chosen to either embed a browser-view and use that for 
 interface, or electron. Not sure if has been mentioned already, 
 but it is an option.


This is also my observation. Browser UI is on the way to take 
over. Advantages are that they are easy to remote, meaning if you 
have network connection you can run it on another device. Some 
mobile phones have a "hidden" web UI if you connect to them using 
a browser. Another advantage is that web UI scales well with 
different resolutions and aspect ratios. You can also more easily 
find people who have the knowledge making cool looking web 
content, compared to people who know how to make custom UI in Qt 


Car infotainment systems often runs the graphics in a browser, 
without many knowing about it. They work similar to FireFox OS, 
you boot directly to the browser.
Jun 01 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 16:40:22 UTC, IGotD- wrote:

 This is also my observation. Browser UI is on the way to take 
 over. Advantages are that they are easy to remote, meaning if 
 you have network connection you can run it on another device.


Yes, browsers are making X11 obsolete...


 You can also more easily find people who have the knowledge 
 making cool looking web content, compared to people who know 



Web components are becoming a reality, it essentially means that 
you have code and styling wrapped up as a component, so that you 
can use it by inserting a custom html-tag in your code. Given the 
massive amount of web developers... you'll eventually have a 
crazy amount of components to choose from. Just waiting for 
Safari:

https://caniuse.com/?search=components

I think?
Jun 01 2021
next sibling parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 20:20:34 UTC, Ola Fosheim Grøstad 
wrote:

 Web components are becoming a reality, it essentially means


Turns out Microsoft has a UI component library for browsers, 
looks interesting:

https://www.fast.design/
Jun 01 2021
prev sibling parent reply cc <cc nevernet.com> writes:
On Tuesday, 1 June 2021 at 20:20:34 UTC, Ola Fosheim Grøstad 
wrote:

 Web components are becoming a reality, it essentially means 
 that you have code and styling wrapped up as a component, so 
 that you can use it by inserting a custom html-tag in your 
 code. Given the massive amount of web developers... you'll 
 eventually have a crazy amount of components to choose from. 
 Just waiting for Safari:

 https://caniuse.com/?search=components

 I think?


It's 2021 and I'm still waiting for parent selectors.  Even 
:has() isn't implemented by anything yet.
Jun 01 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 June 2021 at 01:29:51 UTC, cc wrote:

 It's 2021 and I'm still waiting for parent selectors.  Even 
 :has() isn't implemented by anything yet.


I think that is because :has() is Selectors Level 4, which is a 
working draft, so not a standard yet.

https://www.w3.org/Style/CSS/current-work
Jun 02 2021
prev sibling parent someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 16:40:22 UTC, IGotD- wrote:

 This is also my observation. Browser UI is on the way to take 
 over.


They are the symptom that the underlying foundations are broken 
so we go the easy way: like we don't want to standardize the APIs 
on our OS so lets fire a browser and get standard APIs. Laziness 
over righteousness because computer power is cheap. And then we 
have all our critical internal data right there on the browser 
and ooops ... what can go wrong ?
Jun 01 2021
prev sibling parent reply someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 16:20:19 UTC, Ola Fosheim Grøstad 
wrote:


 I don't really agree with this, most of the interesting things 
 for specifying UIs are happening in in 
 web-frameworks/web-standards nowadays.


I wasn't considering/referring to content in the browser, this is 
an entirely different arena.


 If I were to make a desktop application in D today then I would 
 have chosen to either embed a browser-view and use that for 
 interface, or electron. Not sure if has been mentioned already, 
 but it is an option.


I don't agree with that at all but I respect your point and 
encourage you to do so provided you'll end with something useful 
to you.

The point with that approach is performance, performance, and did 
I say it ? ... performance.

I don't know about you but, what are the reasons you choose to 
develop in D ? One of the often cited reasons I came across is 
performance alongside with better-C style comments and full OOP 
and the like; which as a side-note it happens to be my case. So 
for a little while put you on my shoes and try to see the subject 
we are discussing from my point of view:

Now think for a instant, that you choose D for performance so you 
expect it to be fast, and you write the hello world app to begin 
with, and you fire-up a full-framework like Electron or the like 
just to give you basic GUI controls. Stretch it a bit, instead of 
using Electron and family you coded a basic HTML page saying 
hello world and put a button in a form element to close the 
page/document and then you embed a web browser within your app, a 
fully-fucking-huge-meaning-millions-of-lines-of-code-with-thousands-of-non-relevant-modules-like-TLS/SSL-Web-Assembly-JavaScri
t-and-keep-counting just to ... render hello world inside your
blazingly-fast-lean D program ?

Will it work ?

Sure.

But, why are we, to begin with, stacking layers upon layers of 
APIs (meaning millions of lines of code and/or degrading 
performance to extreme levels and/or increasing the attack 
surface of our lean app) just to say hello world in a window and 
expecting the user to close it at any given time and ... nothing 
more ?

Why did we choose to use huge frameworks, embed browsers, etc to 
write a simple app ?

Because the basics, the foundations, are broken.

Instead of trying to fix the broken bits to allow us to choose 
the obvious/correct/lean/straightforward path, we, developers 
(and now I am talking from the point of view of the whole 
community), keep using higher and higher levels of abstraction to 
accomplish simple things.

Given the power of a typical computer nowadays there is no excuse 
for a GUI to be blazingly-fast, snappy-as-hell, zero-lag. If 
these symptoms are present we are doing it wrong.

Don't get me wrong: browsers are extremely useful pieces of 
software. The problem is everybody starts to think the browser is 
the OS. This approach, to my humble point of view, is 
short-sighted. We came full-circle: from everything done on the 
mainframe with stupid terminals on the other side of the line, to 
personal computers offloading work from servers and starting 
"thinking" by themselves and all the related client/server stuff 
of the early 90s, to the Sun's vision the-network-is-the-computer 
and all the related Java stuff which more-or-less brought us the 
web browsers, to the google's vision the-web-browser-is-the-OS 
approach. Endless layers upon layers. Web browsers are fantastic 
for browsing/reading complex documents with all its hyperlinks, 
stupid things that now assume for granted, but with its complex 
rendering engines, they are, and I said it once again, fantastic 
pieces of software. The problem with the web browser, and now we 
are backing to the GUI subject we are discussing here, is that 
sometimes in mid-00s their development started to be orchestrated 
by the commercial world and specifically by the ad industry, 
seeing them as software to sell relegating its primary purpose of 
knowledge/browsing documents, that's why we left HTML 4/XHTML 
1.0/1.1 behind and got HTML 5 instead of XHMTL 2 which was the 
right way to go if the browsers kept sticking to their primary 
goal. Now the browser mandates font face/style/size, 
strict-layouts, a magazine, a cool selling magazine on my screen. 
Evolution. Nothing against it, quite the opposite, a 
document-centric and app-centric browser split was what was 
needed then. Dreams. So from then on we started to see the 
decadence of GUI design: buttons that didn't look like buttons at 
all, etc. Which is that ? Ah, dunno, try to click over it and 
let's check if anything happens ... are you following me ? Then 
came Johnny Ives   Apple with its concept of the flat user 
interface. Now everything is flat: is this a button ? is this a 
... ? Who knows. This was followed by everyone outside Apple 
since Apple was cool back then, and we got gnome 3 and KDE Plasma 
and Unity. Everything learned so far went to the trashcan. So 
real people doing real work reacted a bit and we got MATE and the 
like, but it was the timeframe of the desktop being displaced by 
the smartphones and/or tables for moma/popa/and-the-likes and the 
power user now became a niche nobody cared for, very reasonable, 
the real money was not there. Transparent windows ! Why on Earth 
would you want a transparent window ? Do you think taking notes 
back then at college on a transparent or semi-transparent notepad 
would make sense ?

Summarizing a bit: GUIs were oversimplified over time to account 
for the non-tech-savvy users which happened to be the great 
majority of them with the advent of mobile devices, and, instead 
of splitting things apart the GUI was dumbed to extreme levels to 
accommodate such users, the less-common-denominator ... this is 
the problem with GUI design guidelines nowadays. The GUI toolkits 
exploded in complexity to support mobile and every-corner-case 
possible and became very difficult to maintain and that's why I 
think many toolkits stalled. I think someone with the knowledge 
to write a classical toolkit in pure-D following the classical 
design principles with the standard controls and nothing more 
should need deep openGL knowledge to begin with (however a better 
choice should be start from zero with its Vulkan successor) 
providing he/she has access to proven code for text input and/or 
font rendering (quite complex) and besides full-UniCode support 
(which in D is not a problem at all).

This is my two cents.

And of course, feel free to argue on everything you disagree with 
:)
Jun 01 2021
next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 20:56:05 UTC, someone wrote:

 Now think for a instant, that you choose D for performance so 
 you expect it to be fast, and you write the hello world app to 
 begin with, and you fire-up a full-framework like Electron or 
 the like just to give you basic GUI controls.


Well, on a Mac I would just embed a WebView which already is 
ready in the OS UI framework. Electron allows you to execute 
native code I think ("Napi" or something?). A better approach is 
probably to use Chromium Embedded Framework v3, which supposedly 
is multithreaded.


 But, why are we, to begin with, stacking layers upon layers of 
 APIs (meaning millions of lines of code and/or degrading 
 performance to extreme levels and/or increasing the attack 
 surface of our lean app) just to say hello world in a window 
 and expecting the user to close it at any given time and ... 
 nothing more ?


Not that much of a performance bottle neck, unless you push a lot 
of data. I wouldn't use it for an audio/graphics editor. Memory 
usage is more of an issue though. Depends on the app, if it is a 
"clock" then it obviously is too much. If it is a full 
application then it is ok.



 Why did we choose to use huge frameworks, embed browsers, etc 
 to write a simple app ?


Primarily because it cuts down on developer time. It is easy to 
change and you can easily configure it for many configurations 
(e.g. easy to create a limited features version).

This trend will increase as web component repos become available. 
At some point it might become prohibitively expensive to develop 
complex user interfaces without web technology.

Right now, drag-and-drop is not as easily supported in browser 
UIs though. That is an argument for using native UI.



 I think someone with the knowledge to write a classical toolkit 
 in pure-D following the classical design principles with the 
 standard controls and nothing more should need deep openGL 
 knowledge to begin with (however a better choice should be 
 start from zero with its Vulkan successor) providing he/she has 
 access to proven code for text input and/or font rendering 
 (quite complex) and besides full-UniCode support (which in D is 
 not a problem at all).


The problem now is that you have to support both Metal, OpenGL 
ES, and Direct X. Vulkan isn't well enough supported to be a 
convenient target.

History also tells us that hardware GPU abstractions tend to be 
weak and not last very long.

So you are still stuck with an abstraction layer like Skia. It is 
just too expensive to support all hardware yourself.

The game industry spends a lot of money supporting/testing 
various hardware drivers and working around bugs in said 
drivers/hardware.

At the end of the day, the user will be upset if the application 
crashes because of a vulkan-bug/hardware-bug. So in that context 
browser-overhead isn't all that bad.



 And of course, feel free to argue on everything you disagree 
 with :)



It is not so much that I disagree, but the hard reality is that 
there are few attractive alternatives that are portable and also 
cuts down on developer time.

I would personally consider the options:

1. Rolling my own using Skia, especially if I only need mouse 
input and no keyboard.

2. CEF or WebView, just to get to a productive stage sooner. 
Assuming the UI is not pushing a large amount of data.

3. Qt/Gtk, but I think they come with a lot of baggage... so I 
personally don't find it more attractive than WebView for basic 
UIs. If you already know webtech it becomes even less attractive 
to learn a framework that is less flexible than a webview. I 
don't see a healthy future for Qt/Gtk, but webtech is there to 
stay.

Note: Many simple GUI toolkits are horribly inefficient as they 
let each object render themselves.  An efficient GUI engine will 
have to replicate some of the browser complexity...
Jun 01 2021
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad 
wrote:

 Right now, drag-and-drop is not as easily supported in browser 
 UIs though. That is an argument for using native UI.


eh web drag and drop isn't half bad at all. Have you ever used it?


 Note: Many simple GUI toolkits are horribly inefficient as they 
 let each object render themselves.


That doesn't make any sense.
Jun 01 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 22:13:08 UTC, Adam D. Ruppe wrote:

 On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad 
 wrote:

 Right now, drag-and-drop is not as easily supported in browser 
 UIs though. That is an argument for using native UI.


 eh web drag and drop isn't half bad at all. Have you ever used 
 it?


My understanding is that dropping OS icons onto the web view is 
problematic, but maybe they have overcome this because of Chrome 
OS. No, I don't use it, except for file uploads.


 Note: Many simple GUI toolkits are horribly inefficient as 
 they let each object render themselves.


 That doesn't make any sense.


Yes, it does. You get lots of graphic context switches and poor 
render-caching performance.
Jun 01 2021
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 1 June 2021 at 22:39:08 UTC, Ola Fosheim Grøstad 
wrote:

 My understanding is that dropping OS icons onto the web view is 
 problematic


You have to subscribe to the particular content type so it 
doesn't always work but it is totally doable.

You can play with it using simpledisplay.d's drag and drop 
support.


 but maybe they have overcome this because of Chrome OS. No, I 
 don't use it, except for file uploads.


Web drag and drop actually dates back to IE 5. It has been 
cleaned up a little since then and now prefers mime types to the 
type enum it used to do (though both still tend to work) but it 
isn't actually all that different.


 Yes, it does. You get lots of graphic context switches and poor 
 render-caching performance.


no not really.

you'd have to be really incompetent to do it this wrong.
Jun 01 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 22:52:41 UTC, Adam D. Ruppe wrote:

 On Tuesday, 1 June 2021 at 22:39:08 UTC, Ola Fosheim Grøstad 
 wrote:

 Yes, it does. You get lots of graphic context switches and 
 poor render-caching performance.


 no not really.

 you'd have to be really incompetent to do it this wrong.


If each widget imperatively draws itself you get graphic context 
switches every time you draw a different graphical element type.

If the render engine manages this, you have much more opportunity 
to group similar items. E.g. do all text of one font size in one 
GPU operation.

Then you also have the whole issue of backing store (caching) 
which cannot be done in an optimal fashion if the widget is in 
control.
Jun 01 2021
prev sibling next sibling parent reply someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 21:47:38 UTC, Ola Fosheim Grøstad 
wrote:

 Well, on a Mac I would just embed a WebView which already is 
 ready in the OS UI framework.


Thanks for the illustration on how you'll eventually proceed with 
it on the Mac side of things -I use iPhones since the 4 series 
but frankly I never developed on (or used for a significant time) 
a modern Mac.


 Not that much of a performance bottle neck, unless you push a 
 lot of data. I wouldn't use it for an audio/graphics editor. 
 Memory usage is more of an issue though.


It just came to mind the first time I installed and used a linux 
distro for a significant amount of time: it was Ubuntu in the 8~9 
time-frame circa 2008~2009 (Jaunty Jackalope if memory serves), 
and coming from the Windows world, mainly on the Windows server 
platform which we usually (and thoroughly) optimized as 
workstations for our daily drivers (we can't even stood for a 
minute the amount of crap Microsoft dumped on its consumers OSs 
-even configuring them with the classical UI dumping animations 
and a zillion more things), the first thing I noticed and struck 
me was the responsiveness of the GUI: snappy as hell compared to 
the usual Windows 7 machines we dealt with at the time, and, I 
mean snappy as hell **without** customizing it disabling 
animations and the like, this was a responsive GUI 
out-of-the-box. It was on gnome 2 of course. The first time I saw 
gnome 3 was game over.


 Primarily because it cuts down on developer time. It is easy to 
 change and you can easily configure it for many configurations 
 (e.g. easy to create a limited features version). This trend 
 will increase as web component repos become available. At some 
 point it might become prohibitively expensive to develop 
 complex user interfaces without web technology.


If we were on slashdot I would undoubtedly mark this as 
insightful.


 The problem now is that you have to support both Metal, OpenGL 
 ES, and Direct X. Vulkan isn't well enough supported to be a 
 convenient target.


IIRC openGL ES is for mobile not for desktop which needs plain 
openGL.

Of course individually supporting the three main APIs is a no-go, 
that's why I mentioned Vulkan, you say it is not mature, it will 
mature. To me Vulkan is like Wayland, there's no going back 
regardless whether you/we consider it has merits or not.


 History also tells us that hardware GPU abstractions tend to be 
 weak and not last very long.


Indeed. But the market is so huge nowadays that the stakes are 
set higher. Or so I want to believe.


 The game industry spends a lot of money supporting/testing 
 various hardware drivers and working around bugs in said 
 drivers/hardware.


Indeed. But the game industry has totally different 
requirements/expectations for the hardware than we need to write 
a classical 2D GUI toolkit. They need APIs close to the hardware 
as possible and very often bypass everything in its path seeking 
3D performance gains.


 At the end of the day, the user will be upset if the 
 application crashes because of a vulkan-bug/hardware-bug. So in 
 that context browser-overhead isn't all that bad.


I guess Vulkan will have separate 2D/3D APIs like openGL so this 
will be no major concern giving the huge different code base size 
for each, but I am talking of pure guess, I will eventually read 
about it (at least) out of sheer curiosity.


 It is not so much that I disagree, but the hard reality is that 
 there are few attractive alternatives that are portable and 
 also cuts down on developer time.


Sad by true.
Jun 01 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 22:50:49 UTC, someone wrote:

 I noticed and struck me was the responsiveness of the GUI: 
 snappy as hell compared to the usual Windows 7 machines we 
 dealt with at the time, and, I mean snappy as hell **without** 
 customizing it disabling animations and the like, this was a 
 responsive GUI out-of-the-box. It was on gnome 2 of course. The 
 first time I saw gnome 3 was game over.


I am of a similar mindset as you, when I use Linux I tend to go 
minimal WM and setup.

It IS depressing how much resources editors use to reach the same 
fluidity as the editor I used on my Amiga in the 1980s (which 
used hardware registers for scrolling).



 IIRC openGL ES is for mobile not for desktop which needs plain 
 openGL.


Yes, but WebGL is basically the same as ES, WebAssembly 
containers... D is supposed to support those?



 Of course individually supporting the three main APIs is a 
 no-go, that's why I mentioned Vulkan, you say it is not mature, 
 it will mature. To me Vulkan is like Wayland, there's no going 
 back regardless whether you/we consider it has merits or not.


I don't know. Hardware vendors are eager to reach market with new 
hardware and will most likely continue to ship buggy drivers for 
the bleeding edge hardware? But we can always hope. :)



 Indeed. But the game industry has totally different 
 requirements/expectations for the hardware than we need to 
 write a classical 2D GUI toolkit. They need APIs close to the 
 hardware as possible and very often bypass everything in its 
 path seeking 3D performance gains.


Possibly. Yet, Skia release notes keep mentioning hardware 
related themes. I guess that could be your canary (wait until 
release notes no longer list hardware related issues).


 I guess Vulkan will have separate 2D/3D APIs like openGL so 
 this will be no major concern giving the huge different code 
 base size for each, but I am talking of pure guess, I will 
 eventually read about it (at least) out of sheer curiosity.


There is no such thing as 2D/3D anymore AFAIK? Shaders are fairly 
generic.

But you have to support at least Metal and Vulkan, and possibly 
WebGL. Skia is less work.
Jun 01 2021
parent reply someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 23:16:04 UTC, Ola Fosheim Grøstad 
wrote:


 I am of a similar mindset as you, when I use Linux I tend to go 
 minimal WM and setup.



 It IS depressing how much resources editors use to reach the 
 same fluidity as the editor I used on my Amiga in the 1980s 
 (which used hardware registers for scrolling).


Amiga's ? I did have them all (insert REALLY BIG SMILE here) !

I never used anything like Workbench anymore -when I say Ubuntu 
was snappy-as-hell and now remember what was like on the Amiga 
... he. The Windows/Macs of the time seemed escaped out of 
prehistory those days. Even the Atari was far better. But you 
know what ? The IBM PC was the **serious** (laughing out loud) 
way to go. Sad. I did learn a lesson what market forces implied 
back at the time.


 Yes, but WebGL is basically the same as ES, WebAssembly 
 containers... D is supposed to support those?


Didn't know. Thought it was a totally different story. Will look 
it up.


 Of course individually supporting the three main APIs is a 
 no-go, that's why I mentioned Vulkan, you say it is not 
 mature, it will mature. To me Vulkan is like Wayland, there's 
 no going back regardless whether you/we consider it has merits 
 or not.


 I don't know. Hardware vendors are eager to reach market with 
 new hardware and will most likely continue to ship buggy 
 drivers for the bleeding edge hardware? But we can always hope. 
 :)


You have a point. The major bugs/annoyances are pretty soon 
ironed out for the Windows platform and never reach the nixes in 
parity. What we got was late, very late, often when two (or more) 
newer product generations already reached the market and all eyes 
are set on them and nobody cares supporting old hardware for 1% 
niche market share of the nixes. Quite understandable by the way. 
Nvidia/Broadcom being the worst when nix support comes to mind.


 Possibly. Yet, Skia release notes keep mentioning hardware 
 related themes. I guess that could be your canary (wait until 
 release notes no longer list hardware related issues).


Huh


 There is no such thing as 2D/3D anymore AFAIK? Shaders are 
 fairly generic.


Bump.


 Skia is less work.


Have you actually used it within D for anything remotely 
"serious" ? By serious I mean something not a casual/hobby 
project, something that you must rely on.
Jun 01 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Tuesday, 1 June 2021 at 23:42:58 UTC, someone wrote:

 On Tuesday, 1 June 2021 at 23:16:04 UTC, Ola Fosheim Grøstad 
 wrote:

 Possibly. Yet, Skia release notes keep mentioning hardware 
 related themes. I guess that could be your canary (wait until 
 release notes no longer list hardware related issues).


 Huh


When Skia release notes no longer mention changes due to 
hardware, then we can assume that the hardware abstraction is 
workable.


 There is no such thing as 2D/3D anymore AFAIK? Shaders are 
 fairly generic.


 Bump.


Not sure what you meant?


 Skia is less work.


 Have you actually used it within D for anything remotely 
 "serious" ? By serious I mean something not a casual/hobby 
 project, something that you must rely on.


Of course not, D is a hobby and I consider D to be a 
work-in-progress.

Not sure how that relates to Skia? Skia is used in many products. 
If I was to use D for something serious, Skia would probably be 
the first thing I would consider...
Jun 01 2021
next sibling parent someone <someone somewhere.com> writes:
 On Tuesday, 1 June 2021 at 23:42:58 UTC, someone wrote:

 Bump.




On Tuesday, 1 June 2021 at 23:50:35 UTC, Ola Fosheim Grøstad 
wrote:

 Not sure what you meant?


errr ... me neither !

Now seriously: attempted to tell you that evidently I know far 
less than what I think I know.


 Of course not, D is a hobby and I consider D to be a  
 work-in-progress.


Crystal-clear.


 Not sure how that relates to Skia? Skia is used in many  
 products. If I was to use D for something serious, Skia would 
 probably be the first thing I would consider...


ACK.
Jun 01 2021
prev sibling parent reply evilrat <evilrat666 gmail.com> writes:
Btw there is also (dear) imgui, which is immediate mode GUI that 
builds geometry to draw for you, how one would draw it is up to 
programmer. It is very popular in game dev because there is very 
little setup to get it working.

Source
https://github.com/ocornut/imgui

D bindings with GL3 demo
https://github.com/Superbelko/imgui-d



On Tuesday, 1 June 2021 at 23:50:35 UTC, Ola Fosheim Grøstad 
wrote:

 Not sure how that relates to Skia? Skia is used in many 
 products. If I was to use D for something serious, Skia would 
 probably be the first thing I would consider...


Yep, use Skia/Cairo or something like this, don't build your own 
full blown 2D engine for every possible graphics API.

I would like to tune my C++ bindings generator to be able to 
handle Skia ASAP, but can't tell when it will be possible.
Jun 01 2021
parent evilrat <evilrat666 gmail.com> writes:
On Wednesday, 2 June 2021 at 05:43:49 UTC, evilrat wrote:

 Yep, use Skia/Cairo or something like this, don't build your 
 own full blown 2D engine for every possible graphics API.

 I would like to tune my C++ bindings generator to be able to 
 handle Skia ASAP, but can't tell when it will be possible.


It happens that Skia now has C API.
I've generated C bindings and made my own BindBC package from it.

https://github.com/Superbelko/bindbc-skia
Jun 02 2021
prev sibling parent reply drug <drug2004 bk.ru> writes:
02.06.2021 00:47, Ola Fosheim Grøstad пишет:

 Note: Many simple GUI toolkits are horribly inefficient as they let each 
 object render themselves.  An efficient GUI engine will have to 
 replicate some of the browser complexity...


I tried retained and immediate GUI, both fail (imho) for my use case - 
large data set of 1M+ heterogeneous items. GTK and Qt are very 
complicated in case of TreeView widgets in contrast to dear imgui or 
nuklear. In retained GUI (GTK and Qt) you need to prepare your data, 
create some intermediate data, probably copy data. TreeView in immediate 
GUI (imgui, nuklear) is pretty trivial and intuitive - you just use your 
data w/o anything else but it draws all items always so immediate GUI 
works nice if you have small data set. nuklear lets you use large data 
set but only if items have the same height. But because an item of 
TreeView can be collapsed or not its height changes and you need to 
calculate height for each items - you can do it yourself but available 
implementations of immediate GUI aren't capable to use that info so you 
need to modify immediate GUI core system and that is very complicated 
job in contrast to retained GUI where adding new widget is much easier.

I was forced to invent my own wheel some where in-between retained and 
immediate GUI. Later I got know that it worked like browsers did (of 
course in general). I think that browser-like GUI is the future. Just 
current browsers are very over-engineered.

My impression is that immediate and retained GUI belong to different 
domains and are not interchangeable. Browser-like GUI is superset of 
both retained and immediate GUI. Just it should be implemented properly.
Jun 02 2021
parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 June 2021 at 09:37:10 UTC, drug wrote:

 02.06.2021 00:47, Ola Fosheim Grøstad пишет:
 I tried retained and immediate GUI, both fail (imho) for my use 
 case - large data set of 1M+ heterogeneous items.


Depends on the data, I guess, if they are all visible at once 
then you basically have to very carefully write your own GPU 
render stage for that view and carefully cache things that does 
not move by rendering them to buffers (in GPU memory).


 I was forced to invent my own wheel some where in-between 
 retained and immediate GUI. Later I got know that it worked 
 like browsers did (of course in general). I think that 
 browser-like GUI is the future. Just current browsers are very 
 over-engineered.


They have some inefficiencies in how the DOM is being manipulated 
(like setting numeric styles as strings, but there is a fix 
coming for this, maybe it is available already?)

But if you deal with large number of items you basically can 
write your own view and dynamically create elements as the user 
scrolls. You do need to estimate the height though.

You can have a web-worker handling the dataset and basically 
stream it to the main thread that does the GUI. There is a delay 
though, so it takes some tweaking.
Jun 02 2021
parent reply drug <drug2004 bk.ru> writes:
02.06.2021 12:50, Ola Fosheim Grøstad пишет:

 Depends on the data, I guess, if they are all visible at once then you 
 basically have to very carefully write your own GPU render stage for 
 that view and carefully cache things that does not move by rendering 
 them to buffers (in GPU memory).


Usually 1 million of items aren't visible at once. Also there is opinion 
that total redrawing can be more efficient than caching because of 
making a decision what to cache and what not can be very complex.


 But if you deal with large number of items you basically can write your 
 own view and dynamically create elements as the user scrolls. You do 
 need to estimate the height though.


To estimate the height you need to have height of every elements, you 
can't dynamically create elements in that case. I create some wrapper 
over data set that stores height of elements. It's much cheaper and 
faster than creating a widget per item - that is a real advantage over 
retained gui. And user has access to that info - that is advantage over 
immediate gui. But yes, there are tasks that can/should be performed by 
dynamically created elements.
Jun 02 2021
parent Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com> writes:
On Wednesday, 2 June 2021 at 10:17:52 UTC, drug wrote:

 Usually 1 million of items aren't visible at once. Also there 
 is opinion that total redrawing can be more efficient than 
 caching because of making a decision what to cache and what not 
 can be very complex.


Depends on the application.

My view on the GPU has changed a bit as some applications may use 
the GPU for computing application data, also pushing the GPU too 
hard will make it hot and fans  start running (making users 
wonder what the app is doing).

Say, if I used an accounting program and it caused the fan to 
spin, then I would be annoyed. :-D


 To estimate the height you need to have height of every 
 elements, you can't dynamically create elements in that case. I 
 create some wrapper over data set that stores height of 
 elements. It's much cheaper and faster than creating a widget 
 per item - that is a real advantage over retained gui. And user 
 has access to that info - that is advantage over immediate gui. 
 But yes, there are tasks that can/should be performed by 
 dynamically created elements.


Varying heights can be tricky, so just computing the heights in a 
wrapper seems reasonable.

Another approach is to use an estimate that is updated as you 
bring in more items, but that is real work (for the programmer).
Jun 02 2021
prev sibling parent Patrick Schluter <Patrick.Schluter bbox.fr> writes:
On Tuesday, 1 June 2021 at 20:56:05 UTC, someone wrote:

 On Tuesday, 1 June 2021 at 16:20:19 UTC, Ola Fosheim Grøstad 
 wrote:


 [...]


 I wasn't considering/referring to content in the browser, this 
 is an entirely different arena.

 [...]


Thank you! I can only agree.
Jun 03 2021
prev sibling parent someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 10:11:25 UTC, evilrat wrote:


 Would like to pay for something that's not exists where there 
 is already like 10 "good enough"(tm) alternatives? How much 
 people actually use D and willing to pay for that?



 Another issue is that these hobby projects are not state of the 
 art solutions, they stuck in early 90's (ok, maybe late 90's), 
 where the rest of the world using different architectures and 
 approaches that was evolved several times from then.
 And yet people who asks for UI libraries goes like "nah, no 
 fancy schmancy CSS, and no markup. gimme good ol' 
 programmatical approach" or "bloat bloat bloat, no thanks"


Regarding what you say on the state-of-the-art GUI/toolkits I 
should clarify that I am not against "modern" UI development. 
Everyone should work/code as they like and I am no-one to say the 
contrary. What I am against to is the idea of **unifying** the 
UIs for desktop and mobile resulting in sub-par experience for 
both of them -which is what happened.


 That's the chicken-egg problem - no funding because no decent 
 solutions, no decent solutions because such enormous effort 
 requires compensation.


eg: postgreSQL is not on the edge of the state-of-the-art right 
now but it is closing the gap more than ever to the point that 
when there have to be a choice made on merits and not politicals 
it is making a dent in Oracle which is the 800-pound gorilla in 
this category -even against Microsoft's SQL Server which drives a 
lot of things in the enterprise/financial world.

eg: qGIS is another project widely used, and I mean **really** 
widely used for big projects not hobby projects; think city 
plans, dams, and the like -every day real world cases not fuss.

I speak of these because it is what I know of, there should be 
some more, but clearly, this is not the rule, this is the 
exception -and also have in mind that these two projects don't 
get indirectly managed by big corporations alla-linux these days.
Jun 01 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
 We need more "100% projects" that are just plug n play rather 
 than plug n pray




Right,I prefer 1*100% over 3*90%.
Jun 01 2021
parent someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 11:13:49 UTC, zjh wrote:


 Right,I prefer 1*100% over 3*90%.


Without any doubt.
Jun 01 2021
prev sibling parent someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 06:31:28 UTC, Ola Fosheim Grostad 
wrote:

 The solution is to reduce the scope of projects, but that 
 requires design and planning. Hobby projects tend to be 
 experiments that evolve over time.


The solution for (at least some critical) projects is to be 
leaded by a benevolent dictator for their lifespans , but, this 
is, yes, as you probably guess, and as anyone expects, quite 
difficult to cope with. This would bring a clear roadmap, 
consistency, and predictability. But this is irrelevant to this 
post and the subject for an entirely different thread -I don't 
want to insert noise here.
Jun 01 2021
prev sibling parent reply someone <someone somewhere.com> writes:
On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote:

 Of the 107 forks of dlangui last seen on github ...


I can't believe it. What a waste of time/resources. It is like if 
I forked MATE, changed the title, made 10/20/or-so changes here 
and there and then dropped out of sight. Pointless.
May 31 2021
parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Tuesday, 1 June 2021 at 03:36:00 UTC, someone wrote:

 On Sunday, 30 May 2021 at 07:03:38 UTC, Chris Piker wrote:

 Of the 107 forks of dlangui last seen on github ...


 I can't believe it. What a waste of time/resources. It is like 
 if I forked MATE, changed the title, made 10/20/or-so changes 
 here and there and then dropped out of sight. Pointless.


Have you ever used github before?

That's how it works. You "fork" something, do a small change, 
then open a pull request back to the original. Then your "fork" 
gets abandoned until next time you want to do a PR.

This is perfectly normal on that site. Number of forks is 
actually correlated with number of *contributors*, not 
abandonment.
Jun 01 2021
parent someone <someone somewhere.com> writes:
On Tuesday, 1 June 2021 at 11:52:51 UTC, Adam D. Ruppe wrote:

 Have you ever used github before?


No I did not.


 That's how it works. You "fork" something, do a small change, 
 then open a pull request back to the original. Then your "fork" 
 gets abandoned until next time you want to do a PR.


My first guess was lots of projects going on each one's 
directions. Sorry for this comment. I should know better :(


 This is perfectly normal on that site. Number of forks is 
 actually correlated with number of *contributors*, not 
 abandonment.


ACK.
Jun 01 2021
prev sibling parent someone <someone somewhere.com> writes:
On Thursday, 27 May 2021 at 02:55:14 UTC, Adam D. Ruppe wrote:

 http://arsdnet.net/minigui-linux.png
 http://arsdnet.net/minigui-sprite.png


Thanks a lot for your info :) !

I want you to know that I am replying to myself on the first post 
summarizing what I already learned researching the subject 
starting with the tips provided by you as well as anyone else 
that replied to my post. Please, if you want and have the time, 
check my last post and let me know anything I got wrong.
May 28 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:

 Yes,


I have download FOX.and success compile.
I think it is very good.small and beauty.
May 27 2021
next sibling parent someone <someone somewhere.com> writes:
On Thursday, 27 May 2021 at 07:20:17 UTC, zjh wrote:


 I have download FOX.and success compile.
 I think it is very good.small and beauty.


Thanks a lot for your info :) !

I want you to know that I am replying to myself on the first post 
summarizing what I already learned researching the subject 
starting with the tips provided by you as well as anyone else 
that replied to my post. Please, if you want and have the time, 
check my last post and let me know anything I got wrong.
May 28 2021
prev sibling parent zjh <fqbqrr 163.com> writes:
On Thursday, 27 May 2021 at 07:20:17 UTC, zjh wrote:

 On


maybe try Gacui.
May 30 2021
prev sibling next sibling parent reply btiffin <btiffin myopera.com> writes:
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:

 Yes, I know this is a question lacking a straightforward answer.


I'm only on a third serious with D day, but I want to take a kick 
at wrapping libAgar now.

libagar is a nice little framework.  But, it's C still (and Ada, 
Perl, COBOL), not D yet.  Will see how it goes.

Very cross platform, the Uniike (unixlike, sans tm) systems, 
nintendo, c64, but that's microagar.  Developed on a BSD system.

http://libagar.org/
May 27 2021
parent someone <someone somewhere.com> writes:
On Thursday, 27 May 2021 at 09:01:04 UTC, btiffin wrote:


 libagar is a nice little framework.  But, it's C still (and 
 Ada, Perl, COBOL), not D yet.  Will see how it goes.


Thanks a lot for your info :) !

I want you to know that I am replying to myself on the first post 
summarizing what I already learned researching the subject 
starting with the tips provided by you as well as anyone else 
that replied to my post. Please, if you want and have the time, 
check my last post and let me know anything I got wrong.
May 28 2021
prev sibling next sibling parent reply =?UTF-8?B?0JLQuNGC0LDQu9C40Lkg0KTQsNC0?= =?UTF-8?B?0LXQtdCy?= writes:
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:

 Yes, I know this is a question lacking a straightforward answer.

 Requirements:

 [...]


sciter, of course.  https://sciter.com/
Or write Dlang alternative.
May 27 2021
next sibling parent Alain De Vos <devosalain ymail.com> writes:
I very succefully used tkd and gtkd, d binding to tk and gtk.

Can someone guide me to using fox or fltk ?
May 27 2021
prev sibling parent reply someone <someone somewhere.com> writes:
On Thursday, 27 May 2021 at 09:11:44 UTC, Виталий Фадеев wrote:


 sciter, of course.  https://sciter.com/
 Or write Dlang alternative.


Thanks a lot for your info :) !

I want you to know that I am replying to myself on the first post 
summarizing what I already learned researching the subject 
starting with the tips provided by you as well as anyone else 
that replied to my post. Please, if you want and have the time, 
check my last post and let me know anything I got wrong.

I need to research sciter a bit more: a first sight is not what I 
am looking for, it seems is has something like a browser 
rendering engine to apply what you define in a resource file, if 
so, I guess it will be very slow compared with any native and/or 
quasi-native toolkit. Give me more time and I'll keep you posted.
May 28 2021
parent zjh <fqbqrr 163.com> writes:
On Saturday, 29 May 2021 at 00:52:10 UTC, someone wrote:

 sciter, of course.  https://sciter.com/




I've also been looking for `good GUI`.
Now, I just find `WTL`. I don't like `QT`. It's too big.
I don't like `LGPL`. You can't link statically.
If you want to bind, I think `wxwidget` is good.
`Sciter's` problem is that it doesn't open source. Their 
binding(`wx/sciter`) is `out of date`.
There is also a `beamui`.
May 28 2021
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:

 Yes, I know this is a question lacking a straightforward answer.

 Requirements:

 [...]


I humbly believe the most complete one is GtKD.

https://gtkdcoding.com/
https://gtkd.org

We all wish there was a STANDARD D GUI library out there, but 
that is a huge effort one or two individuals can't do by 
themselves (that is why all such efforts failed in the past)...
May 27 2021
next sibling parent reply Alain De Vos <devosalain ymail.com> writes:
Let's also not forget other languages have problems with 
gui-toolkits.
For instance, gtk-ada binding has memory leaks. gtk-crystal 
binding is broken.
I would like to see a binding to wxwidgets which is a very cool 
toolkit.
May 27 2021
next sibling parent reply Alain De Vos <devosalain ymail.com> writes:
I think dlangui is a dead monkey.
May 27 2021
parent Imperatorn <johan_forsberg_86 hotmail.com> writes:
On Thursday, 27 May 2021 at 18:57:32 UTC, Alain De Vos wrote:

 I think dlangui is a dead monkey.


Nah, it's ok
May 28 2021
prev sibling next sibling parent reply zjh <fqbqrr 163.com> writes:
On Thursday, 27 May 2021 at 17:04:07 UTC, Alain De Vos wrote:

 Let's


+100000
May 27 2021
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 28 May 2021 at 00:05:36 UTC, zjh wrote:

If there is a binding of wxWidgets.
then is good.
May 27 2021
parent reply zjh <fqbqrr 163.com> writes:
On Friday, 28 May 2021 at 00:07:41 UTC, zjh wrote:

 On Friday,


maybe you can try nana.
May 27 2021
parent reply someone <someone somewhere.com> writes:
On Friday, 28 May 2021 at 01:44:24 UTC, zjh wrote:

 maybe you can try nana.


nana ? can you elaborate please ?
May 28 2021
parent zjh <fqbqrr 163.com> writes:
 maybe you can try nana.




nanapro,I just success compile.
May 28 2021
prev sibling parent reply someone <someone somewhere.com> writes:
On Thursday, 27 May 2021 at 17:04:07 UTC, Alain De Vos wrote:

 Let's also not forget other languages have problems with 
 gui-toolkits.
 For instance, gtk-ada binding has memory leaks. gtk-crystal 
 binding is broken.
 I would like to see a binding to wxwidgets which is a very cool 
 toolkit.


It seems to me the bindings are the symptoms and not the causes: 
the problem, to my humble opinion, is that for whatever reasons, 
we have a **lot** of toolkits trying to reinvent powder over and 
over. In Windows/Mac there's no problem since more-or-less they 
have standard controls, and anyone not using them is because they 
bypass them pursuing multi-platform support. In the nixes is more 
complicated since there were never standard/unified 
controls/guidelines. There are people who thinks diversity is a 
plus and there others stating standardization is the way forward. 
Like it or not, that is we have on the nixes.
May 28 2021
parent reply Alain De Vos <devosalain ymail.com> writes:
One additional toolkit, fltk,
https://www.fltk.org/
May 29 2021
parent someone <someone somewhere.com> writes:
On Saturday, 29 May 2021 at 10:52:11 UTC, Alain De Vos wrote:

 One additional toolkit, fltk,


Just checked it:

FLTK (aka fulltick) for C++ targeting X with openGL: 
[screenshots](https://www.fltk.org/shots.php)

- we do not depend on text-based attributes (GTK+, MOTIF), 
complex chains of support libraries (GTK+, KDE, wxWidgets), 
workarounds to provide OO features in standard C (GTK+), a 
special compiler preprocessor (KDE), or a non-standard variant of 
C (Cocoa)

- supports UniCode and HiDPI since version 1.3.6-STABLE

Seems worth a try I guess.
May 31 2021
prev sibling next sibling parent someone <someone somewhere.com> writes:
On Thursday, 27 May 2021 at 16:49:41 UTC, Dejan Lekic wrote:


 I humbly believe the most complete one is GtKD.

 https://gtkdcoding.com/
 https://gtkd.org

 We all wish there was a STANDARD D GUI library out there, but 
 that is a huge effort one or two individuals can't do by 
 themselves (that is why all such efforts failed in the past)...


Thanks a lot for your info :) !

I want you to know that I am replying to myself on the first post 
summarizing what I already learned researching the subject 
starting with the tips provided by you as well as anyone else 
that replied to my post. Please, if you want and have the time, 
check my last post and let me know anything I got wrong.



desktop environment which in reality is a stripped down version 
of MATE itself: the widget that rocks is the MATE panel, 
everything else is questionable, not to mention really bad 
software like Atril (the PDF viewer). I do run MATE on archlinux 
right now and built the package myself setting aside everything I 
do not want/use.


or, if they plan to deprecate it moving ahead ?
May 28 2021
prev sibling parent reply btiffin <btiffin myopera.com> writes:
On Thursday, 27 May 2021 at 16:49:41 UTC, Dejan Lekic wrote:

 [...]


 I humbly believe the most complete one is GtKD.

 https://gtkdcoding.com/
 https://gtkd.org

 We all wish there was a STANDARD D GUI library out there, but 
 that is a huge effort one or two individuals can't do by 
 themselves (that is why all such efforts failed in the past)...


Agree about GTK and completeness (though D explorations still 
counted under 100 hours).

Will politely disagree about 1 or 2 can't do by themselves...  
Yeah, yeah they can.  :-)  Magic people.  Ok, people with skills 
so advanced (relative to the rest of us) as to be 
indistinguishable from magic.

REBOL, Carl on REBOL dialects for layout with a partner coding 
view graphic drivers.  For example.  It can happen, and does 
happen.  Super star doers.

Rare, yes.  Happens.  There is hope.  And yes, agree, lots of 
fail, *but not all, fail*.

Have good, make well,
Blue
May 29 2021
parent Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 29 May 2021 at 10:51:47 UTC, btiffin wrote:

 Will politely disagree about 1 or 2 can't do by themselves...  
 Yeah, yeah they can.


Well, I've actually done it.

My minigui has its quirks I'm slowly working through, but it 
clearly isn't impossible.
May 29 2021
prev sibling next sibling parent reply Vinod K Chandran <kcvinu82 gmail.com> writes:
On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:


I am learning D by writing a Windows only GUI library. It is 
taking too much time for me since, I am writing some stuff and 
then happen to learn some new things about it and re-writing 
it.Anyhow, so far so good. This is the code now.

```d
import winglib ;
import std.stdio : log = writeln;

void main() { 	

	auto frm = new Window() ;	
	frm.text = "Learning D By Writing D";

         // C = Control class. Window is derived from Control
         // E = EventArgs.

	frm.onMouseHover = (c, e) => log("Mouse is now on ", e.x, ", ", 
e.y);
	frm.onMouseLeave = (c, e) => log("Mouse leaved from window") ;	
	frm.onKeyDown =  (c, e) => log(e.keyCode, " key is pressed");
	frm.create() ;

	auto btn = new Button(frm) ;
	btn.font.name = "Calibri" ;
         btn.width = 150 ;
	btn.text = "DMD Or LDC" ;
	btn.font.size = 14 ;
	btn.create() ;

	frm.show() ;	
	
}
```
I am slowly adding more features to this. Till now, Window & 
Button are completed.



 May 28 2021



  parent reply Marcone <marcone email.com>  writes:


On Friday, 28 May 2021 at 17:04:15 UTC, Vinod K Chandran wrote:

 On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:


 I am learning D by writing a Windows only GUI library. It is 
 taking too much time for me since, I am writing some stuff and 
 then happen to learn some new things about it and re-writing 
 it.Anyhow, so far so good. This is the code now.

 ```d
 import winglib ;
 import std.stdio : log = writeln;

 void main() { 	

 	auto frm = new Window() ;	
 	frm.text = "Learning D By Writing D";

         // C = Control class. Window is derived from Control
         // E = EventArgs.

 	frm.onMouseHover = (c, e) => log("Mouse is now on ", e.x, ", 
 ", e.y);
 	frm.onMouseLeave = (c, e) => log("Mouse leaved from window") ;	
 	frm.onKeyDown =  (c, e) => log(e.keyCode, " key is pressed");
 	frm.create() ;

 	auto btn = new Button(frm) ;
 	btn.font.name = "Calibri" ;
         btn.width = 150 ;
 	btn.text = "DMD Or LDC" ;
 	btn.font.size = 14 ;
 	btn.create() ;

 	frm.show() ;	
 	
 }
 ```
 I am slowly adding more features to this. Till now, Window & 
 Button are completed.


Win32Api + Metaprogramming?



 May 28 2021



  parent  Vinod K Chandran <kcvinu82 gmail.com>  writes:


On Saturday, 29 May 2021 at 01:04:02 UTC, Marcone wrote:


 Win32Api + Metaprogramming?


Yes.



 May 29 2021



prev sibling next sibling parent  someone <someone somewhere.com>  writes:


On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:


 Any comments are welcomed, even any comments regarding anyone 
 experience with GUI development within D, no matter whether the 
 answer would be relevant to my specific question seeking a 
 choice or not.


First and foremost, thanks everybody for your replies :) !

I didn't know some of the toolkits you advised me to try even 
existed.

There was a lot of info for me to digest before starting 
answering you on some of the specifics and/or personal experience 
with them, so, I did my homework and make the following summary 
(mainly relevant to my requirements) to organize my thoughts so I 
could make a roadmap to start selecting/discarding toolkits, and 
please, let me know anything I got wrong and/or point me to 
anything that is plainly wrong in the following summary:

- Microsoft 
[MFC](https://en.wikipedia.org/wiki/Microsoft_Foundation_Class_Library) is a
Microsoft Visual C++ wrapper around the Windows API
- Microsoft [Windows 
Forms](https://en.wikipedia.org/wiki/Windows_Forms) for the net 
framework (not a Windows API wrapper)
- Microsoft 
[WPL](https://en.wikipedia.org/wiki/Windows_Presentation_Foundation) (aka
Windows Presentation Foundation) for the net framework 3.0 using XAML or any
CLR language

1](https://docs.microsoft.com/windows/apps/winui/)

2](https://docs.microsoft.com/windows/apps/winui/winui2/release-notes/) for UWP
XAML apps

3](https://docs.microsoft.com/windows/apps/winui/winui3/release-notes/) for UWP
XAML / Win32 apps (aka Project Reunion)

- Gnome [GNUstep](https://en.wikipedia.org/wiki/GNUstep) for 
Objective-C
- Apple [Cocoa](https://en.wikipedia.org/wiki/Cocoa_(API)) for 
Objective-C

- [MOTIF](https://en.wikipedia.org/wiki/Motif_(software)) for C 
is a legacy UNIX toolkit
- [libagar](http://libagar.org/) (aka agar) for 
(industry-standard ANSI X3.159-1989) C: 
[documentation](http://libagar.org/docs) for 
[1.6.0](http://libagar.org/mdoc.cgi?man=AG_Intro.3), 
[screenshots](http://libagar.org/screenshots.html)
    - supports texture and GPU acceleration wherever available
    - supports linux/freeBSD/dragonFlyBSD (at least)

- [Fox](http://www.fox-toolkit.org/home.html) for C++: 
[overview](http://www.fox-toolkit.org/goals.html), plain 
[documentation](http://www.fox-toolkit.org/doc.html), 
[FAQ](http://www.fox-toolkit.org/faq.html), and 
[screenshots](http://www.fox-toolkit.org/screenshots.html)
    - relies only on core system facilities and **does not wrap** 
native GUI libraries or toolkits
    - supports linux/freeBSD (at least)
    - used by the xfe file manager app

- [wxWidgets](https://en.wikipedia.org/wiki/WxWidgets) (former 
wxWindows) for C++: 
[overview](https://docs.wxwidgets.org/3.0/page_introduction.html), excellent
plain [documentation](https://docs.wxwidgets.org/3.0/),
[tutorials](https://docs.wxwidgets.org/3.0/page_topics.html); eg: [hello world
app](https://docs.wxwidgets.org/3.0/overview_helloworld.html)
    - supports native platform controls wherever possible
    - supports UniCode: 
(https://docs.wxwidgets.org/3.0/overview_unicode.html)overview
    - wxMSW is the native port for Microsoft Windows


    - first-impressions: fully-alive

- 
[arsd](http://dpldocs.info/experimental-docs/arsd.html#desktop-gui):
[simpledisplay](http://dpldocs.info/experimental-docs/arsd.simpledisplay.html)
→ [minigui](http://dpldocs.info/experimental-docs/arsd.minigui.html) for D:
plain documentation
    - simpleDisplay provides basic cross-platform GUI-related 
functionality: creating windows, drawing on them, working with 
the clipboard, timers, openGL, and more; but, **does not 
provide** high-level GUI widgets
    - simpleDisplay does not have any dependencies outside the OS 
and color.d
    - simpleDisplay should support UniCode and i18n 
internationalization since its written in D to begin with (my 
assumption)
    - miniGUI primary goal is to be useful without being large and 
complicated (like GTK and/or QT) and it isn't hugely concerned 
with appearance
    - miniGUI keeps it simple on linux: some controls can be 
customized with CSS-inspired Widget.Style classes
    - miniGUI supports the native controls/themes on Windows
    - miniGUI supports creating widget trees at runtime from XML 
with arsd.minigui_xml
    - miniGUI requirements are arsd.simpledisplay and arsd.color 
dependencies on which it is built: nothing more
    - miniGUI had mostly additive changes or bug fixes since its 
inception until 05-2021
    - miniGUI should support UniCode and i18n internationalization 
since its written in D to begin with (my assumption)

- [dlangUI](https://github.com/buggins/dlangui) for D: 
[documentation](http://buggins.github.io/dlangui/ddox/), 
[tutorials](https://github.com/buggins/dlangui/wiki), and 
[screenshots](http://buggins.github.io/dlangui/screenshots.html)
    - it is a major-refactored port of the Cool Reader app project 
for C++
    - supports openGL based acceleration: fallbacks to pure Win32 
API / SDL / X11 when the openGL library is not available and/or 
cannot be loaded
    - supports highly-customizable styles and themes
    - supports UniCode and i18n internationalization
    - requirements: DMD ≥ 2.077
    - requirements: third-party: DerelictGL3 for OpenGL support
    - requirements: third-party: DerelictFT and FreeType library 
support under linux and optionally under Windows
    - requirements: third-party: DerelictFI and FreeImage library 
support for image decoding
    - requirements: third-party: DerelictSDL2 and SDL2 for cross 
platform support
    - requirements: third-party: XCB and X11 bindings (patched) 
when SDL2 is not used
    - first-impressions: seems abandoned

- Gnome [GTK+](https://en.wikipedia.org/wiki/GTK%2B) (former GIMP 
ToolKit) for C (using GObject library targeting Glib) (currently 
using Cairo)
    - primarily targeting the X-Windows system
    - used in Gnome, LXDE, XFCE, MATE, Cinamon
    - used by Marco, Mutter, Xfwm (and some more) window managers

- [QT](https://en.wikipedia.org/wiki/Qt_(framework)) is for C++
    - primarily targeting the X-Windows system or Wayland
    - used in KDE, LXQT, Lumina, Unity
    - QT [has removed LTS from the OSS 
community](https://catfox.life/2021/03/21/really-leaving-the-li
ux-desktop-behind/) plainly admitting they want us to be their beta testers and
that paid commercial users are the only ones who deserve stability

- 
[Elementary](https://en.wikipedia.org/wiki/Enlightenment_Foundation_Libraries)
for C
    - part of EFL (aka Elementary Foundation Libraries)

- [sciter](https://sciter.com/): is an embeddable 
HTML/CSS/JavaScript engine for modern UI development
    - still need to research it: left it as the last one because 
it seems it is the opposite of what I am looking for

At first glance, but that could end quite differently, possible 
ones are (ordering not standing): dlangUI and arsd.miniGUI 
written in D, agar written in C, Fox and wxWidgets written in C++.

Regarding dlangUI: its a shame if it was really abandoned ... 
does someone seriously considered forking it ? Or is it pointless 
since it needs a lot of human resources that are not there to 
begin with which is what I suspect ?



 May 28 2021



prev sibling next sibling parent reply Marcone <marcone email.com>  writes:


On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:

 Yes, I know this is a question lacking a straightforward answer.

 Requirements:

 [...]


Win32Api. You can use resEdit to create your resource GUI. Work 
only for Windows. Here is my program created with Dlang and 
Win32Api GUI:   
https://sourceforge.net/projects/direct-http-tunnel/



 May 28 2021



  parent  someone <someone somewhere.com>  writes:


On Saturday, 29 May 2021 at 00:57:51 UTC, Marcone wrote:


 Win32Api. You can use resEdit to create your resource GUI. Work 
 only for Windows. Here is my program created with Dlang and 
 Win32Api GUI:   
 https://sourceforge.net/projects/direct-http-tunnel/


Thanks a lot for your info :) !

I want you to know that I am replying to myself on the first post 
summarizing what I already learned researching the subject 
starting with the tips provided by you as well as anyone else 
that replied to my post. Please, if you want and have the time, 
check my last post and let me know anything I got wrong.

I do have a LOT of experience coding on the Windows platform, I 
have no less than 20 years at least, since Windows NT 1.0 
precisely, I do feel at ease with Win32 and COM. The problem 
right now is that, for whatever reasons, I stopped being coding 
Microsoft-centric solutions 5 or-so years ago. I am on archlinux 
right now and have a few boxes running freeBSD and/or 
DragonFlyBSD. I do not plan to go back to Microsoft. Obviously, I 
miss a lot of things; but mainly, SQL-Server, everything 
XML-related which is rock-solid on the Microsoft side, and last 
but not least, PowerShell, which I love by design but regret the 
way that was implemented, specially since the 2.0 release, it 
ended really bloated, but the concept, rocks.

I started to left ship with MicroSoft in the Vista ~ Windows 8 
time frame and left definitely on Windows 9/10. My last boxes 
still run Windows Server 2008 R2 with the newer versions of 
SQL-Server. Ballmer destroyed Microsoft as quality code. The 
userspace since Vista was terrible -and don't get me started on 
the Metro UI.



 May 28 2021



prev sibling next sibling parent reply cc <cc nevernet.com>  writes:


This is overkill for any reasonable application, but I've always 
wanted to design a whole UI framework in OpenGL, just for the 
novelty of it.  I always end up having to reinvent the wheel for 
UI elements in my projects anyway.

https://streamable.com/2uvt4h



 May 30 2021



 next sibling parent reply Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com>  writes:


On Sunday, 30 May 2021 at 12:09:22 UTC, cc wrote:

 This is overkill for any reasonable application, but I've 
 always wanted to design a whole UI framework in OpenGL, just 
 for the novelty of it.  I always end up having to reinvent the 
 wheel for UI elements in my projects anyway.

 https://streamable.com/2uvt4h


There are many GUIS for OpenGL, but OpenGL is no longer supported 
on Macs AFAIK.

I suggest using Skia instead:

https://skia.org/

IIRC it is used in Chromium and Flutter.



 May 30 2021



  parent reply someone <someone somewhere.com>  writes:


On Sunday, 30 May 2021 at 12:18:06 UTC, Ola Fosheim Grøstad wrote:

 There are many GUIS for OpenGL, but OpenGL is no longer  
 supported on Macs AFAIK.


Indeed: openGL on all Apple platforms was finally deprecated on 
2018 after Apple introduced its own proprietary Metal API.


 I suggest using Skia instead:


I been reading about it:

Skia developed by google for C++ using openGL

- most similar in purpose to Cairo or PathFinder (meaning that it 
focuses on drawing) rather than to other more elaborate 
infrastructures like QT that provide their own widgets [skia   
wikipedia.org](https://en.wikipedia.org/wiki/Skia_Graphics_Engine)
- used by google Chrome, Chrome OS, Chromium OS, Mozilla FireFox 
∧ ThunderBird, Android, FireFox OS, LibreOffice, etc

- supports several platform-dependent back-ends; including:
  - CPU-based software rasterization
  - GPU-accelerated openGL, openGL ES, Vulkan, and Metal
  - PDF output
  - SVG output ... partially implemented



 May 31 2021



  parent  Ola Fosheim =?UTF-8?B?R3LDuHN0YWQ=?= <ola.fosheim.grostad gmail.com>  writes:


On Tuesday, 1 June 2021 at 03:16:05 UTC, someone wrote:

 Skia developed by google for C++ using openGL


I think it uses Metal, OpenGL ES, translation layer to OpenGL and 
Direct X, backend for Vulkan (but Vulkan hardware drivers 
apparently tend to be buggy). Also a build for webassembly.

It is the graphics engine for Chrome and Firefox, so it is 
probably the best bet if you want cross platform support.

See release notes for progression:

https://skia.org/docs/user/release/release_notes/



 Jun 01 2021



prev sibling  parent  someone <someone somewhere.com>  writes:


On Sunday, 30 May 2021 at 12:09:22 UTC, cc wrote:


 https://streamable.com/2uvt4h


cool ... to say the least 😎 !



 May 31 2021



prev sibling next sibling parent reply Siemargl <inqnone gmail.com>  writes:


On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:

 Yes, I know this is a question lacking a straightforward answer.

 Requirements:

 - desktop only: forget about support for mobile tablets whatever


You forget semi-official DWT
https://forum.dlang.org/group/dwt



 May 30 2021



 next sibling parent reply dangbinghoo <dangbinghoo gmail.com>  writes:


On Sunday, 30 May 2021 at 12:27:34 UTC, Siemargl wrote:

 On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:

 Yes, I know this is a question lacking a straightforward 
 answer.

 Requirements:

 - desktop only: forget about support for mobile tablets 
 whatever


 You forget semi-official DWT
 https://forum.dlang.org/group/dwt


don't sell it official, even semi-*. it had very bad platform 
support, dub support and ...



 May 30 2021



  parent  someone <someone somewhere.com>  writes:


On Monday, 31 May 2021 at 02:18:35 UTC, dangbinghoo wrote:

 don't sell it official, even semi-*. it had very bad platform 
 support, dub support and ...


Thanks for the clarification -from what I'm learning and seeing 
it seems a lot of the toolkits are dead or closer to.



 May 31 2021



prev sibling  parent reply someone <someone somewhere.com>  writes:


On Sunday, 30 May 2021 at 12:27:34 UTC, Siemargl wrote:

 You forget semi-official DWT


For starters I was advised that it is in not good shape. Another 
one going down :(



 May 31 2021



  parent reply Mike Parker <aldacron gmail.com>  writes:


On Tuesday, 1 June 2021 at 03:18:22 UTC, someone wrote:

 On Sunday, 30 May 2021 at 12:27:34 UTC, Siemargl wrote:

 You forget semi-official DWT


 For starters I was advised that it is in not good shape. 
 Another one going down :(


But have you actually investigated it? It's being actively 
maintained.

https://github.com/d-widget-toolkit/dwt



 May 31 2021



 next sibling parent  Adam D. Ruppe <destructionator gmail.com>  writes:


On Tuesday, 1 June 2021 at 05:26:47 UTC, Mike Parker wrote:

 But have you actually investigated it? It's being actively 
 maintained.

 https://github.com/d-widget-toolkit/dwt


Yeah, DWT is solidly OK. I'd pick it over gtkd if you wanted to 
target Windows since it doesn't use gtk there.



 Jun 01 2021



prev sibling  parent  someone <someone somewhere.com>  writes:


On Tuesday, 1 June 2021 at 05:26:47 UTC, Mike Parker wrote:


 But have you actually investigated it? It's being actively 
 maintained.


Being advised not to use it is not the same as saying won't use 
it; however I consider it a red flag, or to say it in other 
words, something that I have to pay even more attention to before 
start using it in order to not shoot me on the foot. I am 
researching the whole subject of GUI toolkits and right now I 
have no less than 10 toolkits to go so, even downloading, 
installing, configuring, reading some basic documentation, and 
making something stupid like a hello world app for each one will 
take some time, this is no surprise. Up to this point I didn't 
discard anything since I am aware I still have no deep 
insights/basis to. Give me some time please, but anything that 
comes to mind keep telling me, it helps a lot, thanks :) !



 Jun 01 2021



prev sibling  parent  btiffin <btiffin myopera.com>  writes:


On Thursday, 27 May 2021 at 01:17:44 UTC, someone wrote:


 Any comments are welcomed, even any comments regarding anyone 
 experience with GUI development within D, no matter whether the 
 answer would be relevant to my specific question seeking a 
 choice or not.


Along that tack, and as an informational tidbit, if you (any one, 
not just to someone) ever find yourself with a desperate need for 
a gui, but lack development tooling, there is always the 
messaging interface to GTK, GTK-Server, by Peter van Eerten, 
author of BaCon.

gtk-server is GTK by proxy.  Send messages, get GUIs.  Not fast, 
but readily available to hundreds of programming languages.

https://gtk-server.org/intro.html

And for anyone interested in how some geniuses create programming 
environments, BaCon is a BASIC to C converter.  Ships as a shell 
script, that reads itself to self-host a C codegen pass, to 
produce a native compiled bacon compiler.  Self hosted as a shell 
script.  *That alone should warrant a trophy.*  And Peter has 
coded the shell script so that it can actually run as the 
converter compiler for BASIC, or convert itself to C to native 
bacon.

http://basic-converter.org/ worthy of a read.

Have good, make well,
Blue



 May 30 2021