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>