let's talk about themes (and GLMBrickThemer)
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
Your new theme looks nice, congratulation! I will probably switch from the dark theme to this one once it will be available. :-) Julien On 01/08/16 11:13, Esteban Lorenzano 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
This whole theming story is not nice. One good thing about Pharo is that one can make the environment one's own. But most of the time, this starts with the colors, and one hits a brick wall. I just can't help thinking about pieces of software like WinAmp where one could do theming easily, adding plugins with ease etc. A lot of editors these days do it all with CSS and similar tech, blowing us out of the water on that front. Generally speaking, with the new Pharo (like 4.x, 5,x, 6,x), I face a more difficult system to get into (despite all the cool things Spotter allows). Somedays, I am wondering if we aren't actively keeping people out. Phil On Mon, Aug 1, 2016 at 11:13 AM, Esteban Lorenzano <estebanlm@gmail.com> 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
One good thing about Pharo is that one can make the environment one's own. But most of the time, this starts with the colors, and one hits a brick wall.
I just can't help thinking about pieces of software like WinAmp where one could do theming easily, adding plugins with ease etc.
A lot of editors these days do it all with CSS and similar tech, blowing us out of the water on that front.
Yes this is what Bloc2 does too.
Generally speaking, with the new Pharo (like 4.x, 5,x, 6,x), I face a more difficult system to get into (despite all the cool things Spotter allows).
Somedays, I am wondering if we aren't actively keeping people out. You mean over engineering I'm fighting against it.
Phil
On Mon, Aug 1, 2016 at 11:13 AM, Esteban Lorenzano <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> 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
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 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
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>
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 <estebanlm@gmail.com> wrote:
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>
-- www.tudorgirba.com www.feenk.com "Things happen when they happen, not when you talk about them happening."
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 <stepharo@free.fr <mailto: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>
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. 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 <estebanlm@gmail.com> 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."
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.
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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> 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 <http://www.tudorgirba.com> www.feenk.com
"Innovation comes in the least expected form. That is, if it is expected, it already happened."
Sorry, couldnât help putting this here. Each time I hear that there is a CSS usage outside of web I think about this mug:
On 09 Aug 2016, at 15:03, stepharo <stepharo@free.fr> 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 <estebanlm@gmail.com <mailto:estebanlm@gmail.com>> 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 <http://www.tudorgirba.com/> www.feenk.com <http://www.feenk.com/>
"Innovation comes in the least expected form. That is, if it is expected, it already happened."
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 <stepharo@free.fr> 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 <estebanlm@gmail.com> 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."
Le 9/8/16 à 21:15, Tudor Girba a écrit :
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 bit similar to settings. A component should have its settings as variables and values get pushed inside instead of asking a a large facade like systempreferences.
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 <stepharo@free.fr> 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 <estebanlm@gmail.com> 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."
Hi all, just few words about theme/skin concepts in Brick. A skin defines the way a widget is internally composed. The Datepicker is a good example, you can just compare the one in iOS and the one in jQuery, they don't use the same UI components internally and provide a completely different user experience: it is the role of the Skin. The styles are graphical options related to a particular skin. They can be colors, cornerRadii, fonts,... A theme defined a set of consistent skins and related style values for the whole widgets hierarchy. For example, the Material Design is a theme that define both skin and styles to use for all widgets. I think the notion of Palette is interesting to define theme variants without to be forced to create a new theme. Maybe, as a first step, a Palette can be simply something like a QPalette (Qt) which can be used in themes instead of static color values. The current style/theme implementation in Bloc/Brick is at an early stage and don't reflect exactly what it will be. I made a first working implementation of the CSS2+ model as a proof of concept but this doesn't mean that users will be forced to use CSS to style UIs. But i think we have to provide this kind of facility and the concepts under CSS open a lot of possibilities (cascading styles is one of them). Styling and theming are difficult subjects, many ways remain to be explored. Regards, Glenn. ----- Glenn Cavarlé -- View this message in context: http://forum.world.st/let-s-talk-about-themes-and-GLMBrickThemer-tp4908930p4... Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
participants (7)
-
Esteban Lorenzano -
Glenn Cavarlé -
Julien Delplanque -
phil＠highoctane.be -
stepharo -
Tudor Girba -
Yuriy Tymchuk