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.
>
> [...]

We toyed with Armonia a lot, I remember the DOM tree was stored in a single dynamic array, with function to traverse it ...

It was a really cool framework!

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:
>> 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.
>
>
> 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.

I do.
Everything goes well.

1. HTML will be later, JSX not planned.
Idea is to use native D language.
Like this:

void main()
{
    with ( new App )
    {
        with ( CR!Screen )
        {
            with ( CR!Window )
            {
                with ( CR!Element )
                {
                    classes ~= "row";

                    with ( CR!Element )
                    {
                        classes ~= "c1/3 menu";
                    }

                    with ( CR!Element )
                    {
                        classes ~= "c2/3 search center";
                    }

                    with ( CR!Element )
                    {
                        classes ~= "c3/3 indicators right";
                    }
                }

                with ( CR!Element )
                {
                    classes ~= "row";

                    with ( CR!Element )
                    {
                        classes ~= "c1/1 video center";
                    }
                }
            }
        }
    }
}

2. CSS, of course :)

There will be a function for style.
And destylization.
Like this:

    struct Style
    {
        string    className;
        CHECKER[] checkers;
        STYLER    styler;
        UNSTYLER  unstyler;

        uint weight;
    }

using:

    styles ~= new Style( "row", [], ( ElementStyled* element ) {
        element.width = "parent";
    });

And CSS. How we all love.
Like this:

.row {
    width: 100%;
}


3. Windows GDI as main concept. For using on Android will be OpenGL.

Will be surface backend. Like this:

interface ISurface
{
    void BeginPaint ( );
    void RelArea    ( AREA relArea );
    void AbsArea    ( AREA absArea );
    void Path       ( POINT[] points );
    void Color      ( COLOR color );
    void Style      ( LINE_STYLE style );
    void Weight     ( WEIGHT weight );
    void Font       ( FONT font );
    void Fill       ( );
    void Stroke     ( );
    void MoveTo     ( int x, int y );
    void LineTo     ( int x, int y );
    void AngleArc   ( int cx, int cy, int r, float startAngle, float sweepAngle, int direction );
    void Char       ( wchar c );
    void Text       ( string text );
    void Image      ( Image image );
    void EndPaint   ( );
}

This is past version. Now I think it will be easier Screen / Window / GPU-Backend.

I want keep small Node / Element. And want to use Window as Element in DocTree.
It will be beautiful. and I want to keep the principle of similarity.

4. Here we have: clibs + D runtime + Phobos. We’ll come up with something later...


I want beauty & fast Windows Shell!
I want beauty & fast Windows Open/Save/Select folder dialogs!
I want beauty & fast Windows file manager!
I want beauty & fast Windows applications!
I want beauty & fast & usable Android Offline Maps!
And I love Linux & I want also on Linux!
)

On Monday, 29 June 2020 at 13:14:04 UTC, Виталий Фадеев wrote:
> On Sunday, 28 June 2020 at 18:01:08 UTC, c-smile wrote:
>>[...]
>
>> [...]
>
> I do.
> Everything goes well.
>
> [...]

This reads pretty awesome.

On Monday, 29 June 2020 at 13:14:04 UTC, Виталий Фадеев wrote:
> 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:
>>> 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.
>>
>>
>> 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.
>

In first version was GC. It gived many time for experiments. GC take on self dirty work.
Now Node/Element will like this:

struct Node
{
    Node* parent;
    Node* firstChild;
    Node* lastChild;
    Node* prev;
    Node* next;
}


struct Element
{
    Node node;

    alias node this;

    //
    Properties props; // Element properties
    Properties style; // Style properties

    //
    Computed computed;  // <-- after Apply Style and Update. Initial Properties + Style Properties + Element Properties

    //
    Node* g; // Window

    //
    Eventer!( MouseEvent ) onMouseMove;
    Eventer!( MouseEvent ) onMouseButton;
    Eventer!( KeyEvent   ) onKey;
    Eventer!( ClickEvent ) onClick;
    Eventer!( SizeEvent  ) onResize;

    //
    uint updateStamp;
}

Robert ( c-smile ),
1. How you see best Node / Element structure ?

On Monday, 29 June 2020 at 00:04:31 UTC, aberba wrote:
> 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

Very interesting project and tremendous amount of work, my deepest regards.

thanks a lot for the link.

On Monday, 29 June 2020 at 14:34:45 UTC, Виталий Фадеев wrote:

> Now Node/Element will like this:
>
> struct Node
> {
>     Node* parent;
>     Node* firstChild;
>     Node* lastChild;
>     Node* prev;
>     Node* next;
> }
>
>
> struct Element
> {
>     Node node;
>
>     alias node this;
>
>     //
>     Properties props; // Element properties
>     Properties style; // Style properties
>
>     //
>     Computed computed;  // <-- after Apply Style and Update. Initial Properties + Style Properties + Element Properties
>
>     //
>     Node* g; // Window
>
>     //
>     Eventer!( MouseEvent ) onMouseMove;
>     Eventer!( MouseEvent ) onMouseButton;
>     Eventer!( KeyEvent   ) onKey;
>     Eventer!( ClickEvent ) onClick;
>     Eventer!( SizeEvent  ) onResize;
>
>     //
>     uint updateStamp;
> }
>
> Robert ( c-smile ),
> 1. How you see best Node / Element structure ?


Best Node/Element structure is debatable and depends on design goals.

Here is Sciter's DOM tree representation

struct node: resource // reference counted entity
{
    weak_handle<element>   parent;
    weak_handle<element>   layout_parent; // normally parent, but can be different
    uint                   node_index;    // index in element::nodes collection
};

struct text : public node {...};
struct comment : public node {...};

struct element: node {

    tag::symbol_t tag;     // #div, #p, #span, etc.
    attribute_bag atts;    // DOM attributes
    ui_state      state;   // :focus, :hover, :active, etc.

    vector<hnode>        nodes; // child nodes
    handle<layout_data>  ldata; // "rendering tree" data

    hstyle          c_style; // current used style
    hstyle          p_style; // previously used style
    hstyle          d_style; // defined/determined style - computed from CSS
                             // declarations
    hstyle_prop_map a_style; // assigned style, can be null - element.style["..."] = ...;
    hstyle          p_drawn_style; // previously drawn style, for animation triggering

    handle<animation>    animator; // list of animators
    handle<ctl>          behavior; // event handlers a.k.a. behaviors

};

struct element in Sciter supports dynamic subclassing ( explained here https://stackoverflow.com/questions/21212379/changing-vtbl-of-existing-object-on-the-fly-dynamic-subclassing )

So, depending on style applied, particular element can be switched to (may have VTBL of derived class)

element_vertical // flex
element_horizontal // flex
element_grid // grid, flex
element_text // text container, like <p>
element_table
element_table_body
element_table_row
etc.