www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Is UI interesting for us?

reply Ikey Doherty <ikey serpentos.com> writes:
Most of the time I've been a backend engineer. However at times I 
do need to write an app, and usually I go with Gtk.

However, I'm a bit concerned that gtk-d seems .. well, catatonic. 
DWT also appears to be beyond life support.

We all know Rust has iced-rs, which due to the design of Rust has 
had to adopt the Elm paradigm.

D, with features that honestly don't need reiterating, could 
trivially manage OOP, ECS, mixins...

Is there general interest in UI within the D community? And is 
there enough to have our own toolkit, or would we be better 
placed to contribute to the likes of gtk-d?

I have a selfish interest in this, hence asking. While spinning a 
ui toolkit isn't hard, doing it properly can be (accessibility)
Mar 25 2023
next sibling parent AnimusPEXUS <animuspexus protonmail.com> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 ...


some time ago I've started some GUI project 
https://github.com/AnimusPEXUS/dtk , but I've stuck on wayland 
support. I'd could continue If wayland bindings would be ok 
https://github.com/AnimusPEXUS/dtk/issues/1. also EGL bindings 
would be great (but I can't really tell, as I didn't experimented 
with it yet). also I don't mind if somebody fork and continue 
doing dtk it self.

originally I've developed it with SDL support but in wayland SDL 
can't get window properties properly. and currently I can't 
continue with dtk right away.
Mar 25 2023
prev sibling next sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Is there general interest in UI within the D community?


As in most fields, I've done my own thing in my minigui.d. My 
general strategy has been on Windows, it uses the native controls 
where possible so things just work there, then the Linux version 
is 100% custom (and almost all self-contained, since I don't 
wanna bring in annoying outside libs).

This has some interesting effects: some surface level things are 
easier to do on linux but the deeper things are... more possible 
but less realistic.

Accessibility is one example, on Windows it mostly just works. I 
tested it with nvda and such, the basic classes - being built on 
native controls - work fine. Custom widgets of course nothing 
yet. On Linux, it just plain doesn't work at all. I expect it'd 
be possible to tie into gtk's api or something but i just have 
zero familiarity with it. I've glanced down the docs, I think I 
can do it, but that's as far as I've gotten.

But doing things myself on linux has also been interesting. I'm 
told that doing per-monitor fractional scaling is completely 
impossible. Gtk does not seem to support it. I do. It wasn't even 
that hard, so I don't get what the fuss is about...

On the other hand, it took me *ages* to get mixed font text 
layout right (and I still haven't done all the bidi stuff yet 
though I'm pretty confident my newer api will work fine for 
it).... and surprisingly, I found getting scroll bars right was a 
huge pain. Maybe that's just me, but between font bugs and scroll 
bugs, my text edit control, well, sure it worked, but it was a 
bit of an embarrassment for *years* on linux. Whereas on Windows, 
of course, it Just Worked from day one thanks to the OS providing 
it.

Then there's the case of the API and this is one place where we 
can innovate a little in D, though I've mostly been keeping it 
actually more-or-less a clone of the web dom api in javascript 
<http://dpldocs.info/experimental-docs/arsd.minigui.Event.html#details>. But a
few fun things like reflecting over a struct to generate accessors that trigger
updates automatically:

http://dpldocs.info/this-week-in-d/Blog.Posted_2020_11_02.html#the-user-side

Or dialog boxes and menus and such pulled out of simple function 
definitions (which I've been doing for websites for... golly 12 
years now lol):

http://dpldocs.info/this-week-in-d/Blog.Posted_2023_01_16.html#batch-programs


Which I've been very happy with sprinkling around, even while 
keeping the core a very traditional oop class set. It is nice 
when you just do like


---
                  menu("&Edit") {
                         void Envelope_Patterns() {
                                 auto e = new Window("Envelope 
Patterns", 70 * 4, 70 * 4);
                                 new EnvelopeChooser(e);
                                 e.show();
                         }

                          accelerator("F1")
                         void Speed_Down() {
                                 auto sid = 
chooser.getSelection()-1;
                                 auto sd = 
editableData.songData(sid, 0);
                                 sd[2] = cast(ubyte) --speed; // 
speed
                                 Update();
                         }

                          accelerator("F2")
                         void Speed_Up() {
                                 auto sid = 
chooser.getSelection()-1;
                                 auto sd = 
editableData.songData(sid, 0);
                                 sd[2] = cast(ubyte) ++speed; // 
speed
                                 Update();
                         }

                 static string lastMidiFile;
                  menu("Track") {
                         void 
Import_From_Midi(FileName!(lastMidiFile, ["Midi 
files\0*.mid;*.midi;*.rmi"]) file) {

              .........
---

and it magically creates the appropriate windows and dialog 
boxes. Or calling a function:

---
         dialog((NewSpecies ns) {
               // use the ns var here
         });
---

saves a bunch of boilerplate.
Mar 25 2023
prev sibling next sibling parent Salih Dincer <salihdb hotmail.com> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Is there general interest in UI within the D community?


Let's start:

https://github.com/rillki/learn-dlang/tree/master

SDB 79
Mar 25 2023
prev sibling next sibling parent reply Ogi <ogion.art gmail.com> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:


 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?


I believe that a really good UI toolkit that would allow writing 
cross-platform, slick-looking, performant applications with nice 
code may be the killer app that D needs.
Mar 25 2023
next sibling parent reply Zealot <no2 no.no> writes:
On Saturday, 25 March 2023 at 13:01:44 UTC, Ogi wrote:

 On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:


 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?


 I believe that a really good UI toolkit that would allow 
 writing cross-platform, slick-looking, performant applications 
 with nice code may be the killer app that D needs.


just use webview2/CEF and Vue.js (or whatever other framework you 
prefer).
fast, easy, coss platform.
bonus: you have a remote/webui.

there's no need to go for anything else unless you are on a 
constrained embedded device imho
Mar 25 2023
parent reply Ogi <ogion.art gmail.com> writes:
On Saturday, 25 March 2023 at 13:11:58 UTC, Zealot wrote:

 On Saturday, 25 March 2023 at 13:01:44 UTC, Ogi wrote:

 just use webview2/CEF and Vue.js (or whatever other framework 
 you prefer).


Everything web-based runs like garbage and uses tons of RAM.
Mar 26 2023
parent reply Zealot <no2 no.no> writes:
On Sunday, 26 March 2023 at 15:56:50 UTC, Ogi wrote:

 On Saturday, 25 March 2023 at 13:11:58 UTC, Zealot wrote:

 On Saturday, 25 March 2023 at 13:01:44 UTC, Ogi wrote:

 just use webview2/CEF and Vue.js (or whatever other framework 
 you prefer).


 Everything web-based runs like garbage and uses tons of RAM.


not if you write proper code. and RAM doesn't really matter much 
on the desktop anyway.
Mar 28 2023
parent reply Dadoum <dadoum protonmail.com> writes:
On Tuesday, 28 March 2023 at 20:39:34 UTC, Zealot wrote:

 On Sunday, 26 March 2023 at 15:56:50 UTC, Ogi wrote:

 On Saturday, 25 March 2023 at 13:11:58 UTC, Zealot wrote:

 On Saturday, 25 March 2023 at 13:01:44 UTC, Ogi wrote:

 just use webview2/CEF and Vue.js (or whatever other framework 
 you prefer).


 Everything web-based runs like garbage and uses tons of RAM.


 not if you write proper code. and RAM doesn't really matter 
 much on the desktop anyway.


If you intend to write a big software, it matters a lot because 
they already require quite a lot of RAM. Look at most 
professional softs, they are native yet takes a big amount of RAM 
(Let's estimate it to 4 GB, for Visual Studio and light usage of 
Adobe software IIRC back when I was on Windows). Then look at 
Electron apps. They are taking a comparable amount of RAM (400 MB 
for Discord ~ 2 GB for Slack), while they offer almost nothing in 
comparison. If you make a web app you are already accepting to 
sacrifice a lot of performance while a native GUI framework would 
probably have allowed more flexibility (taking advantage of 
language features) while being way more efficient in resource.
Mar 28 2023
parent reply Zealot <no2 no.no> writes:
On Tuesday, 28 March 2023 at 21:23:25 UTC, Dadoum wrote:

 On Tuesday, 28 March 2023 at 20:39:34 UTC, Zealot wrote:

 On Sunday, 26 March 2023 at 15:56:50 UTC, Ogi wrote:

 On Saturday, 25 March 2023 at 13:11:58 UTC, Zealot wrote:

 On Saturday, 25 March 2023 at 13:01:44 UTC, Ogi wrote:

 just use webview2/CEF and Vue.js (or whatever other 
 framework you prefer).


 Everything web-based runs like garbage and uses tons of RAM.


 not if you write proper code. and RAM doesn't really matter 
 much on the desktop anyway.


 If you intend to write a big software, it matters a lot because 
 they already require quite a lot of RAM. Look at most 
 professional softs, they are native yet takes a big amount of 
 RAM (Let's estimate it to 4 GB, for Visual Studio and light 
 usage of Adobe software IIRC back when I was on Windows). Then 
 look at Electron apps. They are taking a comparable amount of 
 RAM (400 MB for Discord ~ 2 GB for Slack), while they offer 
 almost nothing in comparison. If you make a web app you are 
 already accepting to sacrifice a lot of performance while a 
 native GUI framework would probably have allowed more 
 flexibility (taking advantage of language features) while being 
 way more efficient in resource.


'a lot of RAM' for systems from 20 years ago. in todays world of 
desktop computers it's really nothing.
also chances are the webui2 is already loaded on a windows 
system, so it will not take up any additional RAM.

in contrast you can ship a webui based D app with 2mb today and 
it will work on windows. QT requires you to also include 100mb of 
dlls, which will also consume memory.

     "If you make a web app you are already  accepting to 
sacrifice a lot of performance" is also simply not true.
     a) i'm not suggesting you write your whole application in js. 
write it in D and only the
      UI part in the browser.
     b) have you ever actually measured it, because in all the 
tests i did, the vue.js UI was actually faster than the native 
(QT and MFC) versions.

"native GUI framework would probably have allowed allowed more 
flexibility", really? how? the webui runs an basically any 
device, remotely. HTML offers a lot more flexibility than 
T-widgets when it comes to customization, and it's 1000times 
simpler. QML is basically the same thing as a webapp, just with 
all the downsides.
Mar 29 2023
parent Adam D Ruppe <destructionator gmail.com> writes:
On Wednesday, 29 March 2023 at 12:25:01 UTC, Zealot wrote:

 in contrast you can ship a webui based D app with 2mb today and 
 it will work on windows.


http://arsd-official.dpldocs.info/arsd.minigui_addons.webview.html

Though on linux it uses CEF which is like a 2 GB download...

My custom browser is made out of one of those in minigui.
Mar 29 2023
prev sibling parent IchorDev <zxinsworld gmail.com> writes:
On Saturday, 25 March 2023 at 13:01:44 UTC, Ogi wrote:

 On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:


 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?


 I believe that a really good UI toolkit that would allow 
 writing cross-platform, slick-looking, performant applications 
 with nice code may be the killer app that D needs.


Absolutely agree. Writing professional software sucks in D. 
Imagine trying to make a competitor to Photoshop (or similar) 
when you're stuck with a bunch of UI libraries focused on game 
development! I've been trying to solve this for myself for a 
while. I thought bindbc-wxWidgets would be nice, but the library 
has so much code in its headers that it's totally unmaintainable. 
GNUStep is a promising option I think.
Apr 11 2023
prev sibling next sibling parent Dadoum <dadoum protonmail.com> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Most of the time I've been a backend engineer. However at times 
 I do need to write an app, and usually I go with Gtk.

 However, I'm a bit concerned that gtk-d seems .. well, 
 catatonic. DWT also appears to be beyond life support.

 We all know Rust has iced-rs, which due to the design of Rust 
 has had to adopt the Elm paradigm.

 D, with features that honestly don't need reiterating, could 
 trivially manage OOP, ECS, mixins...

 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?

 I have a selfish interest in this, hence asking. While spinning 
 a ui toolkit isn't hard, doing it properly can be 
 (accessibility)


I would love to see a UI framework in D, and I came to the same 
conclusion about gtk-d.

That's why I am trying to build one myself. But as you said, 
doing one right is hard, especially for me (someone with very few 
experience in GUI toolkit, and because I chose the hard mode by 
picking Vulkan + Software rendering as the two backends for the 
lib).

I like how the Widget API I wrote looks, but without rendering 
working properly, I can't say my work is very useful.

```d
Application app = new Application("com.dadoum.example", 
ApplicationFlags.unique);

app.activated ~= (args) {
     writefln!("Activated ! (%-(%s %)) %d %s")(args, args.length, 
args[1]);
};

Button btn;
Filter filter;

Window w = new Window("Example")
     .set!(Window.size)(400, 800)
    /+.set!(Window.resizeable)(false)+/ [
     new Stack() [
         new Column() [
             new Paragraph() [
                 "Use ", new 
Link("https://github.com/Dadoum/super_forms", "super_.forms"), " 
!"
             ],
             new Button("click here !").bind!(btn)
         ],
         new Filter()
             .set!(Widget.visible)(false)
             .bind!(filter) [
             new Fixed() [
                 new Text("You clicked !")
                     .set!(Child!Fixed.x)(20)
             ]
         ],
     ]
];

w.closed ~= () => app.exit(0);
w.show();
```
Mar 25 2023
prev sibling next sibling parent Jacob Shtokolov <jacob.100205 gmail.com> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?


I'm pretty sure there is some interest. The only problem is that 
all those UI toolkits are severely outdated and not up to the 
current standards.

IMHO, the current UI standards are dictated by the frontend 
frameworks like React or Vue, and also Flutter (and I'm talking 
about the component-oriented UI).

Rust has another UI library that follows the React functional 
patterns: https://dioxuslabs.com/

Those functional paradigms are also a great fit for D's dip1000 
and the possibility to avoid the GC as all the UI components have 
a deterministic lifecycle makes it a pretty natural choice for 
implementing it in D as well.

If only we could have something like Vue.js (where styling and 
representation are properly defined) and be able to switch 
backends, say, GTK, QT, HTML, etc...

I bet that would be a huge win for the D community!
Mar 25 2023
prev sibling next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 25/03/2023 11:03 PM, Ikey Doherty wrote:

 Is there general interest in UI within the D community? And is there 
 enough to have our own toolkit, or would we be better placed to 
 contribute to the likes of gtk-d?


Absolutely. Many people have tried and done stuff for this.

GUI toolkits are very complex and extremely hard to get right. They are 
not something you should be doing on a whim with the intent of mass 
adoption.

Look at Adam's stuff, its pretty successful and long lasting. Yet it 
doesn't cover all the core requirements to be used by the masses (like 
UI automation for accessibility).

I've been working in some form or another since 2014 to build a fully D 
GUI toolkit and during that time I have had some success but mostly 
failures and an awful lot of iterations.

Right now I'm doing what amounts to a new standard library, -betterC, 
works with shared libraries including with dll's on Windows by dmd. It 
is incredible. It should be a very good solid base to build a GUI 
toolkit upon. It does what I view as everything right. It gets read only 
memory right with data structures for instance and should be very hard 
to get its usage wrong wrt. memory safety.

We have attempted in the past to bring us all together with the graphics 
workgroup, while that has ended, I did utilize an awful lot of the ideas 
from that into my own work.

The reason I'm going so hard on getting the underlying stuff right is 
because we've been doing the exact same thing since early in D1 days. 
Nothing has really stuck. You can see this exact same scenario playing 
out in Rust too.
Mar 25 2023
parent reply Guillaume Piolat <first.last spam.org> writes:
On Sunday, 26 March 2023 at 00:10:42 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 We have attempted in the past to bring us all together with the 
 graphics workgroup, while that has ended, I did utilize an 
 awful lot of the ideas from that into my own work.


Me also in "gamut" library :)
At the times there wasn't a clear way to do fonts, or images, or 
windows.
well for fonts it's still scattered here and there.
It's probably better to make really good libs for those before 
doing an UI, a whole UI is a bit above whan a single person could 
maintain and design.
Mar 26 2023
next sibling parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 27/03/2023 1:13 AM, Guillaume Piolat wrote:

 It's probably better to make really good libs for those before doing an 
 UI, a whole UI is a bit above whan a single person could maintain and 
 design.


I'm giving it a go anyway!



I am seeing a bit of a problem with gamut, its not handling color spaces 
correctly. It appears to currently ignore them, which means if you care 
about correctness or reproducibility its not suitable (and it does not 
mention it).

An example of this is in PNG, there is no gAMA or cHRM chunk handling. 
It would be ok if it would process it into a more expected form (like 
sRGB), but it doesn't do anything like that.

To do this properly means you can't make assumptions which of course is 
super expensive when doing processing. I.e. you need:

https://github.com/Project-Sidero/image/blob/master/colorimetry/sidero/colorimetry/colorspace/rgb/model.d

https://github.com/Project-Sidero/image/blob/master/colorimetry/sidero/colorimetry/colorspace/rgb/srgb.d#L88

Over all its the ideals of gamut are cool, its scope needs slightly 
enlarging tho ;)
Mar 26 2023
parent reply Guillaume Piolat <first.last spam.org> writes:
On Sunday, 26 March 2023 at 13:35:27 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 I am seeing a bit of a problem with gamut, its not handling 
 color spaces correctly.


Absolutely. Need to find a good design for it.
Mar 26 2023
parent reply "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 27/03/2023 5:39 AM, Guillaume Piolat wrote:

 On Sunday, 26 March 2023 at 13:35:27 UTC, Richard (Rikki) Andrew 
 Cattermole wrote:

 I am seeing a bit of a problem with gamut, its not handling color 
 spaces correctly.


 
 Absolutely. Need to find a good design for it.


You've got a real challenge on your hands. I have started again for less 
core changing things.

Here is an example of why I don't think you'll be able to slot it in as-is.

https://github.com/AuburnSounds/gamut/blob/main/source/gamut/image.d#L929

That should be taking in a target colorspace, not a channel 
specification (which is what PixelType is).

If every color space has an intermediary form it understands (i.e. CIE 
XYZ), you can convert it to that and back again easily. I.e.

https://github.com/Project-Sidero/image/blob/master/colorimetry/sidero/colorimetry/pixel.d#L242
Mar 26 2023
parent reply Guillaume Piolat <first.last spam.org> writes:
On Sunday, 26 March 2023 at 17:11:52 UTC, Richard (Rikki) Andrew 
Cattermole wrote:

 https://github.com/Project-Sidero/image/blob/master/colorimetry/sidero/colorimetry/pixel.d#L242


Yes, but you will recognize stb_image.h has that exact same 
semantic too. You can ask for 1/2/3/4 channel while loading. It 
is implicitely rgba8/rgb8/la8/l8, implicitely sRGB.
People care about value and that implicit conversion more than 
they do about colorspaces. So it's not a simple cut wrong vs true.
Mar 26 2023
parent "Richard (Rikki) Andrew Cattermole" <richard cattermole.co.nz> writes:
On 27/03/2023 9:36 AM, Guillaume Piolat wrote:

 People care about value and that implicit conversion more than they do 
 about colorspaces. So it's not a simple cut wrong vs true.


Agreed. You're probably better off making it out of scope instead.

Its a lot of work, its slower and it kinda goes against the trade offs 
you have already picked.
Mar 26 2023
prev sibling parent Adam D Ruppe <destructionator gmail.com> writes:
On Sunday, 26 March 2023 at 12:13:34 UTC, Guillaume Piolat wrote:

 It's probably better to make really good libs for those before 
 doing an UI, a whole UI is a bit above whan a single person 
 could maintain and design.


I do like ten different things that I'm told are too much for a 
single person to do.
Mar 26 2023
prev sibling next sibling parent Guillaume Piolat <first.last spam.org> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?


There is lots of UI or UI parts in development, and interest too, 
but it's the hardest type of library to build (and most valuable).

Two that haven't been mentionned:

* DlangUI: https://github.com/buggins/dlangui, recently revived
   I think there was another fork too with radical changes.

* the new libsoba is planned to replace immediate-mode UI in 
Inochi2D: https://github.com/Inochi2D/libsoba with interstingly a 
WebGPU backend
Mar 26 2023
prev sibling next sibling parent zoujiaqing <zoujiaqing gmail.com> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Most of the time I've been a backend engineer. However at times 
 I do need to write an app, and usually I go with Gtk.

 However, I'm a bit concerned that gtk-d seems .. well, 
 catatonic. DWT also appears to be beyond life support.

 We all know Rust has iced-rs, which due to the design of Rust 
 has had to adopt the Elm paradigm.

 D, with features that honestly don't need reiterating, could 
 trivially manage OOP, ECS, mixins...

 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?

 I have a selfish interest in this, hence asking. While spinning 
 a ui toolkit isn't hard, doing it properly can be 
 (accessibility)


skiad is a binding to mono/SkiaShar.
skiad has a great api.
A UI framework like AvaloniaUI or like Flutter can be created 
based on skiad.
https://github.com/gearui/skiad
Mar 28 2023
prev sibling next sibling parent reply Dejan Lekic <dejan.lekic gmail.com> writes:
On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?

 I have a selfish interest in this, hence asking. While spinning 
 a ui toolkit isn't hard, doing it properly can be 
 (accessibility)


Absolutely!
I use GtkD in one project as it is, at the moment, the best GUI 
toolkit for D.
I would prefer a GUI toolkit entirely done by the D community, 
from scratch (maybe using Adam's simpledisplay as starting point 
idk) with ideas borrowed from JavaFX/Swing and similar.
Mar 28 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Tuesday, 28 March 2023 at 12:04:27 UTC, Dejan Lekic wrote:

 On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?

 I have a selfish interest in this, hence asking. While 
 spinning a ui toolkit isn't hard, doing it properly can be 
 (accessibility)


 Absolutely!
 I use GtkD in one project as it is, at the moment, the best GUI 
 toolkit for D.
 I would prefer a GUI toolkit entirely done by the D community, 
 from scratch (maybe using Adam's simpledisplay as starting 
 point idk) with ideas borrowed from JavaFX/Swing and similar.


DLangUI does almost all of that. But people aren't interested in 
commiting. They are interested in startig from scratch over and 
over again instead.
Mar 29 2023
parent reply Dadoum <dadoum protonmail.com> writes:
On Wednesday, 29 March 2023 at 09:14:55 UTC, GrimMaple wrote:

 DLangUI does almost all of that. But people aren't interested 
 in commiting. They are interested in startig from scratch over 
 and over again instead.


I tried to use DlangUI to potentially contribute to it. But there 
are some design choices that turned me off personally.

The API is very inspired of Android UI, which makes it very 
verbose with explicit layouts (I have a GTK+ background, so I 
struggle to understand how layouts work in general).

The UI is usually built with a custom format in a string, so if 
it has an error you will have to wait for the code to compile and 
run to see it.

Backends are made of one big file, and I didn't understand how 
you can add one (I wanted Wayland support).

Renderers are also inside each backend, so adding support for 
Vulkan would probably imply adding more duplicated code in every 
backend or move some code in a new module.

Before last year, there was nobody to help me figure out how 
everything works so I gave up and started my own thing, but I 
would love to help and improve the project now.
Mar 29 2023
parent reply GrimMaple <grimmaple95 gmail.com> writes:
On Wednesday, 29 March 2023 at 09:54:35 UTC, Dadoum wrote:

 On Wednesday, 29 March 2023 at 09:14:55 UTC, GrimMaple wrote:

 DLangUI does almost all of that. But people aren't interested 
 in commiting. They are interested in startig from scratch over 
 and over again instead.


 I tried to use DlangUI to potentially contribute to it. But 
 there are some design choices that turned me off personally.

 The API is very inspired of Android UI, which makes it very 
 verbose with explicit layouts (I have a GTK+ background, so I 
 struggle to understand how layouts work in general).

 The UI is usually built with a custom format in a string, so if 
 it has an error you will have to wait for the code to compile 
 and run to see it.

 Backends are made of one big file, and I didn't understand how 
 you can add one (I wanted Wayland support).

 Renderers are also inside each backend, so adding support for 
 Vulkan would probably imply adding more duplicated code in 
 every backend or move some code in a new module.

 Before last year, there was nobody to help me figure out how 
 everything works so I gave up and started my own thing, but I 
 would love to help and improve the project now.


There are countless issues with dlangui, but so far it was the 
most pleasent experience of writing real-life GUI applications in 
D. My nearest example is 
https://github.com/GrimMaple/mwverify/blob/main/source/app.d , a 
fully functional UI app in 65 LOC with no external dependencies 
(only system deps on Windows and Linux). I also think DLangUI 
needs a lot of refactoring to extract as much stuff into separate 
modules as possible. Contributions are welcome, I usually review 
them as soon a I have free time.
Mar 29 2023
parent Salih Dincer <salihdb hotmail.com> writes:
On Wednesday, 29 March 2023 at 10:48:46 UTC, GrimMaple wrote:

 
 There are countless issues with dlangui, but so far it was the 
 most pleasent experience of writing real-life GUI applications 
 in D.


I liked dlangui too, so what kind of bugs did you run into?

SDB 79
Mar 29 2023
prev sibling parent reply sai <sai tmp.com> writes:
I have been using DWT since last 10 years. I think it has the 
perfect combination of features for my needs. Its in maintenance 
mode now but still works.

* no large dll dependencies, compiles to a single small exe on 
windows
* default looks OK and very good customizability w/o any bugs
* fast compilation
* being from java background, almost no learning curve.
* eclipse GUI builder can help to find the function calls that I 
need to use to make a specific ui.

I wish more people work on it and keep it up-to-date. :-)

But if something can be done in Dlang, will be lovely.
Wish DlangUi took off and become more mature.


On Saturday, 25 March 2023 at 10:03:29 UTC, Ikey Doherty wrote:

 Most of the time I've been a backend engineer. However at times 
 I do need to write an app, and usually I go with Gtk.

 However, I'm a bit concerned that gtk-d seems .. well, 
 catatonic. DWT also appears to be beyond life support.

 We all know Rust has iced-rs, which due to the design of Rust 
 has had to adopt the Elm paradigm.

 D, with features that honestly don't need reiterating, could 
 trivially manage OOP, ECS, mixins...

 Is there general interest in UI within the D community? And is 
 there enough to have our own toolkit, or would we be better 
 placed to contribute to the likes of gtk-d?

 I have a selfish interest in this, hence asking. While spinning 
 a ui toolkit isn't hard, doing it properly can be 
 (accessibility)
Mar 31 2023
parent reply Daniel Kozak <kozzi11 gmail.com> writes:
https://slint-ui.com/blog/announcing-slint-1.0.html

This seems to be perfect gui lib and should be possible to use it with Dlang
Apr 04 2023
next sibling parent zjh <fqbqrr 163.com> writes:
On Tuesday, 4 April 2023 at 09:25:37 UTC, Daniel Kozak wrote:

 https://slint-ui.com/blog/announcing-slint-1.0.html

 This seems to be perfect gui lib and should be possible to use 
 it with Dlang



It seems that the LICENSE is not friendly.
Apr 04 2023
prev sibling parent reply ryuukk_ <ryuukk.dev gmail.com> writes:
On Tuesday, 4 April 2023 at 09:25:37 UTC, Daniel Kozak wrote:

 https://slint-ui.com/blog/announcing-slint-1.0.html

 This seems to be perfect gui lib and should be possible to use 
 it with Dlang


rust + c++ 🤮

Here a C one, easier to integrate with D, and doesn't have a 
separate Slint scripts

https://lvgl.io/

https://github.com/lvgl/lvgl

Works on everything including baremetal, so perfect for -betterC 
usage too
Apr 04 2023
parent reply Zz <Zz zz.com> writes:
Here is another one.

https://nappgui.com/en/home/web/home.html

Windows, Mac and GTK.

Zz
Apr 09 2023
parent zjh <fqbqrr 163.com> writes:
On Sunday, 9 April 2023 at 13:33:36 UTC, Zz wrote:

 Here is another one.

 https://nappgui.com/en/home/web/home.html

 Windows, Mac and GTK.

 Zz


Feels good, could anyone create a D binding for it?
Apr 09 2023