There is a Growl in Pharo. I improved it :) Stef On Feb 15, 2012, at 12:42 PM, Camillo Bruni wrote:

gargl....

we should have some non-interactive inform: like Growl on Mac. The popups should just open but not block the interaction IMO.

On 2012-02-14, at 23:50, Igor Stasenko wrote:

...

i started tests and leaved image for a while, but when i went back hoping that it already finished, i discovered that it waiting for me to press ok and did not ran even 20% of all tests.

Somewhere in GoferOperationTest>>testMerge it says 'No changes' and waits for the user to press 'ok'

-- Best regards, Igor Stasenko.

On Feb 15, 2012, at 1:47 PM, Tudor Girba wrote:

Indeed, this is a project that is since too long on my to do list.

I worked on Growl a bit as well, but we need to bring it further. I just pushed the to do towards the top of the list :) I would be happy to collaborate on this issue.

Would be good. Doru could you fix the fact that if I remember correctly you make it dependent on the UIManager? or something like that? But we could really add it to the image so that we have vanishing messages :)

Cheers, Doru

On Wed, Feb 15, 2012 at 1:38 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

There is a Growl in Pharo. I improved it :)

Stef

On Feb 15, 2012, at 12:42 PM, Camillo Bruni wrote:

...

gargl....

we should have some non-interactive inform: like Growl on Mac. The popups should just open but not block the interaction IMO.

On 2012-02-14, at 23:50, Igor Stasenko wrote:

...

i started tests and leaved image for a while, but when i went back hoping that it already finished, i discovered that it waiting for me to press ok and did not ran even 20% of all tests.

Somewhere in GoferOperationTest>>testMerge it says 'No changes' and waits for the user to press 'ok'

-- Best regards, Igor Stasenko.

-- www.tudorgirba.com

"Every thing has its own flow"

On Feb 15, 2012, at 1:58 PM, Tudor Girba wrote:

Hi,

It's not UIManager, but UITheme. I made it dependent on the UITheme in the sense that I moved all the rendering code as an extension. I thought this is the official way to get things working with Polymorph. Did I get it wrong?

I do not know. I'm still confused by the responsibility of UITheme vs UIManager vs… Now you do not want that every tools add method to UITheme because imagine that we do that then how each theme can be modular? so far I do not have the right answer. Now GrowlMorph should have setting and get initialized from the UITheme settings

Cheers, Doru

On Wed, Feb 15, 2012 at 1:54 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Feb 15, 2012, at 1:47 PM, Tudor Girba wrote:

...

Indeed, this is a project that is since too long on my to do list.

I worked on Growl a bit as well, but we need to bring it further. I just pushed the to do towards the top of the list :) I would be happy to collaborate on this issue.

Would be good. Doru could you fix the fact that if I remember correctly you make it dependent on the UIManager? or something like that? But we could really add it to the image so that we have vanishing messages :)

...

Cheers, Doru

On Wed, Feb 15, 2012 at 1:38 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

There is a Growl in Pharo. I improved it :)

Stef

On Feb 15, 2012, at 12:42 PM, Camillo Bruni wrote:

...

gargl....

we should have some non-interactive inform: like Growl on Mac. The popups should just open but not block the interaction IMO.

On 2012-02-14, at 23:50, Igor Stasenko wrote:

...

i started tests and leaved image for a while, but when i went back hoping that it already finished, i discovered that it waiting for me to press ok and did not ran even 20% of all tests.

Somewhere in GoferOperationTest>>testMerge it says 'No changes' and waits for the user to press 'ok'

-- Best regards, Igor Stasenko.

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

Hi, I am not sure I understand, so let's get more specific. We talk about one package which contains one Morph. I thought the purpose of UITheme is to encapsulate all decisions related to how a morph gets rendered. It's like a strategy. For example, we have UITheme>>plainGroupPanelBorderStyleFor: and this is called by the PlainGroupboxMorph. In the same style, I have: UITheme>>growlLabelColorFor: aGrowlMorph ^ Color white GrowlMorph>>labelColor ^ self theme growlLabelColorFor: self Is this not the intended way? Doru On 15 Feb 2012, at 18:04, Igor Stasenko wrote:

On 15 February 2012 17:02, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Feb 15, 2012, at 1:58 PM, Tudor Girba wrote:

...

Hi,

It's not UIManager, but UITheme. I made it dependent on the UITheme in the sense that I moved all the rendering code as an extension. I thought this is the official way to get things working with Polymorph. Did I get it wrong?

I do not know. I'm still confused by the responsibility of UITheme vs UIManager vs… Now you do not want that every tools add method to UITheme because imagine that we do that then how each theme can be modular?

Imo, it is simple: the right to use ui theme should have only those object, which actually responsible for ui: widgets and perhaps ui builders. The rest of world should assume UITheme not exists.

...

so far I do not have the right answer. Now GrowlMorph should have setting and get initialized from the UITheme settings

...

Cheers, Doru

On Wed, Feb 15, 2012 at 1:54 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

On Feb 15, 2012, at 1:47 PM, Tudor Girba wrote:

...

Indeed, this is a project that is since too long on my to do list.

I worked on Growl a bit as well, but we need to bring it further. I just pushed the to do towards the top of the list :) I would be happy to collaborate on this issue.

Would be good. Doru could you fix the fact that if I remember correctly you make it dependent on the UIManager? or something like that? But we could really add it to the image so that we have vanishing messages :)

...

Cheers, Doru

On Wed, Feb 15, 2012 at 1:38 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

There is a Growl in Pharo. I improved it :)

Stef

On Feb 15, 2012, at 12:42 PM, Camillo Bruni wrote:

...

gargl....

we should have some non-interactive inform: like Growl on Mac. The popups should just open but not block the interaction IMO.

On 2012-02-14, at 23:50, Igor Stasenko wrote:

...

i started tests and leaved image for a while, but when i went back hoping that it already finished, i discovered that it waiting for me to press ok and did not ran even 20% of all tests.

Somewhere in GoferOperationTest>>testMerge it says 'No changes' and waits for the user to press 'ok'

-- Best regards, Igor Stasenko.

-- www.tudorgirba.com

"Every thing has its own flow"

-- www.tudorgirba.com

"Every thing has its own flow"

-- Best regards, Igor Stasenko.

-- www.tudorgirba.com Innovation comes in least expected form. That is, if it is expected, it already happened.

On 15 February 2012 21:18, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:

...

I am not sure I understand, so let's get more specific. We talk about one package which contains one Morph.

I thought the purpose of UITheme is to encapsulate all decisions related to how a morph gets rendered. It's like a strategy.

For example, we have UITheme>>plainGroupPanelBorderStyleFor: and this is called by the PlainGroupboxMorph.

In the same style, I have: UITheme>>growlLabelColorFor: aGrowlMorph       ^ Color white GrowlMorph>>labelColor       ^ self theme growlLabelColorFor: self

Is this not the intended way?

I do not know :) Because if we generalize that to all the widgets UITheme will explode. And you cannot use a widget without a theme. Then you always asks the theme. I do not like that

       - Do we want UITheme to be a facade?        - Is UITheme our new preference class?        - I would prefer to get something like setting                - GrowlMorph has a class Var for its labelColor                - and somehow The UITheme push its value inside                        may be the GrowlMorph initialize ask the theme or something like that.                - may each UI could register to the UItheme and the UItheme propagate its changes by saying to the widgets                        I changed ask me what you need.                        and the widget say I need these values.

Now I do not see how Uitheme defining the logic of a widget can scale.

Now I'm trying to understand the flow and architecture that the system could have. So we should get some more exercises to see.

Yes, different themes can be aware about new widget(s) or not.. I think then we should have some safe way of querying theme GrowlMorph>>labelColor ^ self theme setting: #growlLabelColor default: self defaultColor Can't say that i like this "pulling" model, querying theme over and over again.. I think it would be much nicer to actually use push model, i.e. let theme push a props to widget, and do it once at initialization stage: Morph>>initialize .... self applyThemeSettings Morph>>applyThemeSettings self theme applySettings: self class name to: self defaults: self applyDefaultSettings. Morph>>applyDefaultSettings "do nothing, subclasses may do otherwise" so, now if theme has some settings for new kid on the block (like GrowlMorph), it will apply it directly to newly created widget, if not, then widget will apply own defaults. So, then all the #labelColor can be turned into simple: GrowlMorph>>labelColor ^ labelColor (or #propertyAt: .., if you don't like inst vars) whatever. A good reason to have defaults, that it is actually serves as a guide for theme makers, what properties affecting widget appearance/behavior. Yeah.. but it will require a bit of refactoring :) -- Best regards, Igor Stasenko.

On 16 February 2012 13:53, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

On Feb 16, 2012, at 12:52 PM, Igor Stasenko wrote:

Can't say that i like this "pulling" model, querying theme over and over again.. I think it would be much nicer to actually use push model, i.e. let theme push a props to widget,

IIRC from what Gary has posted, it was done that way to easily: 1) have morphs respond to a theme change. (since they fetch values from the theme each draw cycle) 2) not have to hold the state in each individual morph.

Now: 1) should be much easier/cleaner to do using Announcements. 2) is still an issue. However, since most calls create new objects (the different Theme colors are usually created from scratch each call, for instance), and writing it to include caching also leads to ugly code, it might not be as bad.

As for adding values for new widgets - Why do you need a specific label color for growl rather than use the default theme label color? - If you really do, why not use one of the base label colors from the theme (as presented by the facade), and then modify it accordingly instead? (#lighter, #darker, etc)

Yes, status-quo. I agree, that most of the time widgets should use base set of colors (what they are . btw?) provided by theme. But it is not always possible, since some widget could have absolutely unique properties, which cannot be synthesized from any other properties. For example, speaking about Growl morph, it could have settings controlled by theme like: - in what corner of screen to pop up - after how many seconds it should start to fade - should it fade or just disappear immediately - and how long it should fade. So, as you can see, there's nothing in existing themes which you use and apply #lighter/#darker ;) to get these properties. And of course a good widget is one, which has many properties which you can control.

Of course, with the current "query every draw cycle"-scheme, this is wasteful, but if we move to a "locally-managed/responding to Theme changes" the overhead would be negligible. It's still quite a lot of work though.

Cheers, Henry

-- Best regards, Igor Stasenko.

On 16 February 2012 14:20, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

On Feb 16, 2012, at 2:05 PM, Igor Stasenko wrote:

...

On 16 February 2012 13:53, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:

...

On Feb 16, 2012, at 12:52 PM, Igor Stasenko wrote:

Can't say that i like this "pulling" model, querying theme over and over again.. I think it would be much nicer to actually use push model, i.e. let theme push a props to widget,

IIRC from what Gary has posted, it was done that way to easily: 1) have morphs respond to a theme change. (since they fetch values from the theme each draw cycle) 2) not have to hold the state in each individual morph.

Now: 1) should be much easier/cleaner to do using Announcements. 2) is still an issue. However, since most calls create new objects (the different Theme colors are usually created from scratch each call, for instance), and writing it to include caching also leads to ugly code, it might not be as bad.

As for adding values for new widgets - Why do you need a specific label color for growl rather than use the default theme label color? - If you really do, why not use one of the base label colors from the theme (as presented by the facade), and then modify it accordingly instead? (#lighter, #darker, etc)

Yes, status-quo. I agree, that most of the time widgets should use base set of colors (what they are . btw?) provided by theme. But it is not always possible, since some widget could have absolutely unique properties, which cannot be synthesized from any other properties. For example, speaking about Growl morph, it could have settings controlled by theme like: - in what corner of screen to pop up - after how many seconds it should start to fade - should it fade or just disappear immediately - and how long it should fade. Again, if they are fully unique, then why are you consulting a Theme in the first place?

because you want them to be themeable, what else? :)

Cheers, Henry

-- Best regards, Igor Stasenko.