November 20, 2019
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?

There's DWT [1]. But it doesn't currently get any updates besides from make sure it works on the latest compiler.

One of the issues is that some will prefer a native GUI that follows the conventions on a given platform and looks and behaves slightly different across the supported platforms. But  some will prefer a non-native custom GUI that looks the same on all platforms.

There might not be enough people in the community that are interested in implementing GUI applications.

[1] https://github.com/d-widget-toolkit/dwt

--
/Jacob Carlborg
November 20, 2019
On Wednesday, 20 November 2019 at 04:29:18 UTC, rikki cattermole wrote:
> 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).

Did you consider taking your color type (excellent work by the way) and making a mir.ndslice out of it? You would basically have an efiicient bitmap type with bells and whistles with no effort required on your part.
November 21, 2019
On 21/11/2019 2:14 AM, Dukc wrote:
> On Wednesday, 20 November 2019 at 04:29:18 UTC, rikki cattermole wrote:
>> 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).
> 
> Did you consider taking your color type (excellent work by the way) and making a mir.ndslice out of it? You would basically have an efiicient bitmap type with bells and whistles with no effort required on your part.

Most of the work on the image library has been done by Manu.

The rest of us, did help come up with the requirements.

https://github.com/DlangGraphicsWG/documents/blob/master/image.md
https://github.com/DlangGraphicsWG/documents/blob/master/rgb-format.md

No, we did not consider supporting libraries likes ndslice as a dependency of the 'core' image library.
The goal was to make ImageBuffer work with graphic API's like OpenGL directly and to make it be able to be used as wide spread as possible.

https://github.com/DlangGraphicsWG/image/blob/master/src/wg/image/imagebuffer.d#L17

Mutation on the CPU is a much more rare thing in practice for game development + GUI's so it isn't a requirement.
November 21, 2019
On Wednesday, 20 November 2019 at 09:05:50 UTC, Jacob Carlborg wrote:
> 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?
>
> There's DWT [1]. But it doesn't currently get any updates besides from make sure it works on the latest compiler.
>
> One of the issues is that some will prefer a native GUI that follows the conventions on a given platform and looks and behaves slightly different across the supported platforms. But  some will prefer a non-native custom GUI that looks the same on all platforms.
>
> There might not be enough people in the community that are interested in implementing GUI applications.
>
> [1] https://github.com/d-widget-toolkit/dwt
>
> --
> /Jacob Carlborg

Now there's rarely the need to get it to work with platform widget across all platform. They get more different by the day.

I think it's better to have only some common custom drawn widges (like how Material UI works) and make it flexible to build third party custom widgets and styling. Community/users will take care of the rest...including third party components/widget for both Mobile and desktop
November 21, 2019
On Thursday, 21 November 2019 at 12:53:42 UTC, aberba wrote:
> Now there's rarely the need to get it to work with platform widget across all platform. They get more different by the day.

That really depends on what a customer asks for... So you might not need platform widgets (because non-tech people care about the experience, not the tech), but they might requires similar look and behaviour.

GUI toolkits that emulate platform look and feel tend to be more popular.


> I think it's better to have only some common custom drawn widges (like how Material UI works) and make it flexible to build third party custom widgets and styling.

I view Material as a platform GUI-design. They make it available on many platforms... Just like GTK was a platform GUI-design, then made it available on many platforms.  That makes GTK unappealing for many devs. And let's be honest, GTK applications look outdated today.

Google will at some point drop Material, and then all apps that use it will look out-of-style... and you'll need a major rewrite.  I'll give Material 3-5 years.


> Community/users will take care of the rest...including third party components/widget for both Mobile and desktop

Sadly, individuals tend to «creatively» break basic UI guidelines when given the opportunity based on their very personal preferences. To get something consistent you need a disciplined team that follow strict and comprehensive guidelines.

Which is why good GUI toolkits are rare... very rare.

November 21, 2019
On 2019-11-19 22:57:47 +0000, aberba said:

> ... Whats happening now? What's holding 100% D GUI back?

Nothing, so why don't you do one?

We are developing a GUI framework in D for our product. But, the framework is only a menas to an end. And, the focus is on the stuff we need, not to create a ready-to-use-everyone-will-love-it framework.

I bet the ratio is 1:50 for dev-power:feedback-power for such projects in the public => If you want to get things done, you need to do it in a small closed group.

If you want to go public, you need to have a level that others can take it and use it. Otherwise you are wasting a lot of capacity with a lot of wishes but low support.

Anyway, here is a shor teaser:

https://www.dropbox.com/s/57s19lj0xzr7sqo/Bildschirmaufnahme%202019-11-21%20um%2022.38.37.mov 


Mihgt not look like a lot, but everything is already working, so focusing on more basic widgets. And after this we do decoration (a bit) and BTW we can do font rendering too already.

-- 
Robert M. Münch
http://www.saphirion.com
smarter | better | faster

November 26, 2019
On Wednesday, 20 November 2019 at 04:29:18 UTC, rikki cattermole wrote:
> 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.

That's the problem - basically all of it is already there in DLangUI, it's done, complete, working, and has been for a few years. But programmers being programmers, prefer ignoring existing libraries and keep reimplementing the same stuff from scratch. In most cases it doesn't go too far, as the steam dries out. In some cases it does go far, we get one more UI library that nobody uses, and instead other people reimplement the same from scratch and keep asking what's holding us back... It's a cultural thing, I guess. ;)

November 27, 2019
On 27/11/2019 1:01 AM, thedeemon wrote:
> On Wednesday, 20 November 2019 at 04:29:18 UTC, rikki cattermole wrote:
>> 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.
> 
> That's the problem - basically all of it is already there in DLangUI, it's done, complete, working, and has been for a few years. But programmers being programmers, prefer ignoring existing libraries and keep reimplementing the same stuff from scratch. In most cases it doesn't go too far, as the steam dries out. In some cases it does go far, we get one more UI library that nobody uses, and instead other people reimplement the same from scratch and keep asking what's holding us back... It's a cultural thing, I guess. ;)
> 

Things it does not have:

- Event loop
- Windowing (screenshots, notification messages, system tray)
- Render pipeline is from AAA games, the only person I trust with designing it is Manu
- UI automation (if you don't have this you can literally be sued and that ignores the customers you will loose and bad press in general)

Event loop, while it does exist you can't hook into it. See glib's event loop to see something *actually* acceptable.

Theme management is mostly there, not quite what I would suggest, but it is there.
November 26, 2019
On Tuesday, 26 November 2019 at 12:15:57 UTC, rikki cattermole wrote:
> - Windowing (screenshots, notification messages, system tray)
> - Render pipeline is from AAA games, the only person I trust with designing it is Manu
> - UI automation (if you don't have this you can literally be sued and that ignores the customers you will loose and bad press in general)
>
> Event loop, while it does exist you can't hook into it. See glib's event loop to see something *actually* acceptable.
>
> Theme management is mostly there, not quite what I would suggest, but it is there.

Ok, fair points, sorry for the rant. Meanwhile for those with less strict demands, please don't be afraid to use the UI libraries that are not in active development. It might just indicate all the things original author wanted are already there.
November 27, 2019
On 27/11/2019 2:23 AM, thedeemon wrote:
> On Tuesday, 26 November 2019 at 12:15:57 UTC, rikki cattermole wrote:
>> - Windowing (screenshots, notification messages, system tray)
>> - Render pipeline is from AAA games, the only person I trust with designing it is Manu
>> - UI automation (if you don't have this you can literally be sued and that ignores the customers you will loose and bad press in general)
>>
>> Event loop, while it does exist you can't hook into it. See glib's event loop to see something *actually* acceptable.
>>
>> Theme management is mostly there, not quite what I would suggest, but it is there.
> 
> Ok, fair points, sorry for the rant. Meanwhile for those with less strict demands, please don't be afraid to use the UI libraries that are not in active development. It might just indicate all the things original author wanted are already there.

I understand.

Its important to put into context the general case for a GUI and a small subset of usages for it.