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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
next sibling parent reply Alain De Vos <devosalain ymail.com> writes:
I think dlangui is a dead monkey.
May 27
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
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
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
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
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
parent zjh <fqbqrr 163.com> writes:
 maybe you can try nana.
nanapro,I just success compile.
May 28
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
parent reply Alain De Vos <devosalain ymail.com> writes:
One additional toolkit, fltk,
https://www.fltk.org/
May 29
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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