Hi esteban
Next time I have a look at Bloc2 I will check if there is such concept
and see how we can package it.
Stef
Le 2/8/16 à 12:06, Esteban Lorenzano a écrit :
On 02 Aug 2016, at 08:59, stepharo <[email protected]
<mailto:[email protected]>> 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>
