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 <[hidden email]> wrote: esteban |
On May 14, 2013, at 5:13 PM, Benjamin <[hidden email]> wrote:
No registration about tools. UITheme does not deal with that. The current theme should push to all the widgets that the defaultColor is blue.
|
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:
|
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
|
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. |
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." |
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 |
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. |
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 > |
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 |
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:
|
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." > > |
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?" |
In reply to this post by stephane ducasse
Hello
2013/5/15 stephane ducasse <[hidden email]>
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 |
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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. |
Free forum by Nabble | Edit this page |