Hi, We would definitely benefit from a Palette.
One interesting concepts in Bloc2 is that the concrete values are injected in the widget, instead of having the widget ask for it. This is quite powerful because it enables a CSS mechanism (or another one), but we also have to see how it works with the requirement of changing these values dynamically. This will certainly be a next step after the core is stable. Cheers, Doru > On Aug 9, 2016, at 3:03 PM, stepharo <[email protected]> wrote: > > Hi doru > > I think that this is particularly true (having a themer per widget) when the > themer is more a skinner (it changes behavior of the widgets), else we could > have addressed the problem with a solution close to setting. Two years ago I > played with theming and widgets hierarchy and I came to the same conclusion > (that your blog entries). > Do you know how they do it in JavaFX? > I agree also that we should extract the Palette. > Now I'm really curious to see the CSS of Glenn in Bloc2. > Stef > > Le 4/8/16 à 12:52, Tudor Girba a écrit : >> Hi Esteban, >> >> Sorry for the delayed response. >> >> There are two parts in your mail: >> 1. the decomposition of theme to have one themer per widget >> 2. a centralized catalog of values >> >> I certainly agree with 2. In fact, when I refactored the theme colors a long >> time ago, I introduced a rudimentary reuse mechanism on the class side of >> the Theme class. So, now, we should extract those separately. >> >> About 1., I have a different opinion. The hierarchy you mention already >> exists in the Theme class as well, only it is hidden, and it is very hard to >> see what each methods impacts. >> >> Here is how I reached this conclusion. Take a look at this picture I >> produced before we started with Brick (the one from Morphic). The gray >> circles are methods in UITheme, and the red circles are typical Morphs (like >> TextMorph, ListMorph). The gray lines show self calls inside the UITheme, >> and the red lines shod calls from the morph to the UITheme methods. What you >> see here is a very strong clustering of the methods around the widgets, and >> this indicates that having a theme object per widget is appropriate. >> >> >> <Mail Attachment.png> >> >> >> A further constrain is that we want to be able to change the appearance of a >> widget on an instance basis (that is, overriding the default theme setting), >> and having a per-widget themer object, we can achieve that as well. >> >> A similar design appears in Bloc as well, and I think it is actually more >> scalable then the current UITheme, provided that you indeed have a way to >> either centralize the definitions of colors (and other properties), or >> inject those properties from the outside. >> >> All in all, let’s go ahead and extract the palette :). >> >> Cheers, >> Doru >> >> >>> On Aug 1, 2016, at 11:13 AM, Esteban Lorenzano <[email protected]> wrote: >>> >>> 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 >>> >>> >>> <Screen Shot 2016-08-01 at 11.00.15.png> >> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "Innovation comes in the least expected form. >> That is, if it is expected, it already happened." >> > -- www.tudorgirba.com www.feenk.com "To lead is not to demand things, it is to make them happen."
