On 02 Aug 2016, at 08:59, stepharo <stepharo@free.fr> wrote:

Hi esteban

It looks cool. For the error could you use a different one because I cannot read it.

Else when I tried to use the same way than Setting to manage skins it did not work

because theming is a lot of things:��

- a skin

- a color palette

- etc.

for now, I would be happy with extract the color palette into a ��StyleSheet�� object�� this could be modified in settings (while a complete skin not).

Esteban

because a skin is not just color it can be behavior and you have to attach it somewhere.

Now in bloc 2 :)

�� you can the look (that can be expressed with CSS)

�� and you have skins (the behavior: a date can be displayed as a calendar vs. a roller).

In this model a theme (color) will just be similar to applying a new CSS.

Stef

Le 1/8/16 �� 11:13, Esteban Lorenzano a ��crit��:

Hi,��

For one of my side-projects, I made a new theme for Pharo (still no name, I was planing to call it ��Dark Metal�� or something like that. Is a variation on the Dark Theme but ��our�� dark theme is more brown and this one is more blue (see attached)�� I wanted to publish it to push it but then I arrived to an unexpected problem: For Spotter and GTTools in general, theming is not done following current theming approach. Instead, they made a full hierarchy of objects.��

IMO this is plain bad. I understand the attempt to decouple, but now that means if I want to create a new theme, I need to create my theme object with colors I want and then also I need to create an undetermined number of classes (at least one for each tool, but there is also a hierarchy of things there)�� anyway, this DOES NOT scale. Because each tool will have to have a ��theme class�� for each existing theme��

How themes (skins, bah) work in all word is to have a color palette and then tools takes them (they can ��play�� a bit with this palette, but need to always respect the palette).��

Then, I will commit a SLICE modifying the ��themer�� classes to take colors from the current theme (instead of have them hardcoded).��

But of course, how theme work now is not good because they mix ��theme�� (how they display) and ��skin�� (color palette). I will also extract the palette to where should have always been (some kind of a style sheet object)�� who also should have been editable in settings so people can tweak their configuration.��

I didn��t wanted to touch this before, because this will supposedly change with brick, but honestly this will not be ready for Pharo 6 and this is annoying (also, I want to publish my theme and I do not want to add overrides all around :P)

cheers,

Esteban

<Mail Attachment.png>