- Pharo-dev - lists.pharo.org

Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog

by Gary Chambers

Looking at the changeInformee code in Preferences/Preference, the informee still has to query the preference to pick up any changes as it stands... ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 2:50 PM Subject: Re: [Pharo-project] About Preference Flow: was Re: MonticelloChangesDialog On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote: > Ceratainly possible. You'd want a discovery mechanism for a new > Preference > Browser also, otherwise who would know what the preferences are. no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime. > The method flow would still be similar, unless you had some > redirection to > alternate classes or methods or blocks... No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow. > So, in new scheme (no dependency on Preferences) the doSomething > might be: > > self class shouldUseNewDiffTool > ifTrue: [kjlhkjhjkh ] > ifFalse: [nkjhkjkjhkj] Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools. > > > and > MyTool class>>preferences > > would answer something suitable for a preference browser. Could be but the package could also install the preferences in the preferences class Stef > > > Regards, Gary. > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, February 04, 2009 7:58 AM > Subject: [Pharo-project] About Preference Flow: was Re: Monticello > ChangesDialog > > >> Gary >> >> I have a request about the way we use preference. And this is kind of >> really really important if we want to >> stop having spaghetti code. >> >> Instead of having the current situation ie >> >> MyTool>>doSomething >> >> .... >> Preferences useNewDiffTool >> ifTrue: [kjlhkjhjkh ] >> ifFalse: [nkjhkjkjhkj] >> >> >> and not been able to remove the preferences (or that the preference >> is >> just a configuration layer). >> >> I would like to have the preference made that way >> >> MyTool class>>useNewDiff >> >> MyTool class>> useOldDiff >> >> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >> >> >> Preferences useNewDiffTool >> MyTool useNewDiff >> >> I really think that we can do it that way and this way we would >> have a >> much more object-oriented system >> Do you think that this is possible with polymorph? >> I think so. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 4, 2009

Re: [Pharo-project] A step by step tutorial about Traits

by Alexandre Bergel

I am not aware of such a tutorial. The best is probably to use it. Note that I provided a refactoring "move methods into a new traits" that may help. Just give a try and ask questions :-) We are planning to write such tutorial, but resources (especially time) are quite scarce these days (which is not necessarily a bad thing by the way) Alexandre On 4 Feb 2009, at 17:38, Hilaire Fernandes wrote: > Hi, > > Can someone suggest me a nice traits tutorial to quickly start with > it? > > Thanks > > Hilaire > > -- > http://blog.ofset.org/hilaire > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 4, 2009

[Pharo-project] A step by step tutorial about Traits

by Hilaire Fernandes

Hi, Can someone suggest me a nice traits tutorial to quickly start with it? Thanks Hilaire -- http://blog.ofset.org/hilaire

Feb. 4, 2009

Re: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog

by StÃ©phane Ducasse

On Feb 4, 2009, at 1:11 PM, Gary Chambers wrote: > Ceratainly possible. You'd want a discovery mechanism for a new > Preference > Browser also, otherwise who would know what the preferences are. no because you still define the preference in the Preference class it just pushes the right value in MyTool and MyTool does not have to query Preference at runtime. > The method flow would still be similar, unless you had some > redirection to > alternate classes or methods or blocks... No. We use the preference when we select it. Then MyTool uses what has been pushed to it. and in particular it does not query at runtime preference. So Preference becomes a removal layer on top of the system and not something referenced by every method flow. > So, in new scheme (no dependency on Preferences) the doSomething > might be: > > self class shouldUseNewDiffTool > ifTrue: [kjlhkjhjkh ] > ifFalse: [nkjhkjkjhkj] Yes in mytool I deal the way I want about my preference since they are local to me. I do not involve preference. Preference is just a handy facade grouping all the preferences and an entry point to set the preferences in the tools. > > > and > MyTool class>>preferences > > would answer something suitable for a preference browser. Could be but the package could also install the preferences in the preferences class Stef > > > Regards, Gary. > > ----- Original Message ----- > From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> > To: <Pharo-project(a)lists.gforge.inria.fr> > Sent: Wednesday, February 04, 2009 7:58 AM > Subject: [Pharo-project] About Preference Flow: was Re: Monticello > ChangesDialog > > >> Gary >> >> I have a request about the way we use preference. And this is kind of >> really really important if we want to >> stop having spaghetti code. >> >> Instead of having the current situation ie >> >> MyTool>>doSomething >> >> .... >> Preferences useNewDiffTool >> ifTrue: [kjlhkjhjkh ] >> ifFalse: [nkjhkjkjhkj] >> >> >> and not been able to remove the preferences (or that the preference >> is >> just a configuration layer). >> >> I would like to have the preference made that way >> >> MyTool class>>useNewDiff >> >> MyTool class>> useOldDiff >> >> **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! >> >> >> Preferences useNewDiffTool >> MyTool useNewDiff >> >> I really think that we can do it that way and this way we would >> have a >> much more object-oriented system >> Do you think that this is possible with polymorph? >> I think so. >> >> Stef >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >

Feb. 4, 2009

[Pharo-project] Running SqueakSource on pharo

by Marco D'Ambros

Hi, I am trying to run SqueakSource with Pharo. Using the pharo-dev image, I got squeksource with universe. Then I initialize the SSRepository with the default repository and it worked. What I am not able to do is to make squeaksource available on the web. I did not find any class sending the message #registerAsApplication and I dunno which class is the main component which should be registered to seaside. thanks and cheers Marco

Feb. 4, 2009

Re: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog

by Gary Chambers

Ceratainly possible. You'd want a discovery mechanism for a new Preference Browser also, otherwise who would know what the preferences are. The method flow would still be similar, unless you had some redirection to alternate classes or methods or blocks... So, in new scheme (no dependency on Preferences) the doSomething might be: self class shouldUseNewDiffTool ifTrue: [kjlhkjhjkh ] ifFalse: [nkjhkjkjhkj] and MyTool class>>preferences would answer something suitable for a preference browser. Regards, Gary. ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Wednesday, February 04, 2009 7:58 AM Subject: [Pharo-project] About Preference Flow: was Re: Monticello ChangesDialog > Gary > > I have a request about the way we use preference. And this is kind of > really really important if we want to > stop having spaghetti code. > > Instead of having the current situation ie > > MyTool>>doSomething > > .... > Preferences useNewDiffTool > ifTrue: [kjlhkjhjkh ] > ifFalse: [nkjhkjkjhkj] > > > and not been able to remove the preferences (or that the preference is > just a configuration layer). > > I would like to have the preference made that way > > MyTool class>>useNewDiff > > MyTool class>> useOldDiff > > **NO REFERENCE TO PREFERENCE IN THE METHOD FLOW!!!! > > > Preferences useNewDiffTool > MyTool useNewDiff > > I really think that we can do it that way and this way we would have a > much more object-oriented system > Do you think that this is possible with polymorph? > I think so. > > Stef > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 4, 2009

Re: [Pharo-project] Window buttons

by Gary Chambers

Anyone else for always having tooltips/balloon-help? Regards, Gary. ----- Original Message ----- From: "Damien Cassou" <damien.cassou(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, February 02, 2009 10:02 AM Subject: Re: [Pharo-project] Window buttons > On Sun, Feb 1, 2009 at 12:11 PM, Gary Chambers > <gazzaguru2(a)btinternet.com> wrote: >> Unfortunately the noviceMode preference seems to have disappeared from >> Pharo >> (in Squeak, with that on, you'd get balloon help for the buttons). > > I think this preference is useless in that case. Please provide > tooltips in every cases. On my linux distribition, I've never noticed > them but I've just verified that tooltips are present on these 3 > buttons on all windows. > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 4, 2009

Re: [Pharo-project] Polymorph and OB Browser Colors Quick Solution

by Gary Chambers

With Polymorph use of Text for button labels does work. Not for normal Squeak though... Regards, Gary. ----- Original Message ----- From: "David RÃ¶thlisberger" <squeak(a)webcitas.ch> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Monday, February 02, 2009 11:13 AM Subject: Re: [Pharo-project] Polymorph and OB Browser Colors Quick Solution > Hi Gary, > >> I notice the back/forward buttons are created with a morph as the label. >> Might be better to refactor OBDraggableButton to be under >> PluggableButtonMorphPlus (or implement enablement protocol) and use just >> a string or text, using enablement rather than on/off state - that >> should help avoid use of the hardcoded font. > > ok, I changed the back/forward buttons to be subclasses of > PluggableButtonMorphPlus. > But I did not change the label to just be a string or text, because it > doesn't seem > to be possible to get colored labels for buttons if you don't generate the > string > morph yourself. Because when you pass a text, PluggableButtonMorph just > uses its > string, but not the assigned attributes... > > >> Button bar heights are also a problem if fixed size. >> Similarly, OBButtonModel might benefit from some attention (hence the >> "different" style of the instance/class/traits buttons etc.). These >> buttons also. > > ok, I will check that. > > Thanks, > David > >> ------------------------------------------------------------------------ >> *From:* David RÃ¶thlisberger <squeak(a)webcitas.ch> >> *To:* Pharo-project(a)lists.gforge.inria.fr >> *Sent:* Friday, 30 January, 2009 3:17:46 PM >> *Subject:* Re: [Pharo-project] Polymorph and OB Browser Colors Quick >> Solution >> >> Thanks, Gary, for this new patch. Indeed this works better. :) >> I adapted some parts and committed it for the moment. From the Polymorph >> point of >> view: Is this what you need? >> Because I need to adapt it again as OB does not work properly in Squeak >> now, so I >> would like to know whether it does what you want for Polymorph or not. >> >> It's enough when you load latest OB-Morphic to get it. >> >> David >> >> > Found the correct one now... attached. >> > >> > Regards, Gary. >> > >> > ----- Original Message ----- From: "David RÃ¶thlisberger" >> > <squeak(a)webcitas.ch <mailto:squeak@webcitas.ch>> >> > To: <Pharo-project(a)lists.gforge.inria.fr >> <mailto:Pharo-project@lists.gforge.inria.fr>> >> > Sent: Thursday, January 29, 2009 1:43 PM >> > Subject: Re: [Pharo-project] Polymorph and OB Browser Colors Quick >> Solution >> > >> > >> >> Hi Gary, >> >> >> >>> Not heard from David since I emailed on 30th Dec about getting OB to >> be >> >>> less hardcoded about direct use of model colours, along with having >> >>> buttons changed to PluggableButtonMorphPlus (to use enablement >> rather >> >>> than on/off state to indicate enablement)... >> >> >> >> yep, sorry, I was busy with other stuff. >> >> >> >> But still I'm not sure about the question I sent to you beginning of >> >> this year as an >> >> answer to your mail from the 30th of December: >> >> >> >> "Concerning the first issue about #adoptPaneColor: >> >> In my Squeak 3.9 (and I think also in my latest Pharo) image this >> >> method is already >> >> present in Morph. Is your change therefore needed at all, and if so, >> >> where should we >> >> commit it? I don't think it should be part of OB." >> >> >> >> To give you some more context: You once posted to the mailing list a >> >> CS-patch >> >> containing the #adoptPaneColor: as an OB-extension method for Morph. >> >> But as for me >> >> this method (with the same source code) is already present in Morph, >> I >> >> cannot imagine >> >> that this patch fixes the problem. >> >> I therefore think we should fix this color problem differently. >> >> If you know another solution, please let me know, otherwise I will >> >> dive into it. >> >> >> >> I will in the meantime look at the PluggableButtonMorphPlus issue. >> >> >> >> Cheers, >> >> David >> >> >> >> >> >>> Regards, Gary. >> >>> >> >>> ----- Original Message ----- >> >>> *From:* Rob Rothwell <mailto:r.j.rothwell@gmail.com >> <mailto:r.j.rothwell@gmail.com>> >> >>> *To:* Pharo Development >> <mailto:pharo-project@lists.gforge.inria.fr >> <mailto:pharo-project@lists.gforge.inria.fr>> >> >>> *Sent:* Tuesday, January 27, 2009 11:32 PM >> >>> *Subject:* [Pharo-project] Polymorph and OB Browser Colors Quick >> >>> Solution >> >>> >> >>> I know OB has some issues with the Polymorph themes such that you >> >>> are always left with the standard browser window color border in >> the >> >>> window panes of an OB Browser. >> >>> >> >>> At any rate, a simple "Preferences setPreference: >> >>> #browserWindowColor toValue: (Color r: 0.815 g: 0.811 b: 0.811)" >> >>> seems to set it to a decent color for the Watery2 or Watery >> theme, >> >>> but I was wondering if there is a better place to set something >> like >> >>> this more...dynamically...when different themes are chosen. >> >>> >> >>> Thanks, >> >>> >> >>> Rob >> >>> >> >>> >> >>> >> > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 4, 2009

Re: [Pharo-project] webpage typo

by Adrian Lienhard

On Feb 4, 2009, at 00:42 , Chris Kassopulo wrote: > Phrao is free and open source > on page > http://www.pharo-project.org/license Fixed, thanks for mentioning Adrian > > > nice website > tried the latest pharo-dev image > you guys are amazing > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 4, 2009

Re: [Pharo-project] Seaside?

by Lukas Renggli

>>If you want Seaside 2.9 you should use <http://builder.seaside.st/>. > > Yes - but the builder ONLY allows to create a script for an ALPHA > release (Seaside 2.9.0-alpha2). Yes. > The script in ScriptLoader always loaded the NEWEST packages > so people, who want to help extending and fixing Seaside could > easily load it. It should also make sure that the latest "hot" > Seaside stuff is working in Pharo. This cannot work: 1. Installer initializes packages in random order. 2. Have a look at the LoadOrder page and how many times it changed in the past few months: <http://code.google.com/p/seaside/updates/list>. > Unfortunately since the packages and dependencies change too often > it is hard to maintain such a script. Maybe the builder could be > extended to allow the generation of a "hot build" script. That's too complicated at the moment. > Wish Smalltalk would provide better dependency handling with > appropriate tools like the dep. graph viewer [1] as in Javas Maven. We have the dependency handling. What we don't have is the build server. Cheers, Lukas -- Lukas Renggli http://www.lukas-renggli.ch

Feb. 4, 2009