[Pharo-dev] about theme and friends

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

[Pharo-dev] about theme and friends

Stéphane Ducasse
esteban

I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the
one of settings.

Every widget should have custom hooks and setter, getter and default values.
The hooks should be annotated or registered seomwhere.
Then the widget code simply uses the hooks normally.

Now a theme changes should push new values onto these hooks.

This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme.
I will try to build a small experiment but I'm sure that this is the solution

Nobody call settings nowadays (as it was the case with Preferences in the past).

Stef
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Benjamin Van Ryseghem (Pharo)
The problem is the overlapping.
For settings, different project do not define the same settings.

But for tools, it's different
By example, Browser, and Nautilus will try to register to default browser.

Ben

On May 14, 2013, at 4:55 PM, Stéphane Ducasse <[hidden email]> wrote:

esteban

I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the
one of settings.

Every widget should have custom hooks and setter, getter and default values.
The hooks should be annotated or registered seomwhere.
Then the widget code simply uses the hooks normally.

Now a theme changes should push new values onto these hooks.

This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme.
I will try to build a small experiment but I'm sure that this is the solution

Nobody call settings nowadays (as it was the case with Preferences in the past).

Stef

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

stephane ducasse

On May 14, 2013, at 5:13 PM, Benjamin <[hidden email]> wrote:

The problem is the overlapping.
For settings, different project do not define the same settings.

But for tools, it's different
By example, Browser, and Nautilus will try to register to default browser.

I'm not talking about this level.
No registration about tools. UITheme does not deal with that. 

The current theme should push to all the widgets that the defaultColor is blue. 




Ben

On May 14, 2013, at 4:55 PM, Stéphane Ducasse <[hidden email]> wrote:

esteban

I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the
one of settings.

Every widget should have custom hooks and setter, getter and default values.
The hooks should be annotated or registered seomwhere.
Then the widget code simply uses the hooks normally.

Now a theme changes should push new values onto these hooks.

This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme.
I will try to build a small experiment but I'm sure that this is the solution

Nobody call settings nowadays (as it was the case with Preferences in the past).

Stef


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Benjamin Van Ryseghem (Pharo)
Ok, my bad :)

This is a massive refactoring, but indeed, it may be cool :)
Ben

On May 14, 2013, at 5:18 PM, stephane ducasse <[hidden email]> wrote:


On May 14, 2013, at 5:13 PM, Benjamin <[hidden email]> wrote:

The problem is the overlapping.
For settings, different project do not define the same settings.

But for tools, it's different
By example, Browser, and Nautilus will try to register to default browser.

I'm not talking about this level.
No registration about tools. UITheme does not deal with that. 

The current theme should push to all the widgets that the defaultColor is blue. 




Ben

On May 14, 2013, at 4:55 PM, Stéphane Ducasse <[hidden email]> wrote:

esteban

I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the
one of settings.

Every widget should have custom hooks and setter, getter and default values.
The hooks should be annotated or registered seomwhere.
Then the widget code simply uses the hooks normally.

Now a theme changes should push new values onto these hooks.

This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme.
I will try to build a small experiment but I'm sure that this is the solution

Nobody call settings nowadays (as it was the case with Preferences in the past).

Stef



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Gary Chambers-4
Please do bear in mind having multiple themes concurrently in use.
Whilst we have a theme for the devolopment environment, instances of applications can have their own etc.

Regards, Gary
----- Original Message -----
Sent: Tuesday, May 14, 2013 4:22 PM
Subject: Re: [Pharo-dev] about theme and friends

Ok, my bad :)

This is a massive refactoring, but indeed, it may be cool :)
Ben

On May 14, 2013, at 5:18 PM, stephane ducasse <[hidden email]> wrote:


On May 14, 2013, at 5:13 PM, Benjamin <[hidden email]> wrote:

The problem is the overlapping.
For settings, different project do not define the same settings.

But for tools, it's different
By example, Browser, and Nautilus will try to register to default browser.

I'm not talking about this level.
No registration about tools. UITheme does not deal with that. 

The current theme should push to all the widgets that the defaultColor is blue. 




Ben

On May 14, 2013, at 4:55 PM, Stéphane Ducasse <[hidden email]> wrote:

esteban

I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the
one of settings.

Every widget should have custom hooks and setter, getter and default values.
The hooks should be annotated or registered seomwhere.
Then the widget code simply uses the hooks normally.

Now a theme changes should push new values onto these hooks.

This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme.
I will try to build a small experiment but I'm sure that this is the solution

Nobody call settings nowadays (as it was the case with Preferences in the past).

Stef



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Stéphane Ducasse
In reply to this post by Stéphane Ducasse
Looking at the code I have the impression that many UITheme methods should be moved to the their classes

Example:


UITheme>>newGroupboxIn: aThemedMorph label: aString
        "Answer a groupbox with the given label."

        ^GroupboxMorph new
                font: self labelFont;
                cornerStyle: aThemedMorph preferredCornerStyle;
                hResizing: #spaceFill;
                vResizing: #spaceFill;
                label: aString;
                yourself

Why this is not a creation method on GroupBox?

Then the trait TeasilyThemed looks suspicious to me.



Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Tudor Girba-2
Hi,

I was rather thinking of having the theme be a composable factory:
- for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory.
- the UITheme simply stores all these factories, and the morph looks the factory up via the theme.
- the UITheme will have no more subclasses.
- in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme.

This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside.

Cheers,
Doru



On May 14, 2013, at 9:24 PM, Stéphane Ducasse <[hidden email]> wrote:

> Looking at the code I have the impression that many UITheme methods should be moved to the their classes
>
> Example:
>
>
> UITheme>>newGroupboxIn: aThemedMorph label: aString
> "Answer a groupbox with the given label."
>
> ^GroupboxMorph new
> font: self labelFont;
> cornerStyle: aThemedMorph preferredCornerStyle;
> hResizing: #spaceFill;
> vResizing: #spaceFill;
> label: aString;
> yourself
>
> Why this is not a creation method on GroupBox?
>
> Then the trait TeasilyThemed looks suspicious to me.
>
>
>

--
www.tudorgirba.com

"Presenting is storytelling."


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Dennis Groves
How do I get off this list? I never subscribed - so I don't have a
login. :(


--
[Dennis Groves](http://about.me/dennis.groves), MSc
[Email me](mailto:[hidden email]) or [schedule a
meeting](http://goo.gl/8sPIy).

> "Unless someone like you...cares a whole awful lot...nothing is going
> to get better...It's not." -- The Lorax

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Marcus Denker-4

On May 14, 2013, at 10:04 PM, "Dennis Groves" <[hidden email]> wrote:

> How do I get off this list? I never subscribed - so I don't have a login. :(
>

I will remove you.

But it's strange. I took all email addresses that where in the old pharo-project list and added
them here. So the other list did send mails to your address before… maybe you filtered them?

But I have seen stranger things with Mailman ;-).

        Marcus.


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Stéphane Ducasse
In reply to this post by Dennis Groves

On May 14, 2013, at 10:03 PM, Dennis Groves <[hidden email]> wrote:

> How do I get off this list? I never subscribed - so I don't have a login. :(

Ask nicely :)
We never added you so someone should have done it.
We will remove you.


>
>
> --
> [Dennis Groves](http://about.me/dennis.groves), MSc
> [Email me](mailto:[hidden email]) or [schedule a meeting](http://goo.gl/8sPIy).
>
>> "Unless someone like you...cares a whole awful lot...nothing is going to get better...It's not." -- The Lorax
>


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

stephane ducasse
In reply to this post by Stéphane Ducasse
StandardWindow>>defaultColor
        "Answer the default color/fill style for the receiver"
       
        ^self theme windowColor

to me I would put windowColor as a variable of the window.

Stef


On May 14, 2013, at 4:55 PM, Stéphane Ducasse <[hidden email]> wrote:

> esteban
>
> I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the
> one of settings.
>
> Every widget should have custom hooks and setter, getter and default values.
> The hooks should be annotated or registered seomwhere.
> Then the widget code simply uses the hooks normally.
>
> Now a theme changes should push new values onto these hooks.
>
> This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme.
> I will try to build a small experiment but I'm sure that this is the solution
>
> Nobody call settings nowadays (as it was the case with Preferences in the past).
>
> Stef


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

stephane ducasse
In reply to this post by Gary Chambers-4
<base href="x-msg://1058/">
On May 14, 2013, at 5:36 PM, Gary Chambers <[hidden email]> wrote:

Please do bear in mind having multiple themes concurrently in use.
Whilst we have a theme for the devolopment environment, instances of applications can have their own etc.


Ok we will :)


Regards, Gary
----- Original Message -----
Sent: Tuesday, May 14, 2013 4:22 PM
Subject: Re: [Pharo-dev] about theme and friends

Ok, my bad :)

This is a massive refactoring, but indeed, it may be cool :)
Ben

On May 14, 2013, at 5:18 PM, stephane ducasse <[hidden email]> wrote:


On May 14, 2013, at 5:13 PM, Benjamin <[hidden email]> wrote:

The problem is the overlapping.
For settings, different project do not define the same settings.

But for tools, it's different
By example, Browser, and Nautilus will try to register to default browser.

I'm not talking about this level.
No registration about tools. UITheme does not deal with that. 

The current theme should push to all the widgets that the defaultColor is blue. 




Ben

On May 14, 2013, at 4:55 PM, Stéphane Ducasse <[hidden email]> wrote:

esteban

I discussed with damien and I think that now I got the solution. In fact the architecture should be the same than the 
one of settings.

Every widget should have custom hooks and setter, getter and default values.
The hooks should be annotated or registered seomwhere.
Then the widget code simply uses the hooks normally.

Now a theme changes should push new values onto these hooks.

This will lead to a flow that is totally different. Nobody should write UITheme builder or even Smalltalk ui theme.
I will try to build a small experiment but I'm sure that this is the solution

Nobody call settings nowadays (as it was the case with Preferences in the past). 

Stef

Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

stephane ducasse
In reply to this post by Tudor Girba-2

> Hi,
>
> I was rather thinking of having the theme be a composable factory:
> - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory.

Why a factory and not just the morph?

> - the UITheme simply stores all these factories, and the morph looks the factory up via the theme.

I do not get it.
One key question is do we want to have the theme removable or not.
Now if we would pushed only data through the hooks of the widgets it could work
but we will have to be able to specify specific computation for a given widgets and theme.
So may be this is what you mean by factory but this is still not clear to me.

> - the UITheme will have no more subclasses.

But you will have multiple subclasses of each of the factories?


> - in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme.
>
> This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside.

Yes but the GroupBoxFactory will also be out of the GroupBoxMorph so this is not clear to me how this is different


>
> Cheers,
> Doru
>
>
>
> On May 14, 2013, at 9:24 PM, Stéphane Ducasse <[hidden email]> wrote:
>
>> Looking at the code I have the impression that many UITheme methods should be moved to the their classes
>>
>> Example:
>>
>>
>> UITheme>>newGroupboxIn: aThemedMorph label: aString
>> "Answer a groupbox with the given label."
>>
>> ^GroupboxMorph new
>> font: self labelFont;
>> cornerStyle: aThemedMorph preferredCornerStyle;
>> hResizing: #spaceFill;
>> vResizing: #spaceFill;
>> label: aString;
>> yourself
>>
>> Why this is not a creation method on GroupBox?
>>
>> Then the trait TeasilyThemed looks suspicious to me.
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Presenting is storytelling."
>
>


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Tudor Girba-2
Hi,

On May 14, 2013, at 10:18 PM, stephane ducasse <[hidden email]> wrote:

>
>> Hi,
>>
>> I was rather thinking of having the theme be a composable factory:
>> - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory.
>
> Why a factory and not just the morph?

Because you will need a place that will orchestrate how multiple morphs look. Of course, some of the properties can become part of the morph, but you will still need the theme responsible object.

>> - the UITheme simply stores all these factories, and the morph looks the factory up via the theme.
>
> I do not get it.
> One key question is do we want to have the theme removable or not.
> Now if we would pushed only data through the hooks of the widgets it could work
> but we will have to be able to specify specific computation for a given widgets and theme.
> So may be this is what you mean by factory but this is still not clear to me.

I am not sure what you mean by removable, but I think we should be able to remove a particular theme, but not the theme as a concept.

>> - the UITheme will have no more subclasses.
>
> But you will have multiple subclasses of each of the factories?

Yes.

>> - in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme.
>>
>> This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside.
>
> Yes but the GroupBoxFactory will also be out of the GroupBoxMorph so this is not clear to me how this is different

GroupBoxMorph>>doSomething
        self theme groupBoxFactory doSomethingWith: self

The two will work together tightly.

The advantage is that you will not have all drawing methods in one class, but nicely separated into dedicated classes.
And then I can do:

UITheme current
        textFactory: StandardTextFactory new;
        groupBoxFactory: FancyGroupBoxFactory new;
        ...

Cheers,
Doru


>>
>> Cheers,
>> Doru
>>
>>
>>
>> On May 14, 2013, at 9:24 PM, Stéphane Ducasse <[hidden email]> wrote:
>>
>>> Looking at the code I have the impression that many UITheme methods should be moved to the their classes
>>>
>>> Example:
>>>
>>>
>>> UITheme>>newGroupboxIn: aThemedMorph label: aString
>>> "Answer a groupbox with the given label."
>>>
>>> ^GroupboxMorph new
>>> font: self labelFont;
>>> cornerStyle: aThemedMorph preferredCornerStyle;
>>> hResizing: #spaceFill;
>>> vResizing: #spaceFill;
>>> label: aString;
>>> yourself
>>>
>>> Why this is not a creation method on GroupBox?
>>>
>>> Then the trait TeasilyThemed looks suspicious to me.
>>>
>>>
>>>
>>
>> --
>> www.tudorgirba.com
>>
>> "Presenting is storytelling."
>>
>>
>
>

--
www.tudorgirba.com

"What is more important: To be happy, or to make happy?"


Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

Denis Kudriashov
In reply to this post by stephane ducasse
Hello

2013/5/15 stephane ducasse <[hidden email]>
> Hi,
>
> I was rather thinking of having the theme be a composable factory:
> - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory.

Why a factory and not just the morph?

In my Presenty it was my conclusion: prototypes is a way to go.
So instead of

UITheme>>newGroupboxIn: aThemedMorph label: aString
        "Answer a groupbox with the given label."

        ^GroupboxMorph new
                font: self labelFont;
                cornerStyle: aThemedMorph preferredCornerStyle;
                hResizing: #spaceFill;
                vResizing: #spaceFill;
                label: aString;
                yourself

You can get

UITheme>>newGroupboxIn: aThemedMorph label: aString
        ^groupboxMorph veryDeepCopy
                label: aString;
                yourself

And of course you can make prototype morphs as settings and edit it in SettingsBrowser.

In Presenty I gone very far with this idea
Reply | Threaded
Open this post in threaded view
|

Re: [Pharo-dev] about theme and friends

abergel
In reply to this post by Tudor Girba-2
Talking about theme, I just want to say that I like the Glamour theme very much.

Alexandre


On May 14, 2013, at 3:59 PM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> I was rather thinking of having the theme be a composable factory:
> - for each morph, we would have a factory that would know how to work with that morph. In essence for the GroupBoxMorph, we would have the method below in a GroupBoxFactory.
> - the UITheme simply stores all these factories, and the morph looks the factory up via the theme.
> - the UITheme will have no more subclasses.
> - in this way, you can build a theme by taking factories from other themes without overriding everything simply because you can only subclass from one theme.
>
> This design will work better than the settings-inspired one because typically you need to set more than simple properties. For example, you also need to instantiate things (such as a border morph) and this might be more difficult to set from outside.
>
> Cheers,
> Doru
>
>
>
> On May 14, 2013, at 9:24 PM, Stéphane Ducasse <[hidden email]> wrote:
>
>> Looking at the code I have the impression that many UITheme methods should be moved to the their classes
>>
>> Example:
>>
>>
>> UITheme>>newGroupboxIn: aThemedMorph label: aString
>> "Answer a groupbox with the given label."
>>
>> ^GroupboxMorph new
>> font: self labelFont;
>> cornerStyle: aThemedMorph preferredCornerStyle;
>> hResizing: #spaceFill;
>> vResizing: #spaceFill;
>> label: aString;
>> yourself
>>
>> Why this is not a creation method on GroupBox?
>>
>> Then the trait TeasilyThemed looks suspicious to me.
>>
>>
>>
>
> --
> www.tudorgirba.com
>
> "Presenting is storytelling."
>
>

--
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.