D language for Graphical User Interface and Cross Platform Development

c-smile andrew at sciter.com
Sun Jun 28 18:01:08 UTC 2020


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.




More information about the Digitalmars-d mailing list