Theme in Roassal

[pavel-krivanek]

Issue by bergel Sunday Apr 30, 2017 at 17:24 GMT Originally opened as https://github.com/moosetechnology/Moose/issues/1195

---

A more flexible handling of colors using definable color schemes or palettes or some like means sounds interesting though. We currently have made changes to Roassal to adjust some constantly defined colors, like eg. tooltip background, to our needs/wishes which could be more elegantly solved by definable color schemes.

[pavel-krivanek]

Comment by bergel Monday May 08, 2017 at 19:34 GMT

---

Tudor wrote:

I think this is difficult to demo and teach (and I do this a lot) because “color4” is obscure. Perhaps we can alleviate the problem by giving more domain names like:

• primary color
• emphasis color
• secondary emphasis color

But, I think there can be a nice middle ground. If, we introduce a ThemedColor like I said before, then “primaryColor” is nothing but an instance of that.

I would leave plain colors unaltered. So: view shape circle color: Color red. should always be drawn red. This will be very useful during demos.

If we want to transform it, we can introduce a transformation method in Color that applies the formula of Pavel and that assumes that the color was meant relative to white.

Maybe, something like: Color red asThemed.

[pavel-krivanek]

Comment by bergel Monday May 08, 2017 at 19:35 GMT

---

http://ethanschoonover.com/solarized provide a color table, both for dark and white theme

[pavel-krivanek]

Comment by bergel Friday May 19, 2017 at 22:18 GMT

---

The class TRTheme has improved. The Solarized theme is now in.

[pavel-krivanek]

Comment by girba Thursday May 25, 2017 at 07:05 GMT

---

I noticed. While this is interesting, I believe the solution is mostly suitable for situations where we have a limited and known set of amount of colors and combinations, like is the case for syntax highlighting (which is what Solarized was made for).

However, for Roassal we are not limited to those colors, and if we take into account the fact that we have overlapping situations the combinations are even larger. For example:

view := RTMondrian new. view shape circle borderColor: Color gray; color: (RTNColorLinearNormalizer inContext: (1 to: 100) lowColor: Color white highColor: Color black). view nodes: (1 to: 100). view

The goal here would be to highlight the large pieces that appear in black. However, when using the TRDarkSolarizedTheme, you get the exact opposite of what you want.

Furthermore, having a yellowish background is just not suitable for visualizations. Contrast is important and we cannot provide a default that throws it away.

At the level of Roassal we need to be able to control color. That is why the only solution I see is to have themed colors that I can specify explicitly.

[pavel-krivanek]

Comment by bergel Thursday May 25, 2017 at 14:37 GMT

---

I have the impression that there is not a unique implementation possible. Versions Roassal2-AlexandreBergel.1645 and Trachel-AlexandreBergel.418 allows the following:

view := RTMondrian new.
view view canvas theme: TRDarkTheme new.
view shape circle
borderColor: Color gray;
color: (RTNColorLinearNormalizer inContext: (1 to: 100) lowColor: Color white asThemed highColor: Color red asThemed).
view nodes: (1 to: 100).
view layout grid.
view

view := RTMondrian new.
view view canvas theme: TRWhiteTheme new.
view shape circle
borderColor: Color gray;
color: (RTNColorLinearNormalizer inContext: (1 to: 100) lowColor: Color white asThemed highColor: Color red asThemed).
view nodes: (1 to: 100).
view layout grid.
view

There is also a new class TRTheme

view := RTMondrian new.
view view canvas theme: TRDarkSolarizedTheme new.
view shape circle
borderColor: Color gray;
color: (RTNColorLinearNormalizer inContext: (1 to: 100) lowColor: TRTheme red highColor: TRTheme blue).
view nodes: (1 to: 100).
view layout grid.
view

I like the solution you have proposed. It allows anyone to define a new theme

[pavel-krivanek]

Comment by girba Thursday May 25, 2017 at 15:19 GMT

---

Nice, I think we are getting closer.

We still have the issue we have at the beginning. In the first example, Color white asThemed produces black. This is just not intuitive and we should have the option of controlling explicitly what we want to get.

This is why, I believe we need a ThemedColor object that is polymorphic with Color and that can make the decision dynamically. This way we could write something like:

ThemedColor forWhiteTheme: Color black; forDarkTheme: Color white.

We can still have Color>>asThemed but that should return this new object.

What do you think?

[akevalion]

Moved to roassal3 Please use roassal3 https://github.com/ObjectProfile/Roassal3 I will close this issue because cleaning process and roassal2 will be frozen