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.

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.

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.