Hi,

On Apr 23, 2017, at 10:37 PM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:

As a quick fix for Roassal we probably can make an “inverted colors canvas”.

I think this is not necessarily a quick fix. I think this should be the first direction we should try.

Is anyone interested in taking this on?

Cheers, Doru

Also when Pharo was light Moose had a white theme. Now when Pharo goes dark should we make a black theme? :)

Cheers. Uko

...

On 23 Apr 2017, at 23:08, Tudor Girba tudor@tudorgirba.com wrote:

Hi,

As you could see, in Pharo we turned the Dark Theme on by default.

The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:

• they were conceived on a white canvas
• the colors are hardcoded

Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.

What do you think?

Cheers, Doru

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Every thing should have the right to be different."

Hi,

On Apr 24, 2017, at 8:44 AM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

I can try to look at it.

Great!

However I think that we should keep Moose white in the official version and switch in time when a proper palates management will be integrated in Pharo.

Or we can try to do that in the context of Moose and see how far this goes.

Doru

Cheers, -- Pavel

2017-04-23 22:40 GMT+02:00 Tudor Girba tudor@tudorgirba.com: Hi,

...

On Apr 23, 2017, at 10:37 PM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:

As a quick fix for Roassal we probably can make an “inverted colors canvas”.

I think this is not necessarily a quick fix. I think this should be the first direction we should try.

Is anyone interested in taking this on?

Cheers, Doru

...

Also when Pharo was light Moose had a white theme. Now when Pharo goes dark should we make a black theme? :)

Cheers. Uko

...

On 23 Apr 2017, at 23:08, Tudor Girba tudor@tudorgirba.com wrote:

Hi,

As you could see, in Pharo we turned the Dark Theme on by default.

The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:

• they were conceived on a white canvas
• the colors are hardcoded

Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.

What do you think?

Cheers, Doru

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Every thing should have the right to be different."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Some battles are better lost than fought."

On Sun, Apr 23, 2017 at 10:40:47PM +0200, Tudor Girba wrote:

Hi,

...

On Apr 23, 2017, at 10:37 PM, Yuriy Tymchuk yuriy.tymchuk@me.com wrote:

As a quick fix for Roassal we probably can make an “inverted colors canvas”.

I think this is not necessarily a quick fix. I think this should be the first direction we should try.

This is a quick fix, but also very ugly fix. I've done this long time ago as I regularly switch between light and dark (I toggle it with a metalink as I don't want to physically change the code, but that's not important here).

in `TRMorph>>#drawOn:` after `surface hasBeenFreed ifTrue: [ self createSurface ].` you add the following

``` surface drawDuring: [ :cs | cs paintMode restoreAfter: [ cs setPaint: Color white. cs paintMode difference. cs drawShape: (0 @ 0 extent: surface extent) ] ]. ```

but it is really weird to state in the background that you want an object blue, and suddenly you see it yellow (becuase it is inverted).

On discord we briefly discussed with Alex the idea of introducing themes. In principle it is not complex work, it's just lot of it. (as there are hardcoded values all over the place).

Peter

Is anyone interested in taking this on?

Cheers, Doru

...

Also when Pharo was light Moose had a white theme. Now when Pharo goes dark should we make a black theme? :)

Cheers. Uko

...

On 23 Apr 2017, at 23:08, Tudor Girba tudor@tudorgirba.com wrote:

Hi,

As you could see, in Pharo we turned the Dark Theme on by default.

The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:

• they were conceived on a white canvas
• the colors are hardcoded

Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.

What do you think?

Cheers, Doru

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Every thing should have the right to be different."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

On 24/04/2017 09:38, Peter Uhnak wrote:

On discord we briefly discussed with Alex the idea of introducing themes. In principle it is not complex work, it's just lot of it. (as there are hardcoded values all over the place). Peter

Kind of ironic that as developers of reverse-engineering tools, we don't have the tools to help us in this task (not complex, repetitive programming) :-(

nicolas

The PetitParser 2 UI also needs some care...

2017-04-24 10:10 GMT+02:00 Tudor Girba tudor@tudorgirba.com:

Hi,

...

On Apr 24, 2017, at 9:54 AM, Nicolas Anquetil Nicolas.Anquetil@inria.fr

wrote:

...

On 24/04/2017 09:38, Peter Uhnak wrote:

...

On discord we briefly discussed with Alex the idea of introducing

themes. In principle it is not complex work, it's just lot of it. (as there are hardcoded values all over the place). Peter

...

Kind of ironic that as developers of reverse-engineering tools, we don't

have the tools to help us in this task (not complex, repetitive programming) :-(

Why do you say that we do not have these tools? We do.

Doru

...

nicolas

-- Nicolas Anquetil -- MCF (HDR) Project-Team RMod

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Speaking louder won't make the point worthier."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

In the package PetitParser2-GUI-Morphic that generates graphs for grammar elements are hardcoded colors so the viewport is white even on the dark theme. It is not based on Roassal but on plain Morphic. E.g. PP2Node>>#morphicProduction

-- Pavel

2017-04-24 13:31 GMT+02:00 Tudor Girba tudor@tudorgirba.com:

What do you mean?

Doru

...

On Apr 24, 2017, at 10:50 AM, Pavel Krivanek pavel.krivanek@gmail.com

wrote:

...

The PetitParser 2 UI also needs some care...

2017-04-24 10:10 GMT+02:00 Tudor Girba tudor@tudorgirba.com: Hi,

...

On Apr 24, 2017, at 9:54 AM, Nicolas Anquetil <

Nicolas.Anquetil@inria.fr> wrote:

...

...

On 24/04/2017 09:38, Peter Uhnak wrote:

...

On discord we briefly discussed with Alex the idea of introducing

themes. In principle it is not complex work, it's just lot of it. (as there are hardcoded values all over the place). Peter

...

...

Kind of ironic that as developers of reverse-engineering tools, we

don't have the tools to help us in this task (not complex, repetitive programming) :-(

...

Why do you say that we do not have these tools? We do.

Doru

...

nicolas

-- Nicolas Anquetil -- MCF (HDR) Project-Team RMod

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Speaking louder won't make the point worthier."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Beauty is where we see it."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

Le 24/04/2017 à 22:18, Nicolas Anquetil a écrit :

I mean that this kind of work will probably involve little repetitive operations that require little intelligence for the 2nd, 3rd, ... repetition

being able to "declare" simply the first iteration and then replicate as simply the following ones would be nice

nicolas

IIRC Mark Rizun did a tool to automate refactoring in Pharo. He presented it at Esug in 2015.

I might prefer a color palette with semantic names: ColorPalette pastel16 primarySelectionColor. That can then be themed.

Stephan

Verstuurd vanaf mijn iPhone

Op 24 apr. 2017 om 17:53 heeft Tudor Girba tudor@tudorgirba.com het volgende geschreven:

I took a look at the code.

I think the transformColor: is exactly the relevant direction. But, I think there are still two issues to be addressed:

1. The logic does not yet work for everything. For example, lightRed is can be distinguished on white, but is barely so in the dark theme.

2. The more problematic issue is the mismatch between the script and the result.

Take a look at this example: view := RTMondrian new. view shape circle color: Color black. view nodes: (1 to: 42). view layout grid. view

On a white theme, it looks like:

<Playground-white.png>

On the dark theme, it would be:

<Playground-dark.png>

The problem is that in order to get the desired light gray result, I have to write “Color black” and this does not work.

How about introducing the notion of a ThemedColor?

Something like ThemedColor new for: RTDarkTheme use: Color lightGray; for: RTWhiteTheme use: Color black

And some derivates:

ThemedColor new forDark: Color lightGray; forWhite: Color black

Cheers, Doru

...

On Apr 24, 2017, at 4:52 PM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

It's done. Thank you very much, Alex! We only need to tune some colors for the best result in both themes.

-- Pavel

2017-04-23 22:08 GMT+02:00 Tudor Girba tudor@tudorgirba.com: Hi,

As you could see, in Pharo we turned the Dark Theme on by default.

The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:

• they were conceived on a white canvas
• the colors are hardcoded

Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.

What do you think?

Cheers, Doru

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software gets."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

I am really not happy with the current gray background, because it halves any color distinction in half, so everything becomes much harder to read.

If you have black text on white background, or white text on black background it's very distinct (as much as you can get), but when you put the color of the background in the middle, then both white text and black text (the most distant colors) become much harder to read.

Color black is turned into dim white, which is readable, but I find it unconfortable. Color white is just unreadable (yes, I can read it, but I actually have to focus on the word and cannot just glance it).

So, could we make the default background much darker (maybe the same dark as the playground text background)?

Regarding direct color specification: yes, it is relevant (maybe not for Moose); but being able to use custom theme instead of directly specifying the colors is also fine. (in other words, I would like to be able to specify exactly what colors to use)

Peter

On Tue, Apr 25, 2017 at 09:45:48AM +0200, Alexandre Bergel wrote:

Hi Doru,

...

I think the transformColor: is exactly the relevant direction. But, I think there are still two issues to be addressed:

Yes, Pavel came along with a relatively good formular to transform colors.

...

Take a look at this example: view := RTMondrian new. view shape circle color: Color black. view nodes: (1 to: 42). view layout grid. view

[…]

...

Something like ThemedColor new for: RTDarkTheme use: Color lightGray; for: RTWhiteTheme use: Color black

And some derivates:

ThemedColor new forDark: Color lightGray; forWhite: Color black

Having theme raises the relevance of directly specifying colors. In your Mondrian example, why would you want to have black nodes? Or, are you interested in having a color that is distinct from other used colors? And this goes with ThemedColor. Consider this: https://github.com/d3/d3-scale-chromatic

We could have the d3.schemeAccent palette for White Theme and d3.schemeDark2 for the Dark theme. The users would then not directly use a color, but an index in the palette. Maybe something like:

view := RTMondrian new. view shape circle color4. view nodes: (1 to: 42). view layout grid. view -=-=-=-=-=-=

Or "view shape circle colorPink.” since pink is the fourth of d3.schemeDark2

What do you think?

Let’s keep this discussion. We need to move on!

Cheers, Alexandre

...

Cheers, Doru

...

On Apr 24, 2017, at 4:52 PM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

It's done. Thank you very much, Alex! We only need to tune some colors for the best result in both themes.

-- Pavel

2017-04-23 22:08 GMT+02:00 Tudor Girba tudor@tudorgirba.com: Hi,

As you could see, in Pharo we turned the Dark Theme on by default.

The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:

• they were conceived on a white canvas
• the colors are hardcoded

Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.

What do you think?

Cheers, Doru

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software gets."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

I do not understand the question.

Doru

On Apr 25, 2017, at 10:41 AM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

2017-04-24 17:53 GMT+02:00 Tudor Girba tudor@tudorgirba.com: I took a look at the code.

I think the transformColor: is exactly the relevant direction. But, I think there are still two issues to be addressed:

1. The logic does not yet work for everything. For example, lightRed is can be distinguished on white, but is barely so in the dark theme.

2. The more problematic issue is the mismatch between the script and the result.

Take a look at this example: view := RTMondrian new. view shape circle color: Color black. view nodes: (1 to: 42). view layout grid. view

On a white theme, it looks like:

<Playground-white.png>

On the dark theme, it would be:

<Playground-dark.png>

The problem is that in order to get the desired light gray result, I have to write “Color black” and this does not work.

White is only a shade of black :-)

How about introducing the notion of a ThemedColor?

Something like ThemedColor new for: RTDarkTheme use: Color lightGray; for: RTWhiteTheme use: Color black

And some derivates:

ThemedColor new forDark: Color lightGray; forWhite: Color black

Cheers, Doru

...

On Apr 24, 2017, at 4:52 PM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

It's done. Thank you very much, Alex! We only need to tune some colors for the best result in both themes.

-- Pavel

2017-04-23 22:08 GMT+02:00 Tudor Girba tudor@tudorgirba.com: Hi,

As you could see, in Pharo we turned the Dark Theme on by default.

The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:

• they were conceived on a white canvas
• the colors are hardcoded

Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.

What do you think?

Cheers, Doru

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software gets."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Next time you see your life passing by, say 'hi' and get to know her."

Never mind. I read the wrong thing :)

Doru

On Apr 25, 2017, at 11:58 AM, Alexandre Bergel alexandre.bergel@me.com wrote:

Which question? Pavel did not ask a question :-)

Alexandre

...

On Apr 25, 2017, at 11:16 AM, Tudor Girba tudor@tudorgirba.com wrote:

I do not understand the question.

Doru

...

On Apr 25, 2017, at 10:41 AM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

2017-04-24 17:53 GMT+02:00 Tudor Girba tudor@tudorgirba.com: I took a look at the code.

I think the transformColor: is exactly the relevant direction. But, I think there are still two issues to be addressed:

1. The logic does not yet work for everything. For example, lightRed is can be distinguished on white, but is barely so in the dark theme.

2. The more problematic issue is the mismatch between the script and the result.

Take a look at this example: view := RTMondrian new. view shape circle color: Color black. view nodes: (1 to: 42). view layout grid. view

On a white theme, it looks like:

<Playground-white.png>

On the dark theme, it would be:

<Playground-dark.png>

The problem is that in order to get the desired light gray result, I have to write “Color black” and this does not work.

White is only a shade of black :-)

How about introducing the notion of a ThemedColor?

Something like ThemedColor new for: RTDarkTheme use: Color lightGray; for: RTWhiteTheme use: Color black

And some derivates:

ThemedColor new forDark: Color lightGray; forWhite: Color black

Cheers, Doru

...

On Apr 24, 2017, at 4:52 PM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

It's done. Thank you very much, Alex! We only need to tune some colors for the best result in both themes.

-- Pavel

2017-04-23 22:08 GMT+02:00 Tudor Girba tudor@tudorgirba.com: Hi,

As you could see, in Pharo we turned the Dark Theme on by default.

The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:

• they were conceived on a white canvas
• the colors are hardcoded

Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.

What do you think?

Cheers, Doru

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software gets."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Next time you see your life passing by, say 'hi' and get to know her."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"No matter how many recipes we know, we still value a chef."

Hi,

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.

What do you think?

Doru

On Apr 25, 2017, at 1:01 PM, Alexandre Bergel alexandre.bergel@me.com wrote:

So, is something like:

view := RTMondrian new. view shape circle color4. view nodes: (1 to: 42). view layout grid. view -=-=-=-=-=-= acceptable?

#color4 would then pick the fourth colors of a suitable palette.

Alexandre

...

On Apr 25, 2017, at 12:52 PM, Tudor Girba tudor@tudorgirba.com wrote:

Never mind. I read the wrong thing :)

Doru

...

On Apr 25, 2017, at 11:58 AM, Alexandre Bergel alexandre.bergel@me.com wrote:

Which question? Pavel did not ask a question :-)

Alexandre

...

On Apr 25, 2017, at 11:16 AM, Tudor Girba tudor@tudorgirba.com wrote:

I do not understand the question.

Doru

...

On Apr 25, 2017, at 10:41 AM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

2017-04-24 17:53 GMT+02:00 Tudor Girba tudor@tudorgirba.com: I took a look at the code.

I think the transformColor: is exactly the relevant direction. But, I think there are still two issues to be addressed:

1. The logic does not yet work for everything. For example, lightRed is can be distinguished on white, but is barely so in the dark theme.

2. The more problematic issue is the mismatch between the script and the result.

Take a look at this example: view := RTMondrian new. view shape circle color: Color black. view nodes: (1 to: 42). view layout grid. view

On a white theme, it looks like:

<Playground-white.png>

On the dark theme, it would be:

<Playground-dark.png>

The problem is that in order to get the desired light gray result, I have to write “Color black” and this does not work.

White is only a shade of black :-)

How about introducing the notion of a ThemedColor?

Something like ThemedColor new for: RTDarkTheme use: Color lightGray; for: RTWhiteTheme use: Color black

And some derivates:

ThemedColor new forDark: Color lightGray; forWhite: Color black

Cheers, Doru

...

On Apr 24, 2017, at 4:52 PM, Pavel Krivanek pavel.krivanek@gmail.com wrote:

It's done. Thank you very much, Alex! We only need to tune some colors for the best result in both themes.

-- Pavel

2017-04-23 22:08 GMT+02:00 Tudor Girba tudor@tudorgirba.com: Hi,

As you could see, in Pharo we turned the Dark Theme on by default.

The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons:

• they were conceived on a white canvas
• the colors are hardcoded

Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo.

What do you think?

Cheers, Doru

-- www.tudorgirba.com www.feenk.com

"Not knowing how to do something is not an argument for how it cannot be done."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

“The smaller and more pervasive the hardware becomes, the more physical the software gets."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Next time you see your life passing by, say 'hi' and get to know her."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"No matter how many recipes we know, we still value a chef."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"We cannot reach the flow of things unless we let go."

Can we continue this thread?

:-)

Yes. I like what you propose. Primary Color, emphasis Color… Having #asThemed is also easy to have. It is orthogonal actually.

The last few weeks have been intense. I will do a major overhaul of the coloring in Roassal very soon. This is crucial. The default colors of Mondrian and Grapher also need to be completely rethought.

Alexandre

...

On Apr 30, 2017, at 8:07 AM, Tudor Girba tudor@tudorgirba.com wrote:

Hi,

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.

What do you think?

Doru

...

On Apr 25, 2017, at 1:01 PM, Alexandre Bergel alexandre.bergel@me.com wrote:

So, is something like:

view := RTMondrian new. view shape circle color4. view nodes: (1 to: 42). view layout grid. view -=-=-=-=-=-= acceptable?

#color4 would then pick the fourth colors of a suitable palette.

Alexandre

...

On Apr 25, 2017, at 12:52 PM, Tudor Girba tudor@tudorgirba.com wrote:

Never mind. I read the wrong thing :)

Doru

...

On Apr 25, 2017, at 11:58 AM, Alexandre Bergel alexandre.bergel@me.com wrote:

Which question? Pavel did not ask a question :-)

Alexandre

...

On Apr 25, 2017, at 11:16 AM, Tudor Girba tudor@tudorgirba.com wrote:

I do not understand the question.

Doru

> On Apr 25, 2017, at 10:41 AM, Pavel Krivanek pavel.krivanek@gmail.com wrote: > > > > 2017-04-24 17:53 GMT+02:00 Tudor Girba tudor@tudorgirba.com: > I took a look at the code. > > I think the transformColor: is exactly the relevant direction. But, I think there are still two issues to be addressed: > > 1. The logic does not yet work for everything. For example, lightRed is can be distinguished on white, but is barely so in the dark theme. > > 2. The more problematic issue is the mismatch between the script and the result. > > Take a look at this example: > view := RTMondrian new. > view shape circle color: Color black. > view nodes: (1 to: 42). > view layout grid. > view > > On a white theme, it looks like: > > <Playground-white.png> > > On the dark theme, it would be: > > <Playground-dark.png> > > The problem is that in order to get the desired light gray result, I have to write “Color black” and this does not work. > > White is only a shade of black :-) > > > How about introducing the notion of a ThemedColor? > > Something like > ThemedColor new > for: RTDarkTheme use: Color lightGray; > for: RTWhiteTheme use: Color black > > And some derivates: > > ThemedColor new > forDark: Color lightGray; > forWhite: Color black > > > Cheers, > Doru > > >> On Apr 24, 2017, at 4:52 PM, Pavel Krivanek pavel.krivanek@gmail.com wrote: >> >> It's done. Thank you very much, Alex! >> We only need to tune some colors for the best result in both themes. >> >> -- Pavel >> >> 2017-04-23 22:08 GMT+02:00 Tudor Girba tudor@tudorgirba.com: >> Hi, >> >> As you could see, in Pharo we turned the Dark Theme on by default. >> >> The question is what should we do with Moose. I think it would be great to have it working with the Dark Theme, but the problem is that the Roassal visualizations do not appropriate in the current theme because of two reasons: >> - they were conceived on a white canvas >> - the colors are hardcoded >> >> Showing a white canvas in the Dark Theme is not an option. Either we introduce a mechanism to adapt the visualizations to the current theme, or we keep a different theme in Moose than in Pharo. >> >> What do you think? >> >> Cheers, >> Doru >> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Not knowing how to do something is not an argument for how it cannot be done." >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >> _______________________________________________ >> Moose-dev mailing list >> Moose-dev@list.inf.unibe.ch >> https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > “The smaller and more pervasive the hardware becomes, the more physical the software gets." > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > > > _______________________________________________ > Moose-dev mailing list > Moose-dev@list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"Next time you see your life passing by, say 'hi' and get to know her."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"No matter how many recipes we know, we still value a chef."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev

-- www.tudorgirba.com www.feenk.com

"We cannot reach the flow of things unless we let go."

-- www.tudorgirba.com www.feenk.com

"Problem solving efficiency grows with the abstractness level of problem understanding."

---

Moose-dev mailing list Moose-dev@list.inf.unibe.ch https://www.list.inf.unibe.ch/listinfo/moose-dev