Hi, I will take a look at this tomorrow and get back to you.
Cheers, Doru > On Aug 2, 2016, at 12:06 PM, Esteban Lorenzano <[email protected]> wrote: > > >> On 02 Aug 2016, at 08:59, stepharo <[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> >> > -- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."
