Jump to page: 1 27  
Page
Thread overview
November 19
There's been attempts to implement a native D GUI toolkit but it seems none gets community attention. The closets...DlangUI (https://code.dlang.org/packages/dlangui)... seems no more under active development...getting to a year now.

Ketmar and others have been in the talks about doing something towards that. Whats happening now? What's holding 100% D GUI back?
November 19
On Tuesday, 19 November 2019 at 22:57:47 UTC, aberba wrote:
> There's been attempts to implement a native D GUI toolkit but it seems none gets community attention. The closets...DlangUI (https://code.dlang.org/packages/dlangui)... seems no more under active development...getting to a year now.
>
> Ketmar and others have been in the talks about doing something towards that. Whats happening now? What's holding 100% D GUI back?

I've seen some C++ GUI attempts getting some success with few people working on them.

http://nanapro.org/en-us/

https://google.github.io/flatui/ ...By Google...can't say few devs though

https://github.com/vurtun/nuklear

https://github.com/ocornut/imgui
November 19
On 11/19/19 5:57 PM, aberba wrote:
> There's been attempts to implement a native D GUI toolkit but it seems none gets community attention. The closets...DlangUI (https://code.dlang.org/packages/dlangui)... seems no more under active development...getting to a year now.

Last commit was in August, so not quite dead, but I'd say that's your best shot at something. Seems pretty legit.

Having been around for the growth of gtk from GIMP to replace the X/Motif UI, I'd say it's quite a feat to have something working as well as DLangUI with the time/manpower there.

If I were to create a GUI-based app (I haven't in a long time), I'd probably look there.

-Steve
November 20
On Tuesday, 19 November 2019 at 22:57:47 UTC, aberba wrote:
> Ketmar and others have been in the talks about doing something towards that. Whats happening now? What's holding 100% D GUI back?

I already have a 100% D gui in my libs.... just it isn't 100% complete because I haven't had the real need to continue working on it. Been doing a lot of web uis instead of desktop, but I'll keep working on it... very slowly.
November 20
For 100% D GUI toolkit, we would need somebody who is knowledgeable on Unicode (text layouting e.g. Bidi) and font rasterization. These together are many a man year projects and quite massive.

But more realistically with using e.g. FreeType and HarfBuzz:

- Image library (started)
- Event loop (next on my list to do)
- Windowing
- Render pipeline
- Text rendering (part of render pipeline sort of)
- Widget rendering (I'm doing requirements gathering atm)
- Theme management (CSS-like + reloading + widget renderer + text rendering)
- UI automation
- Controls

So yeah, lots of stuff.

For reference: https://github.com/DlangGraphicsWG
We wanted to get something actually working before making an announcement (we rely quite heavily on Manu for image library/render pipeline parts and he has been busy most of this year).

Our discussions are on Discord.

Here is an old image that I generated from my experimenting with widget rendering: https://cdn.discordapp.com/attachments/522751717780094979/634557892556750878/Capture.PNG
November 20
On Tuesday, 19 November 2019 at 23:25:12 UTC, aberba wrote:
> I've seen some C++ GUI attempts getting some success with few people working on them.

They all look like they are cool projects, but most of them seem to be immediate mode (low level graphics is pushed to the screen more or less directly). So I would imagine that they are mostly useful for simple GUIs or require more programmer effort than you get from typical retained mode GUI framworks.

Anyway, is it really important that all the code is in D?  If so, why not port a retained mode framework that already exists? Like Skia/Flutter.

Keep in mind that:

1.  GUI APIs have to change constantly to stay competitive. Apple recently changed their API to Swift UI, which is more declarative than the previous API (like some Web UI frameworks). A rather big change IMO.

2. OS/Hardware vendors quickly change graphics interfaces. E.g. OpenGL is no longer a thing on Apple, so you need a separate Metal engine.

You need a team of at least 10 skilled people that make it their primary hobby to stay relevant. Porting seems a much more likely option if the goal is to have something that is useful for production.


> https://github.com/vurtun/nuklear

Appears to have D bindings, though.

November 20
On Tuesday, 19 November 2019 at 23:25:12 UTC, aberba wrote:
> http://nanapro.org/en-us/

Thanks for sharing btw, I've now looked a bit more closely at the C++ GUIs you mentioned, and Nana seems to be the only one of these 4 that that attempts to be a UI framework, and it appears to be slow moving and a bit weird. So it has a long way to go before taking on the alternatives (gtk etc).

These:

> https://google.github.io/flatui/
> https://github.com/vurtun/nuklear
> https://github.com/ocornut/imgui

seems to require you to build your own graphics/input handling... which can be a lot of work if you don't have one already (i.e. mostly for games).  Dear ImGUI appears to receive some financial backing from game studios/Google. FlatUI is backed by Google.

I guess you could port Dear ImGUI to D, might be a good idea actually, but you would still be a long way from writing your own GUI application.

November 20
On Wednesday, 20 November 2019 at 07:52:47 UTC, Ola Fosheim Grøstad wrote:
> some financial backing from game studios/Google. FlatUI is backed by Google.

Having done a bit more research it appears that being supported by Google isn't enough. FPLbase which FlatUI is using for rendering does not seem to receive much love. But I found this fork:

https://github.com/LukasBanana/LLGL

Which might be a low level alternative worth evaluating if Skia is considered to be too high level.

So there are interesting things going on, and it is moving relatively fast. I think it would be a grave mistake to not build on what is done with C/C++ at the lower level layers because maintenance is just too expensive when you don't have a really large pool of applications building on it.

However, even with LLGL behind you, look at all the code you need to just display one gradient-shaded triangle on screen:

https://github.com/LukasBanana/LLGL/tree/master/examples/Cpp/HelloTriangle

Clearly... you want to stand on the shoulders of others to get a portable graphics layer rather than rolling all on your own.

November 20
On Wednesday, 20 November 2019 at 07:52:47 UTC, Ola Fosheim Grøstad wrote:
> On Tuesday, 19 November 2019 at 23:25:12 UTC, aberba wrote:
>> http://nanapro.org/en-us/
>
> Thanks for sharing btw, I've now looked a bit more closely at the C++ GUIs you mentioned, and Nana seems to be the only one of these 4 that that attempts to be a UI framework, and it appears to be slow moving and a bit weird. So it has a long way to go before taking on the alternatives (gtk etc).
>
> These:
>
>> https://google.github.io/flatui/
>> https://github.com/vurtun/nuklear
>> https://github.com/ocornut/imgui
>
> seems to require you to build your own graphics/input handling... which can be a lot of work if you don't have one already (i.e. mostly for games).  Dear ImGUI appears to receive some financial backing from game studios/Google. FlatUI is backed by Google.
>
> I guess you could port Dear ImGUI to D, might be a good idea actually, but you would still be a long way from writing your own GUI application.

Flatui like many things Google is abandonware.

It never went anywhere beyond a couple of NDK game samples.

November 20
On Wednesday, 20 November 2019 at 08:22:53 UTC, Paulo Pinto wrote:
> Flatui like many things Google is abandonware.
>
> It never went anywhere beyond a couple of NDK game samples.

FlatUI has not received updates in 2 years, the underlying layer received an update 6 months ago. It is quite minimal, but there are some ideas in there that one can borrow.

As far as C++ goes, I think there will be opportunities for much better UI APIs when stackless coroutines become available... but it will probably take a decade for library developers to figure out how to make good use of it.

« First   ‹ Prev
1 2 3 4 5 6 7