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

[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

[Pharo-project] Fwd: [squeak-dev] Re: squeak on unix and ucs4 key codes

by StÃ©phane Ducasse

> > > From: stephane ducasse <stephane.ducasse(a)free.fr> > Date: February 4, 2009 9:05:31 AM CEST > To: Pharo Development <Pharo-project(a)lists.gforge.inria.fr> > Subject: Fwd: [squeak-dev] Re: squeak on unix and ucs4 key codes > > > may be something to look at. > > stef > > Begin forwarded message: > >> From: nicolas cellier <ncellier(a)ifrance.com> >> Date: January 31, 2009 3:04:46 PM CEST >> To: squeak-dev(a)lists.squeakfoundation.org >> Subject: [squeak-dev] Re: squeak on unix and ucs4 key codes >> Reply-To: The general-purpose Squeak developers list <squeak-dev(a)lists.squeakfoundation.org >> > >> >> Yoshiki Ohshima a Ã©crit : >>> At Tue, 27 Jan 2009 20:53:31 +0100, >>> Martin Kuball wrote: >>>> Hi! >>>> >>>> Can someone please tell me how to make squeak play nice with the >>>> keyevents generated by the new unix VM. I'm really fed up with >>>> this "subscript is out of bounds" error messages (where subscript >>>> is <= 0). >>>> >>>> I don't care if it is some change in the smalltalk code or if I >>>> have to disable something in the c-code before compiling. >>> What image are you using? The image side code should look at the >>> proper entry(-ies) in the event buffer (at: 6, but if it is zero, >>> at: >>> 3). Look at (for example) the Etoys image. >>> -- Yoshiki >> >> Hello Martin, >> I presume this has something to do with http://bugs.squeak.org/view.php?id=7071 >> Maybe you'd like to load Yoshiki fixes in your image. >> Executing this code in a workspace might help: >> Installer ensureFix: 7071. >> Cheers >> >> Nicolas >> >> >> > > > >

Feb. 4, 2009

[Pharo-project] Seaside?

by Torsten Bergmann

Lukas wrote: >That script does not load an "official" set of packages. To me it does >not look like it works. It worked - but it is broken again due to various dependency changes in the Seaside packages and time does not permit to update it on a daily/weekly basis. Therefore we should either drop it or Seasiders should help maintaining it. >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). 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. 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. Wish Smalltalk would provide better dependency handling with appropriate tools like the dep. graph viewer [1] as in Javas Maven. Bye T. [1] http://docs.codehaus.org/display/MAVEN/Developing+Maven+2.1 -- Jetzt 1 Monat kostenlos! GMX FreeDSL - Telefonanschluss + DSL fÃ¼r nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a

Feb. 4, 2009

Re: [Pharo-project] webpage typo

by StÃ©phane Ducasse

Hi chris We would not exist if Squeak would not have and we will always remember that and thanks Alan and his group for all the great stuff **they** did. But we had to reconsider some ideas and practices :) Now in a couple of years we will be truly better than now. Stef On Feb 4, 2009, at 12:42 AM, Chris Kassopulo wrote: > Phrao is free and open source > on page > http://www.pharo-project.org/license > > 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

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

by StÃ©phane Ducasse

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

Feb. 4, 2009