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 <steph...@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 <esteba...@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."
