On Thu, 29 Dec 2016 21:41:45 +0000, aberba wrote:
> Styling is similar to CSS but different. Wished someone would just go for a full blown CSS parser. CSS has proven its more capable and loved for client side styling/decoration.

CSS is huge. It also brings in some assumptions about the layout model.

Supporting a subset of CSS would be reasonable.

On Thursday, 29 December 2016 at 22:53:51 UTC, Chris Wright wrote:
> On Thu, 29 Dec 2016 21:41:45 +0000, aberba wrote:
>> Styling is similar to CSS but different. Wished someone would just go for a full blown CSS parser. CSS has proven its more capable and loved for client side styling/decoration.
>
> CSS is huge. It also brings in some assumptions about the layout model.
>
> Supporting a subset of CSS would be reasonable.

This, besides there are things in CSS that only makes sense for it and not necessary for this. Like the way it certain styles are depending on each other, the dependencies may act differently by CSS, than it would by my library, because I do not render things with the same mindset or goal as CSS. One thing that especially is hard is the selector scheme as it's not based on styling a marked up language nor any kind of language structure at all. So the same kind of hierarchy doesn't exist with selectors like a div with a div isn't a thing, it's just a container that has a child component that's a container, but since this targets native GUI development then I don't want styling to match such inheritance and each component should be decoupled from each other. I believe it's much smoother and easier to manage your design. The only things that won't be decoupled from components and their children and surroundings would be things like positions, margins, paddings etc. all which doesn't affect the design.

On Tuesday, 20 December 2016 at 01:45:27 UTC, Tommi wrote:
> Improve the standard library!

...If you improve the standard library, everything OK? If...
Next Version Request.
Add To The F Sharp Like Pipeline Operator(D Language Pipeline Syntax is BAD.) & SML(C Language Compatible) Like Function Syntax &Haskell Like Maybe Monad&Binary Execution speed Up.
Plz,Now!!!

On Friday, 30 December 2016 at 06:22:40 UTC, bauss wrote:
> [...]

Yeah. I meant a subset. But widgets will not follow the DOM query syntax, it should use class attributes.

.button {
  border-color: red;
}

.container {
  ...
}

auto btn = new Button();
btn.addClass("button");
btn.addStyleFromFile("style.css");

...
container = new ...
container.addStyleFromSource(".container {…}");

On Friday, 30 December 2016 at 11:32:50 UTC, aberba wrote:
> On Friday, 30 December 2016 at 06:22:40 UTC, bauss wrote:
>> [...]
>
> Yeah. I meant a subset. But widgets will not follow the DOM query syntax, it should use class attributes.
>
> .button {
>   border-color: red;
> }
>
> .container {
>   ...
> }
>
> auto btn = new Button();
> btn.addClass("button");
> btn.addStyleFromFile("style.css");
>
> ...
> container = new ...
> container.addStyleFromSource(".container {…}");

Yeah it kinda follows classes right now already.

It follows a little different concept, where it's based on selectors and not classes.

So you give your component selectors that it acts on. There are of course default selectors on them such as their component type, name, states etc.

See:
https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L297

And:
https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L376

On Friday, 30 December 2016 at 13:26:15 UTC, Bauss wrote:
> On Friday, 30 December 2016 at 11:32:50 UTC, aberba wrote:
>> [...]
>
> Yeah it kinda follows classes right now already.
>
> It follows a little different concept, where it's based on selectors and not classes.
>
> So you give your component selectors that it acts on. There are of course default selectors on them such as their component type, name, states etc.
>
> See:
> https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L297
>
> And:
> https://github.com/PoisonEngine/poison-ui/blob/master/src/ui/component.d#L376

And of course: https://github.com/PoisonEngine/poison-ui/blob/master/README.md#styling

On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:

> Styling is similar to CSS but different. Wished someone would just go for a full blown CSS parser. CSS has proven its more capable and loved for client side styling/decoration.

Isn't this what GTK is essentially doing already where widget rendering is primarily defined by CSS.

On Friday, 30 December 2016 at 13:56:30 UTC, Getald wrote:
> On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:
>
>> Styling is similar to CSS but different. Wished someone would just go for a full blown CSS parser. CSS has proven its more capable and loved for client side styling/decoration.
>
> Isn't this what GTK is essentially doing already where widget rendering is primarily defined by CSS.

Yep it is

On Friday, 30 December 2016 at 13:56:30 UTC, Getald wrote:
> On Thursday, 29 December 2016 at 21:41:45 UTC, aberba wrote:
>
>> Styling is similar to CSS but different. Wished someone would just go for a full blown CSS parser. CSS has proven its more capable and loved for client side styling/decoration.
>
> Isn't this what GTK is essentially doing already where widget rendering is primarily defined by CSS.

Yes but it's gtk, there's year of work behind the library. For a homemade GUI library CSS or not CSS is really just bikeshedding around the format. The real stuff is to write the rendering engine. It becomes particularly tricky when the engine also supports transformations. If something is not well done you see it directly after rotation and translation.

On Saturday, 31 December 2016 at 08:14:28 UTC, jkpl wrote:
> Yes but it's gtk, there's year of work behind the library. For a homemade GUI library CSS or not CSS is really just bikeshedding around the format. The real stuff is to write the rendering engine. It becomes particularly tricky when the engine also supports transformations. If something is not well done you see it directly after rotation and translation.

rendering engine...hmmm...