Definitely!

My post was about the second point.

Doru

On Sat, Jul 19, 2014 at 5:22 PM, stepharo <stepharo@free.fr> wrote:

Hi doru

I think that there are two points:
������ - moving creation API from theme to classes (I'm doing this one to also create example of the widgets)
������ ������ Smalltalk ui theme newButton.... sucks :)
������ - rethinking the theming architecture

Stef

On 19/7/14 14:16, Tudor Girba wrote:

Hi Stef,

I do not have time right now to go into details, so take this just as an acknowledgment that I have an interest in this topic :).

My initial proposal that I sent to this list a while ago (some details are provided here: http://www.humane-assessment.com/blog/a-pharo-refactoring-story-adding-theme-ability-to-a-morph) went exactly in the direction of a ThemeStrategy that I call Themer. We used it already for several morphs around Glamour to play with the boundaries and it works well.

I still think we need the UITheme but that should only provide a list of themers without any implementation. Like that we can package a uniform look throughout the whole environment. However, we should still be able to override the themer at the level of morph for quick prototyping and custom needs.

I will get back to you.

Cheers,

Doru

On Sat, Jul 19, 2014 at 9:15 AM, stepharo <stepharo@free.fr> wrote:

Hi guys

I want to lower the importance of UITheme

- first the factory API should be pushed in the respective classes
ie:

UItheme>>newButtonIn: aThemedMorph for: aModel getState: stateSel action: actionSel arguments: args getEnabled: enabledSel getLabel: labelSel help: helpText
"Answer a new button."

|b|
b := PluggableButtonMorph
on: aModel
getState: stateSel
action: actionSel
label: labelSel.
b
theme: self;
label: ' ' font: self buttonFont;
update: labelSel;
arguments: (args ifNil: [{b}]);
getEnabledSelector: enabledSel;
cornerStyle: (self buttonCornerStyleIn: aThemedMorph);
hResizing: #shrinkWrap;
vResizing: #shrinkWrap;
setBalloonText: helpText;
extent: b minExtent;
removeProperty: #theme.
^b


should be transformed into

PluggableButtonMorph>>newButtonFor: aModel getState: stateSel action: actionSel arguments: args getEnabled: enabledSel label: label help: helpText
"Answer a new button."

| b |
b := self on: aModel getState: stateSel action: actionSel.
b
arguments: (args ifNil: [{b}]);
hResizing: #shrinkWrap;
vResizing: #shrinkWrap;
label: label ;
getEnabledSelector: enabledSel;
setBalloonText: helpText;
extent: b minExtent;
hResizing: #rigid;
vResizing: #rigid.
^b


Now I do not want to lose the theme so I'm working on that.

- second I wanted to experiment with the theming architecture

I did the following

XPGrowlMorph

Object < XPGrowlThemeStrategy
parentTheme := UITheme new

XPGrowlThemeStrategy < XPGrowlDarkTheme
parentTheme := PharoDarkTheme new
growFillColor:
Color white
XPGrowlThemeStrategy < XPGrowlPharo30Theme
parentTheme := Pharo30Theme new
growFillColor:
Color red
minTextSize
^ parentTheme minTextSize

I did the same with XPSimpleButtonMorph


Conclusion:

- Do we gain from object inheritance vs class?
I do not think that we want to change dynamical the theme chain
So I will make the widget strategy class from their theme

PharoDarkTheme < XPGrowlDarkTheme

Pharo30Theme < XPGrowlPharo30Theme

- cons we may have duplicated behavior accross theme => traits?

- Do we gain having widgets specific theming strategy
- cons this generate a lot of classes
so we will see

+ with inheritance we reuse a lot
+ probably we can reduce the API of UItheme (see below)


- Can we reduce the API of UITheme
buttonBorderColor
listBorderColor
���.

Yes probably doing

Pharo3Theme>>buttonBorderColor

=>

Pharo30ButtonStrategy>>borderColor

-> but should be experimented


- From a widget point of view, if we want to have possibility to see the same widgets in different theme at the same time
this raises the problem of the injection (or recomputation) of the theme values.
Example below:
We want to specify a theme but the new is calling initialize and the values are computed with a default/current theme.


XPGrowlMorph new
theme: XPPharo3ThemeStrategy new;
label: 'The time' contents: TimeStamp now;
skin;
openInWorld.

XPGrowlMorph new
theme: XPDarkThemeStrategy new;
label: 'The time' contents: TimeStamp now;
openInWorld.

=> Question is it worth because with a default theme we would have it nearly working.

Stef

--

www.tudorgirba.com

"Every thing has its own flow"

--

www.tudorgirba.com

"Every thing has its own flow"