Preferences removal Re: [update 1.2] #12092
Locked
Preferences removal Re: [update 1.2] #12092
 
|
On Sun, Aug 15, 2010 at 1:48 PM, Marcus Denker <[hidden email]> wrote: 12092 The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. I mean...is there a mapping between each previous preference a the new ones? Cheers Mariano Marcus _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote:
What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preference class return true or false for that preference. That should be 90% of all usages, I guess.. We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g. compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...).
But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I think not really what we want. One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removing unsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... Marcus -- Marcus Denker -- http://www.marcusdenker.de INRIA Lille -- Nord Europe. Team RMoD. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
On Sunday, August 15, 2010, Marcus Denker <[hidden email]> wrote:
> > On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote: > > > But I think we should add back a Preferences class for allowing to load old code. (it's referenced > in the class side initialize in old code often...) Please don't add such a fake classes, it just makes everything more difficult and less functional. People should not use outdated code, and if they do they should be able to fix it themselves. I am fixing right now the remaining references in OB and Shout (RB and eCompletion are already fixed). Lukas > > > The problem are the external pacakges. I have 100 references to Preferences in Pharo dev....almost EVERY external package uses Preferences. > So....we really need help of the external package maintainers to update them. And I am not sure how easy is that. > What should be easy is to have a Preferences class that supports the simple API that everyone was using: add a preference. And make Preferenceclass return true or false for that preference. That should be 90% of all usages, I guess.. > We can do that by just having a dictionary and overriding doesNotUnderstand:. We should not provide all this magic that used to be there, e.g.compiling on the fly methods for accessed perferences (which funnily had an empty source pointer...). > I mean...is there a mapping between each previous preference a the new ones? > > > In 1.1, Preferences are returning the values from the Settings framework for backward compatibillity. > But I don't think that Preferences added are shown in the Settings? This would require Settings to be generated, which is possible but I thinknot really what we want. > One could of course build this specification for the Preferences... and maybe there was even code there for that ;-) I started the cleanup bu removingunsent messages... but after a while that got really boring. And Preferences was a near 2000 LOC abdomination of a class. > I checked in 1.1Dev, and most of the references are from the Core, which we removed in 1.2... > Marcus > > > --Marcus Denker -- http://www.marcusdenker.de <http://www.marcusdenker.de/> > INRIA Lille -- Nord Europe. Team RMoD. > > > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
On Sun, Aug 15, 2010 at 2:58 PM, Lukas Renggli <[hidden email]> wrote:
Lukas, Shout won't load in Pharo 1.2 because of issue http://code.google.com/p/pharo/issues/detail?id=2734 :( Lukas _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
Name: Refactoring-Core-lr.149
Author: lr Time: 15 August 2010, 5:18:09 pm UUID: 27652b7f-9069-49e2-ad79-b6c3ecb077d9 Ancestors: Refactoring-Core-lr.148 - removed all references to Preferences Name: ShoutWorkspace-lr.7 Author: lr Time: 15 August 2010, 5:20:07 pm UUID: 851aa393-9367-4731-b695-1bcec55add0c Ancestors: ShoutWorkspace-lr.6 - removed all references to Preferences Name: Shout-lr.86 Author: lr Time: 15 August 2010, 5:20:53 pm UUID: 07aa43a8-8669-4cc8-b5a7-e8c8f002adfd Ancestors: Shout-lr.85 - removed all references to Preferences (next is to add settings for the format, but that requires quite some heavy changes) Name: OmniBrowser-lr.487 Author: lr Time: 15 August 2010, 5:25:43 pm UUID: fc4947b3-c23c-4cbb-a7af-7876306dc8de Ancestors: OmniBrowser-lr.486 - removed all references to Preferences Name: OB-Standard-lr.488 Author: lr Time: 15 August 2010, 5:26:21 pm UUID: 8a31228c-89e8-4450-8408-9d47576d9db5 Ancestors: OB-Standard-lr.487 - removed all references to Preferences Name: OB-Tests-Core-lr.83 Author: lr Time: 15 August 2010, 5:26:43 pm UUID: 8ebb0466-c329-4eaa-a5a9-9e1114cf5da2 Ancestors: OB-Tests-Core-lr.82 - removed all references to Preferences Name: OB-Tests-Morphic-lr.28 Author: lr Time: 15 August 2010, 5:27:19 pm UUID: 043cf6f5-a9dd-4c9e-8846-fe43a280de07 Ancestors: OB-Tests-Morphic-lr.27 - removed all references to Preferences Name: OB-Tests-Standard-lr.115 Author: lr Time: 15 August 2010, 5:27:39 pm UUID: 3459c99b-df43-4ad9-b277-e579ff5a9bff Ancestors: OB-Tests-Standard-lr.114 - removed all references to Preferences 2010/8/15 Mariano Martinez Peck <[hidden email]>: > > > On Sun, Aug 15, 2010 at 2:58 PM, Lukas Renggli <[hidden email]> wrote: >> >> On Sunday, August 15, 2010, Marcus Denker <[hidden email]> wrote: >> > >> > On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote: >> > >> > >> > But I think we should add back a Preferences class for allowing to load >> > old code. (it's referenced >> > in the class side initialize in old code often...) >> >> Please don't add such a fake classes, it just makes everything more >> difficult and less functional. People should not use outdated code, >> and if they do they should be able to fix it themselves. >> >> I am fixing right now the remaining references in OB and Shout (RB and >> eCompletion are already fixed). >> > > Lukas, Shout won't load in Pharo 1.2 because of issue > > http://code.google.com/p/pharo/issues/detail?id=2734 > > :( > >> >> Lukas >> >> > >> > >> > The problem are the external pacakges. I have 100 references to >> > Preferences in Pharo dev....almost EVERY external package uses Preferences. >> > So....we really need help of the external package maintainers to update >> > them. And I am not sure how easy is that. >> > What should be easy is to have a Preferences class that supports the >> > simple API that everyone was using: add a preference. And make >> > Preferenceclass return true or false for that preference. That should be 90% >> > of all usages, I guess.. >> > We can do that by just having a dictionary and overriding >> > doesNotUnderstand:. We should not provide all this magic that used to be >> > there, e.g.compiling on the fly methods for accessed perferences (which >> > funnily had an empty source pointer...). >> > I mean...is there a mapping between each previous preference a the new >> > ones? >> > >> > >> > In 1.1, Preferences are returning the values from the Settings framework >> > for backward compatibillity. >> > But I don't think that Preferences added are shown in the Settings? This >> > would require Settings to be generated, which is possible but I thinknot >> > really what we want. >> > One could of course build this specification for the Preferences... and >> > maybe there was even code there for that ;-) I started the cleanup bu >> > removingunsent messages... but after a while that got really boring. And >> > Preferences was a near 2000 LOC abdomination of a class. >> > I checked in 1.1Dev, and most of the references are from the Core, which >> > we removed in 1.2... >> > Marcus >> > >> > >> > --Marcus Denker >> > -- http://www.marcusdenker.de <http://www.marcusdenker.de/> >> > INRIA Lille -- Nord Europe. Team RMoD. >> > >> > >> > >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
coooooooooooooooooool
probably to be put in configurationOf for pharo1.2 Stef On Aug 15, 2010, at 5:28 PM, Lukas Renggli wrote: > Name: Refactoring-Core-lr.149 > Author: lr > Time: 15 August 2010, 5:18:09 pm > UUID: 27652b7f-9069-49e2-ad79-b6c3ecb077d9 > Ancestors: Refactoring-Core-lr.148 > > - removed all references to Preferences > > Name: ShoutWorkspace-lr.7 > Author: lr > Time: 15 August 2010, 5:20:07 pm > UUID: 851aa393-9367-4731-b695-1bcec55add0c > Ancestors: ShoutWorkspace-lr.6 > > - removed all references to Preferences > > Name: Shout-lr.86 > Author: lr > Time: 15 August 2010, 5:20:53 pm > UUID: 07aa43a8-8669-4cc8-b5a7-e8c8f002adfd > Ancestors: Shout-lr.85 > > - removed all references to Preferences (next is to add settings for > the format, but that requires quite some heavy changes) > > Name: OmniBrowser-lr.487 > Author: lr > Time: 15 August 2010, 5:25:43 pm > UUID: fc4947b3-c23c-4cbb-a7af-7876306dc8de > Ancestors: OmniBrowser-lr.486 > > - removed all references to Preferences > > Name: OB-Standard-lr.488 > Author: lr > Time: 15 August 2010, 5:26:21 pm > UUID: 8a31228c-89e8-4450-8408-9d47576d9db5 > Ancestors: OB-Standard-lr.487 > > - removed all references to Preferences > > Name: OB-Tests-Core-lr.83 > Author: lr > Time: 15 August 2010, 5:26:43 pm > UUID: 8ebb0466-c329-4eaa-a5a9-9e1114cf5da2 > Ancestors: OB-Tests-Core-lr.82 > > - removed all references to Preferences > > Name: OB-Tests-Morphic-lr.28 > Author: lr > Time: 15 August 2010, 5:27:19 pm > UUID: 043cf6f5-a9dd-4c9e-8846-fe43a280de07 > Ancestors: OB-Tests-Morphic-lr.27 > > - removed all references to Preferences > > Name: OB-Tests-Standard-lr.115 > Author: lr > Time: 15 August 2010, 5:27:39 pm > UUID: 3459c99b-df43-4ad9-b277-e579ff5a9bff > Ancestors: OB-Tests-Standard-lr.114 > > - removed all references to Preferences > > 2010/8/15 Mariano Martinez Peck <[hidden email]>: >> >> >> On Sun, Aug 15, 2010 at 2:58 PM, Lukas Renggli <[hidden email]> wrote: >>> >>> On Sunday, August 15, 2010, Marcus Denker <[hidden email]> wrote: >>>> >>>> On Aug 15, 2010, at 1:56 PM, Mariano Martinez Peck wrote: >>>> >>>> >>>> But I think we should add back a Preferences class for allowing to load >>>> old code. (it's referenced >>>> in the class side initialize in old code often...) >>> >>> Please don't add such a fake classes, it just makes everything more >>> difficult and less functional. People should not use outdated code, >>> and if they do they should be able to fix it themselves. >>> >>> I am fixing right now the remaining references in OB and Shout (RB and >>> eCompletion are already fixed). >>> >> >> Lukas, Shout won't load in Pharo 1.2 because of issue >> >> http://code.google.com/p/pharo/issues/detail?id=2734 >> >> :( >> >>> >>> Lukas >>> >>>> >>>> >>>> The problem are the external pacakges. I have 100 references to >>>> Preferences in Pharo dev....almost EVERY external package uses Preferences. >>>> So....we really need help of the external package maintainers to update >>>> them. And I am not sure how easy is that. >>>> What should be easy is to have a Preferences class that supports the >>>> simple API that everyone was using: add a preference. And make >>>> Preferenceclass return true or false for that preference. That should be 90% >>>> of all usages, I guess.. >>>> We can do that by just having a dictionary and overriding >>>> doesNotUnderstand:. We should not provide all this magic that used to be >>>> there, e.g.compiling on the fly methods for accessed perferences (which >>>> funnily had an empty source pointer...). >>>> I mean...is there a mapping between each previous preference a the new >>>> ones? >>>> >>>> >>>> In 1.1, Preferences are returning the values from the Settings framework >>>> for backward compatibillity. >>>> But I don't think that Preferences added are shown in the Settings? This >>>> would require Settings to be generated, which is possible but I thinknot >>>> really what we want. >>>> One could of course build this specification for the Preferences... and >>>> maybe there was even code there for that ;-) I started the cleanup bu >>>> removingunsent messages... but after a while that got really boring. And >>>> Preferences was a near 2000 LOC abdomination of a class. >>>> I checked in 1.1Dev, and most of the references are from the Core, which >>>> we removed in 1.2... >>>> Marcus >>>> >>>> >>>> --Marcus Denker >>>> -- http://www.marcusdenker.de <http://www.marcusdenker.de/> >>>> INRIA Lille -- Nord Europe. Team RMoD. >>>> >>>> >>>> >>> >>> -- >>> Lukas Renggli >>> www.lukas-renggli.ch >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
On Sun, Aug 15, 2010 at 6:19 PM, Stéphane Ducasse <[hidden email]> wrote: coooooooooooooooooool Of course :) That's why I asked about Shout repo.... Stef _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
In reply to this post by Mariano Martinez Peck
> Lukas, Shout won't load in Pharo 1.2 because of issue
> > http://code.google.com/p/pharo/issues/detail?id=2734 I am using PharoCore 1.1 until PharoCore 1.2 gets a release candidate. I guess PluggableTextMorph should be fixed, or why was this instance variable added? Is this coming from Squeak? Lukas > > :( > >> >> Lukas >> >> > >> > >> > The problem are the external pacakges. I have 100 references to >> > Preferences in Pharo dev....almost EVERY external package uses Preferences. >> > So....we really need help of the external package maintainers to update >> > them. And I am not sure how easy is that. >> > What should be easy is to have a Preferences class that supports the >> > simple API that everyone was using: add a preference. And make >> > Preferenceclass return true or false for that preference. That should be 90% >> > of all usages, I guess.. >> > We can do that by just having a dictionary and overriding >> > doesNotUnderstand:. We should not provide all this magic that used to be >> > there, e.g.compiling on the fly methods for accessed perferences (which >> > funnily had an empty source pointer...). >> > I mean...is there a mapping between each previous preference a the new >> > ones? >> > >> > >> > In 1.1, Preferences are returning the values from the Settings framework >> > for backward compatibillity. >> > But I don't think that Preferences added are shown in the Settings? This >> > would require Settings to be generated, which is possible but I thinknot >> > really what we want. >> > One could of course build this specification for the Preferences... and >> > maybe there was even code there for that ;-) I started the cleanup bu >> > removingunsent messages... but after a while that got really boring. And >> > Preferences was a near 2000 LOC abdomination of a class. >> > I checked in 1.1Dev, and most of the references are from the Core, which >> > we removed in 1.2... >> > Marcus >> > >> > >> > --Marcus Denker >> > -- http://www.marcusdenker.de <http://www.marcusdenker.de/> >> > INRIA Lille -- Nord Europe. Team RMoD. >> > >> > >> > >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Lukas Renggli www.lukas-renggli.ch _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
On Sun, Aug 15, 2010 at 6:41 PM, Lukas Renggli <[hidden email]> wrote:
I have no idea. I asked several times if someone can fix it... I am trying to start building PharoDev on top of PharoCore 1.2 but I have this problem.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
As far as I know, this happens because now a TextMorph has a styler
strategy. By default, the styler is the NullStyler but it can be set from outside to be something else (like a ShoutStyler). Like that you have the two concerns (editing, and highlighting) nicely supported by the framework without requiring subclassing. So, I would say that the simplest way to go around this problem and still be somewhat backward compatible would be to renamed styler to shoutStyler in the PluggableShoutMorph. Cheers, Doru On 15 Aug 2010, at 18:48, Mariano Martinez Peck wrote: > > > On Sun, Aug 15, 2010 at 6:41 PM, Lukas Renggli <[hidden email]> > wrote: > > Lukas, Shout won't load in Pharo 1.2 because of issue > > > > http://code.google.com/p/pharo/issues/detail?id=2734 > > I am using PharoCore 1.1 until PharoCore 1.2 gets a release candidate. > > I guess PluggableTextMorph should be fixed, or why was this instance > variable added? Is this coming from Squeak? > > I have no idea. I asked several times if someone can fix it... > I am trying to start building PharoDev on top of PharoCore 1.2 but I > have this problem. > > > > Lukas > > > > > :( > > > >> > >> Lukas > >> > >> > > >> > > >> > The problem are the external pacakges. I have 100 references to > >> > Preferences in Pharo dev....almost EVERY external package uses > Preferences. > >> > So....we really need help of the external package maintainers > to update > >> > them. And I am not sure how easy is that. > >> > What should be easy is to have a Preferences class that > supports the > >> > simple API that everyone was using: add a preference. And make > >> > Preferenceclass return true or false for that preference. That > should be 90% > >> > of all usages, I guess.. > >> > We can do that by just having a dictionary and overriding > >> > doesNotUnderstand:. We should not provide all this magic that > used to be > >> > there, e.g.compiling on the fly methods for accessed > perferences (which > >> > funnily had an empty source pointer...). > >> > I mean...is there a mapping between each previous preference a > the new > >> > ones? > >> > > >> > > >> > In 1.1, Preferences are returning the values from the Settings > framework > >> > for backward compatibillity. > >> > But I don't think that Preferences added are shown in the > Settings? This > >> > would require Settings to be generated, which is possible but I > thinknot > >> > really what we want. > >> > One could of course build this specification for the > Preferences... and > >> > maybe there was even code there for that ;-) I started the > cleanup bu > >> > removingunsent messages... but after a while that got really > boring. And > >> > Preferences was a near 2000 LOC abdomination of a class. > >> > I checked in 1.1Dev, and most of the references are from the > Core, which > >> > we removed in 1.2... > >> > Marcus > >> > > >> > > >> > --Marcus Denker > >> > -- http://www.marcusdenker.de <http://www.marcusdenker.de/> > >> > INRIA Lille -- Nord Europe. Team RMoD. > >> > > >> > > >> > > >> > >> -- > >> Lukas Renggli > >> www.lukas-renggli.ch > >> > >> _______________________________________________ > >> Pharo-project mailing list > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > -- > Lukas Renggli > www.lukas-renggli.ch > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Every successful trip needs a suitable vehicle." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Preferences removal Re: [update 1.2] #12092
|
|
On Aug 15, 2010, at 7:03 PM, Tudor Girba wrote: > As far as I know, this happens because now a TextMorph has a styler strategy. By default, the styler is the NullStyler but it can be set from outside to be something else (like a ShoutStyler). > > Like that you have the two concerns (editing, and highlighting) nicely supported by the framework without requiring subclassing. > > So, I would say that the simplest way to go around this problem and still be somewhat backward compatible would be to renamed styler to shoutStyler in the PluggableShoutMorph. why not but having a 1.2 version would solve the problem too. > > Cheers, > Doru > > > On 15 Aug 2010, at 18:48, Mariano Martinez Peck wrote: > >> >> >> On Sun, Aug 15, 2010 at 6:41 PM, Lukas Renggli <[hidden email]> wrote: >> > Lukas, Shout won't load in Pharo 1.2 because of issue >> > >> > http://code.google.com/p/pharo/issues/detail?id=2734 >> >> I am using PharoCore 1.1 until PharoCore 1.2 gets a release candidate. >> >> I guess PluggableTextMorph should be fixed, or why was this instance >> variable added? Is this coming from Squeak? >> >> I have no idea. I asked several times if someone can fix it... >> I am trying to start building PharoDev on top of PharoCore 1.2 but I have this problem. >> >> >> >> Lukas >> >> > >> > :( >> > >> >> >> >> Lukas >> >> >> >> > >> >> > >> >> > The problem are the external pacakges. I have 100 references to >> >> > Preferences in Pharo dev....almost EVERY external package uses Preferences. >> >> > So....we really need help of the external package maintainers to update >> >> > them. And I am not sure how easy is that. >> >> > What should be easy is to have a Preferences class that supports the >> >> > simple API that everyone was using: add a preference. And make >> >> > Preferenceclass return true or false for that preference. That should be 90% >> >> > of all usages, I guess.. >> >> > We can do that by just having a dictionary and overriding >> >> > doesNotUnderstand:. We should not provide all this magic that used to be >> >> > there, e.g.compiling on the fly methods for accessed perferences (which >> >> > funnily had an empty source pointer...). >> >> > I mean...is there a mapping between each previous preference a the new >> >> > ones? >> >> > >> >> > >> >> > In 1.1, Preferences are returning the values from the Settings framework >> >> > for backward compatibillity. >> >> > But I don't think that Preferences added are shown in the Settings? This >> >> > would require Settings to be generated, which is possible but I thinknot >> >> > really what we want. >> >> > One could of course build this specification for the Preferences... and >> >> > maybe there was even code there for that ;-) I started the cleanup bu >> >> > removingunsent messages... but after a while that got really boring. And >> >> > Preferences was a near 2000 LOC abdomination of a class. >> >> > I checked in 1.1Dev, and most of the references are from the Core, which >> >> > we removed in 1.2... >> >> > Marcus >> >> > >> >> > >> >> > --Marcus Denker >> >> > -- http://www.marcusdenker.de <http://www.marcusdenker.de/> >> >> > INRIA Lille -- Nord Europe. Team RMoD. >> >> > >> >> > >> >> > >> >> >> >> -- >> >> Lukas Renggli >> >> www.lukas-renggli.ch >> >> >> >> _______________________________________________ >> >> Pharo-project mailing list >> >> [hidden email] >> >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> > >> > _______________________________________________ >> > Pharo-project mailing list >> > [hidden email] >> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > >> >> >> >> -- >> Lukas Renggli >> www.lukas-renggli.ch >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > -- > www.tudorgirba.com > > "Every successful trip needs a suitable vehicle." > > > > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |