> On 02 Aug 2016, at 08:59, stepharo <steph...@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> >
