Ideally I would like to have pharo and squeak versions separated (may be the packages should have a OB-Squeak and OB-Pharo). else we will never make real progress. Stef
> Hi all, > > We have to make important decisions about squeak/pharo compatibility > regarding the new setting package. > The problem is that some packages (as Polymorph but also OB, > ecompletion and certainly a lot of others) are > included in pharo (aka pharo-dev) but are also used by squeak and > the compatibility is now an issue because we plan > to remove the Preferences class from Pharo. > So, I'm looking for advices about that... > Any feedback ? > > Cheers > Alain > > From: Alain Plantec <[email protected]> > Date: May 27, 2009 7:21:25 PM CEDT > To: Gary Chambers <[email protected]> > Subject: Re: preferences refactoring > Reply-To: [email protected] > > > Gary Chambers a écrit : >> Hi Alain. >> >> I guess I may have to fork the Pharo/Squeak specific areas. Not an >> easy job! > yes, not really cool. > > what about the following: > I make the assumption that DiffMorph is using the > browseWithPrettyPrint preference. > For pharo, you can create a new package with a PolymorphSettings > class: > > ---------------------- > PolymorphSettings class>>browseWithPrettyPrint > <setting> > ^ BrowseWithPrettyPrint ifNil: [ BrowseWithPrettyPrint := > (SettingManager newSetting: 'bla bla') ... ] > > PolymorphSettings class>>initialize > self browseWithPrettyPrint whenChangedSend: #prettyPrinting: to: > DiffMorph > ---------------------- > > For squeak you can also create a new package with a > PolymorphPreferences class: > > ---------------------- > PolymorphPreferences class>>initialize > (Preferences preferenceAt: #browseWithPrettyPrint) ifNil:[ > Preferences > addPreference: #browseWithPrettyPrint > categories: #(browsing) > default: true > balloonHelp: 'Enable, or ...'. > (Preferences preferenceAt: browseWithPrettyPrint) > changeInformee: self > changeSelector: #browseWithPrettyPrintChanged. > self browseWithPrettyPrintChanged]. > PolymorphPreferences class>>browseWithPrettyPrintChanged > DiffMorph prettyPrinting: Preferences browseWithPrettyPrint > > ---------------------- > > and as you pointed out, DiffMorph has also its own class variable > for the preference. > > DiffMorph class>>prettyPrinting: aBoolean > PrettyPrinting := aBoolean > > DiffMorph class>>prettyPrinting > ^ PrettyPrinting > > > Thus, in Pharo PolymorphSettings is loaded and the DiffMorph class > variable changes are handled via the setting. > In Squeak, PolymorphPreferences is loaded and the DiffMorph class > variable updating relies on the changeInformee hook. > > a little bit ugly but I guess this is the price to pay for > compatibility. > > what do you think ? > > Cheers > Alain >> >> To start I'll refactor Polymorph to use class side accessors for >> any use of preferences. That way Squeak can delegate to Preferences >> whilst Pharo can use the pragma based settings. >> >> E.g. >> DiffMorph>>setText can do >> >> self class colorWhenPrettyPrinting value >> >> In Squeak: >> >> DiffMorph class>>colorWhenPrettyPrinting >> ^Preferences colorWhenPrettyPrinting >> >> In Pharo: >> >> DiffMorph class>>colorWhenPrettyPrinting >> ^ColorWhenPrettyPrinting ifNil: [ >> ColorWhenPrettyPrinting := (SettingManager newSetting: 'Color >> pretty print') default: false] >> >> Regards, Gary >> >> ----- Original Message ----- From: "Alain Plantec" >> <[email protected] >> > >> To: "Gary Chambers" <[email protected]> >> Sent: Friday, May 22, 2009 3:56 PM >> Subject: preferences refactoring >> >> >>> Hi Gary, >>> During the migration from old preferences to the new setting >>> framework, >>> some methods I'm changing can be from Polymorph packages. >>> I just like to know if I have to send to you polymorph specific >>> parts ? >>> or what is the rule ? >>> As an example, DiffMorph>>setText will be touched by the removal >>> of the #colorWhenPrettyPrinting >>> preference. Do I have to send to you a Polymorph specific part ? >>> Thanks >>> Alain >> >> >> > > > > > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
