Re: [Pharo-dev] UITheme experience (please read) :)

July 19, 2014


      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...) 
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 
<mailto: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 <http://www.tudorgirba.com>
"Every thing has its own flow"