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