On 24/06/2020 12:17 AM, aberba wrote:
> On Tuesday, 23 June 2020 at 07:51:57 UTC, Suliman wrote:
>> There is also https://github.com/dayllenger/beamui
> 
> Seriously,this is it.
> 
> Its checks in just about everything would like a D GUI to have. Especially CSS-like styling and slimming things down.
> 
> Thanks for sharing

There is no dedicated event loop or windowing library underpinning it.

Unfortunately this means that GtkD is still a better option.

On Tuesday, 23 June 2020 at 16:28:26 UTC, rikki cattermole wrote:
> On 24/06/2020 12:17 AM, aberba wrote:
>> On Tuesday, 23 June 2020 at 07:51:57 UTC, Suliman wrote:
>>> There is also https://github.com/dayllenger/beamui
>> 
>> Seriously,this is it.
>> 
>> Its checks in just about everything would like a D GUI to have. Especially CSS-like styling and slimming things down.
>> 
>> Thanks for sharing
>
> There is no dedicated event loop or windowing library underpinning it.
>
> Unfortunately this means that GtkD is still a better option.

"PRs are welcome" :P

On Tuesday, 23 June 2020 at 16:28:26 UTC, rikki cattermole wrote:
> ...
> Unfortunately this means that GtkD is still a better option.

Why is that _unfortunate_?

On Tuesday, 23 June 2020 at 16:28:26 UTC, rikki cattermole wrote:
> On 24/06/2020 12:17 AM, aberba wrote:
>> On Tuesday, 23 June 2020 at 07:51:57 UTC, Suliman wrote:
>>> There is also https://github.com/dayllenger/beamui
>> 
>> Seriously,this is it.
>> 
>> Its checks in just about everything would like a D GUI to have. Especially CSS-like styling and slimming things down.
>> 
>> Thanks for sharing
>
> There is no dedicated event loop or windowing library underpinning it.
>
> [...]

it's using SDL, X11 or Win32, waiting for messages using the platform specific event loops there. Where did you get your assumption there from or what do you mean if you don't mean these event loops but some other event loop?

On 25/06/2020 2:09 AM, WebFreak001 wrote:
> On Tuesday, 23 June 2020 at 16:28:26 UTC, rikki cattermole wrote:
>> On 24/06/2020 12:17 AM, aberba wrote:
>>> On Tuesday, 23 June 2020 at 07:51:57 UTC, Suliman wrote:
>>>> There is also https://github.com/dayllenger/beamui
>>>
>>> Seriously,this is it.
>>>
>>> Its checks in just about everything would like a D GUI to have. Especially CSS-like styling and slimming things down.
>>>
>>> Thanks for sharing
>>
>> There is no dedicated event loop or windowing library underpinning it.
>>
>> [...]
> 
> it's using SDL, X11 or Win32, waiting for messages using the platform specific event loops there. Where did you get your assumption there from or what do you mean if you don't mean these event loops but some other event loop?

SDL is the only backend that is capable of you interacting with the event loop itself in a meaningful way.

However it wasn't designed for the majority of use cases, a very narrow set. While useful, it has significant limitations.

Being able to wait and get system windowing library events is always required and each backend is capable of doing that. But that doesn't mean it'll play nicely with threads, shared libraries (like X11) or other event loops.

On Wednesday, 17 June 2020 at 10:33:36 UTC, BoQsc wrote:
> It seems that by using gtkd project to build your GUI application it requires a preinstalled runtime that weights around 40mb, for Windows operating systems. (https://gtkd.org/download.html)
>
> A Dlang UI GUI project by Buggins seems to be deprecated and even a simple example could not be run anymore. (https://github.com/buggins/dlangui)
>
> I'm not aware of any other serious project that could efficiently provide a way to build a stable GUI.
>
> What should I do if I want to write a cross-platform application with graphical user interface in D? Should I wait until there will be better maintained libraries listed on the (https://wiki.dlang.org/GUI_Libraries) or there are other ways to create and build a GUI D language application?

What about Sciter ?

Site: https://sciter.com/

D: https://github.com/sciter-sdk/Sciter-Dport

On 2020-06-25 03:33:23 +0000, Виталий Фадеев said:

> What about Sciter ?
> 
> Site: https://sciter.com/
> 
> D: https://github.com/sciter-sdk/Sciter-Dport

It looks interesting but I never tried it. Any experience with it?

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

On Thursday, 25 June 2020 at 20:42:25 UTC, Robert M. Münch wrote:
> On 2020-06-25 03:33:23 +0000, Виталий Фадеев said:
>
>> What about Sciter ?
>> 
>> Site: https://sciter.com/
>> 
>> D: https://github.com/sciter-sdk/Sciter-Dport
>
> It looks interesting but I never tried it. Any experience with it?

Sciter's author here.

Sciter API is pretty compact, it is exposed from sciter.dll as a structure ( https://github.com/c-smile/sciter-sdk/blob/master/include/sciter-x-api.h#L50 )
and normally application use 20-30 functions of it. Sciter is perfectly suitable for D. D integration was one of design targets from the very beginning.

Below is slightly orthogonal to the question, just thoughts, my pardon.

Just in case, initially Sciter was meant to be written in D. Here is the story: https://sciter.com/10-years-road-to-sciter/

I still think that among native languages D lang is the most suitable one for GUI development. GC is the must for UI if to consider complex ownership graphs that frequently contain loops.

Having said that, it is possible but quite hard to make an embeddable/shared (to other systems) GUI engine in D, for very same reason as the above. The most feasible approach, I think, is along the lines of my Quark project ( https://quark.sciter.com ) - self- sufficient executables that contain GUI engine linked statically.

If to consider a "perfect and modern D GUI library":

1. It should have unified DOM serializable to HTML/XHTML. There are many good reasons for that, from Accessibility (a.k.a. Section 508), to things like enabling React alike functionality and JSX. D syntax may even support JSX natively in the way I did in Sciter's script: https://sciter.com/docs/content/script/language/ssx.htm

2. It should be style-able, so is CSS or its subset. It is again flexible and 95% UI developers know it already. Style-ability here means not just colors but flexibility and configurability of element flows (layout manager in Java AWT terms).

3. It shall use GPU rendering as much as possible. That's the must for high-DPI monitors.

4. Implementation shall be compact - each D GUI application will include it statically and compilations time shall be short.

Please let me know if someone will start doing anything close to the the above in D - I can help.

On Sunday, 28 June 2020 at 18:01:08 UTC, c-smile wrote:
> On Thursday, 25 June 2020 at 20:42:25 UTC, Robert M. Münch wrote:
>> [...]
>
> Sciter's author here.
>
> [...]

You may check out BeamUI written in 100% D. It's the closest I've seen to what you may be talking about.

https://github.com/dayllenger/beamui

On 2020-06-28 18:01:08 +0000, c-smile said:

> Sciter's author here.

Hi Andrew, thank for jumping-in.

> Sciter API is pretty compact, it is exposed from sciter.dll as a structure ( https://github.com/c-smile/sciter-sdk/blob/master/include/sciter-x-api.h#L50 ) and normally application use 20-30 functions of it. Sciter is perfectly suitable for D. D integration was one of design targets from the very beginning.

I didn't know that D was taken into account for Sciter nor that it's well suited to work with D. Might be a good addition to your web-page (if it's not already there and I overlooked it).

So, this means, that all the embedding principals work with D too?

> Just in case, initially Sciter was meant to be written in D. Here is the story: https://sciter.com/10-years-road-to-sciter/

Oh, cool. Again, if this thing is so good integrated with D, that should be made more public.

> I still think that among native languages D lang is the most suitable one for GUI development. GC is the must for UI if to consider complex ownership graphs that frequently contain loops.

I agree... it feels very natural to do such frameworks in D.

> Having said that, it is possible but quite hard to make an embeddable/shared (to other systems) GUI engine in D, for very same reason as the above. The most feasible approach, I think, is along the lines of my Quark project ( https://quark.sciter.com ) - self- sufficient executables that contain GUI engine linked statically.

That's a very interesting thing! I have some questions:

* Our goals is to create a zero-dependency standalone EXE application. As I read this, this is possible? We would have additional D/C code we want to all "link" statically.

* Does quark does anything against reverse engineering? I mean, all the script stuff is very nice, but we have to be sure, things are not changed, extracted, etc.

* Is the scriping engine, which seems to be genuinly done from scratch, fully JS compatible? Or how does it fit into the overall web-stack space? Can exteranl frameworks be used, too? Or do these need some Sciter specific adjustments?

> If to consider a "perfect and modern D GUI library":
> 
> 1. It should have unified DOM serializable to HTML/XHTML. There are many good reasons for that, from Accessibility (a.k.a. Section 508), to things like enabling React alike functionality and JSX. D syntax may even support JSX natively in the way I did in Sciter's script: https://sciter.com/docs/content/script/language/ssx.htm

I always see two parts:

1. The "how to code it" part, which should use a declarative DSL that integrates with the rest of the D application code pretty simple and without any friction. If there HTML/CSS/JS is the best combo, could be discussed. At the end of the day, I think this is all more about taste than technological superiority.

2. The "how to display" part. I prefer to have a GUI toolkit, that doesn't use any native widgets, instead just renders the stuff the app needs. I want access from high-level abstraction to low-levels, so I can get in between and do whatever is required for my app.

> 2. It should be style-able, so is CSS or its subset. It is again flexible and 95% UI developers know it already. Style-ability here means not just colors but flexibility and configurability of element flows (layout manager in Java AWT terms).

Agree, again, if this is CSS or something else, can be discussed. But of course you are right, that more and more people know this CSS stuff, it doesn't make a lot of sense to reinvent the wheel.

> 3. It shall use GPU rendering as much as possible. That's the must for high-DPI monitors.

Yes. Or have a very sophisticated, hight speed sofware renderer.

> 4. Implementation shall be compact - each D GUI application will include it statically and compilations time shall be short.

Yep!

> Please let me know if someone will start doing anything close to the the above in D - I can help.

I might turn this the other way and take a deeper look into what you have. Beside, doing a GUI library is a fun project, I have a clear business use-case behind it.

Going to PM you for more details, that might not be that interesting for the community.

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