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
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 <stephane.ducasse@inria.fr> 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
On May 14, 2013, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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 <stephane.ducasse@inria.fr> 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
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 <stephane.ducasse@free.fr> wrote:
On May 14, 2013, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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 <stephane.ducasse@inria.fr> 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
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 ----- From: Benjamin To: Discusses Development of Pharo 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 <stephane.ducasse@free.fr> wrote: On May 14, 2013, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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 <stephane.ducasse@inria.fr> 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
On May 14, 2013, at 5:36 PM, Gary Chambers <gazzaguru2@btinternet.com> 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 ----- From: Benjamin To: Discusses Development of Pharo 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 <stephane.ducasse@free.fr> wrote:
On May 14, 2013, at 5:13 PM, Benjamin <benjamin.vanryseghem.pharo@gmail.com> 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 <stephane.ducasse@inria.fr> 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
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.
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 <stephane.ducasse@inria.fr> 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."
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:dennis.groves@owasp.org) 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
On May 14, 2013, at 10:04 PM, "Dennis Groves" <dennis.groves@gmail.com> 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.
On May 14, 2013, at 10:03 PM, Dennis Groves <dennis.groves@gmail.com> 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:dennis.groves@owasp.org) 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
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 <stephane.ducasse@inria.fr> 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."
Hi, On May 14, 2013, at 10:18 PM, stephane ducasse <stephane.ducasse@free.fr> 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 <stephane.ducasse@inria.fr> 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?"
Hello 2013/5/15 stephane ducasse <stephane.ducasse@free.fr>
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
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 <tudor@tudorgirba.com> 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 <stephane.ducasse@inria.fr> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
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 <Stephane.Ducasse@inria.fr> 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
participants (9)
-
Alexandre Bergel -
Benjamin -
Denis Kudriashov -
Dennis Groves -
Gary Chambers -
Marcus Denker -
stephane ducasse -
Stéphane Ducasse -
Tudor Girba