February 2012 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] annoying press "ok" when running tests (not headless)

by Henrik Johansen

On Feb 16, 2012, at 2:20 PM, Henrik Johansen wrote: > > On Feb 16, 2012, at 2:05 PM, Igor Stasenko wrote: > >> On 16 February 2012 13:53, Henrik Johansen <henrik.s.johansen(a)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? > By which I mean; A Theme provides an API to a consistent look and feel (color scheme, roundness of widgets etc). As for what you specified, either that IS specific to the Growl Morph, and should therefore be contained in the growl morph (with appropriate settings), or you encase in the theme settings related to generic *pop-up* behavior. I just don't see the use of providing styling info like #growlLabelColor from a *Theme*, for the same reason I don't think #debuggerScrollbarThickness would be an appropriate thing to ask of a Theme. Cheers, Henry

Feb. 16, 2012

Re: [Pharo-project] Nautilus Refactorings

by S Krish

Absolutely.. it is better.. I do have a small personal implementation that allows me the luxury of not registering the change.. when halt is inserted.. but I agree there is no two opinions.. Toggle breakpoint if it works perfectly it will be the best but I have both issues: * The long methods in which I put Toggle breakpoint loses the sense of what line it is on .. jumps around.. very annoying there.. * Instability of painting.. I am not sure if I can pin point anything.. but has occurred almost only when I use this through Morphic UI construction.. The hack I have is temporary.. but also allows me to insert the self halt anywhere in the method code at the point I right click in the method and insert it ( sensibly though.. ). Till the Toggle breakpoint works perfectly. On Thu, Feb 16, 2012 at 6:46 PM, Luc Fabresse <luc.fabresse(a)gmail.com>wrote: > > > 2012/2/16 S Krish <krishnamachari.sudhakar(a)gmail.com> > >> Toggle Breakpoint, my experience in last one month in Morphic projects is >> causing instability.. >> >> I prefer the self halt, that is comparatively rock stable.. I have never >> had the image crash out or cause unpredictable paint etc.. >> > > I think, it would be better to have a working toggle breakpoint which > doesn't produce a new version of the compiled method (less garbage in > methods' versions). > > Luc > > >> >> >> On Thu, Feb 16, 2012 at 4:17 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: >> >>> I miss running and debugging a single test from Nautilus (the current >>> right-click menu on a method says 'Run Tests', plural, but maybe it only >>> run the selected). >>> >>> And the simple Toggel Breakpoint stuff, I hate modifying methods with >>> self halt just to have a look at what is happening. >>> >>> On 16 Feb 2012, at 11:36, Benjamin wrote: >>> >>> > Me too, it's one of my favorite :) >>> > >>> > >>> > This one, and the red icon for uncommented classes :) >>> > >>> > They are the two features which really have changed my way of working. >>> > >>> > >>> > Ben >>> > >>> > >>> > On Feb 16, 2012, at 10:27 AM, Sven Van Caekenberghe wrote: >>> > >>> >> >>> >> On 16 Feb 2012, at 10:15, Luc Fabresse wrote: >>> >> >>> >>> And I forget to say that I didn't get why the background of some >>> methods is yellow? >>> >> >>> >> Method too long, I love this feature! >>> > >>> > >>> >>> >>> >> >

Feb. 16, 2012

Re: [Pharo-project] annoying press "ok" when running tests (not headless)

by Igor Stasenko

On 16 February 2012 14:20, Henrik Johansen <henrik.s.johansen(a)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(a)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.

Feb. 16, 2012

Re: [Pharo-project] annoying press "ok" when running tests (not headless)

by Henrik Johansen

On Feb 16, 2012, at 2:05 PM, Igor Stasenko wrote: > On 16 February 2012 13:53, Henrik Johansen <henrik.s.johansen(a)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? Cheers, Henry

Feb. 16, 2012

Re: [Pharo-project] Nautilus Refactorings

by Luc Fabresse

2012/2/16 S Krish <krishnamachari.sudhakar(a)gmail.com> > Toggle Breakpoint, my experience in last one month in Morphic projects is > causing instability.. > > I prefer the self halt, that is comparatively rock stable.. I have never > had the image crash out or cause unpredictable paint etc.. > I think, it would be better to have a working toggle breakpoint which doesn't produce a new version of the compiled method (less garbage in methods' versions). Luc > > > On Thu, Feb 16, 2012 at 4:17 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > >> I miss running and debugging a single test from Nautilus (the current >> right-click menu on a method says 'Run Tests', plural, but maybe it only >> run the selected). >> >> And the simple Toggel Breakpoint stuff, I hate modifying methods with >> self halt just to have a look at what is happening. >> >> On 16 Feb 2012, at 11:36, Benjamin wrote: >> >> > Me too, it's one of my favorite :) >> > >> > >> > This one, and the red icon for uncommented classes :) >> > >> > They are the two features which really have changed my way of working. >> > >> > >> > Ben >> > >> > >> > On Feb 16, 2012, at 10:27 AM, Sven Van Caekenberghe wrote: >> > >> >> >> >> On 16 Feb 2012, at 10:15, Luc Fabresse wrote: >> >> >> >>> And I forget to say that I didn't get why the background of some >> methods is yellow? >> >> >> >> Method too long, I love this feature! >> > >> > >> >> >> >

Feb. 16, 2012

Re: [Pharo-project] Nautilus Refactorings

by S Krish

Toggle Breakpoint, my experience in last one month in Morphic projects is causing instability.. I prefer the self halt, that is comparatively rock stable.. I have never had the image crash out or cause unpredictable paint etc.. On Thu, Feb 16, 2012 at 4:17 PM, Sven Van Caekenberghe <sven(a)beta9.be>wrote: > I miss running and debugging a single test from Nautilus (the current > right-click menu on a method says 'Run Tests', plural, but maybe it only > run the selected). > > And the simple Toggel Breakpoint stuff, I hate modifying methods with self > halt just to have a look at what is happening. > > On 16 Feb 2012, at 11:36, Benjamin wrote: > > > Me too, it's one of my favorite :) > > > > > > This one, and the red icon for uncommented classes :) > > > > They are the two features which really have changed my way of working. > > > > > > Ben > > > > > > On Feb 16, 2012, at 10:27 AM, Sven Van Caekenberghe wrote: > > > >> > >> On 16 Feb 2012, at 10:15, Luc Fabresse wrote: > >> > >>> And I forget to say that I didn't get why the background of some > methods is yellow? > >> > >> Method too long, I love this feature! > > > > > > >

Feb. 16, 2012

Re: [Pharo-project] annoying press "ok" when running tests (not headless)

by Igor Stasenko

On 16 February 2012 13:53, Henrik Johansen <henrik.s.johansen(a)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.

Feb. 16, 2012

Re: [Pharo-project] Nautilus Refactorings

by GastÃ³n Dall' Oglio

Hi Benjamin. Nautilus is really cool, congrats! Is possibly extract the methods comments (comments in the first lines of methods)? If possible, when I see a method, in the comment pane added to the current class comment, I want to can see the related comments. Related how? Well... * One posibility is the comments of the overwritten methods (same method name in the superclasses), that often have very important information for the correct or convenient manner of overwrite them. Maybe having an option in the setting to indicated how many comments to show. For example in Seaside, often I override a method, and there are tons of very important documentation in the overwritten methods comments, then I have to go in the hierarchy one and again for see them. * Another posibility is show the comments of invoked methods, when is can determinate of course, for example self sends... In this manner, I haven't to go in every method invocation to see that it does. Again, maybe a option in settings... * Another? My 2 cents Thanks a lot. 2012/2/16 Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> > Me too, it's one of my favorite :) > > > This one, and the red icon for uncommented classes :) > > They are the two features which really have changed my way of working. > > > Ben > > > On Feb 16, 2012, at 10:27 AM, Sven Van Caekenberghe wrote: > > > > > On 16 Feb 2012, at 10:15, Luc Fabresse wrote: > > > >> And I forget to say that I didn't get why the background of some > methods is yellow? > > > > Method too long, I love this feature! > > >

Feb. 16, 2012

Re: [Pharo-project] annoying press "ok" when running tests (not headless)

by Henrik Johansen

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) 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

Feb. 16, 2012

Re: [Pharo-project] annoying press "ok" when running tests (not headless)

by Igor Stasenko

On 15 February 2012 21:18, StÃ©phane Ducasse <stephane.ducasse(a)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.

Feb. 16, 2012