Preference initialization

Hi all,

while working on the sensor fix I ran across the problem that there is
no initialization code for current preference settings, a typical side
effect of working with an image.

Problem is, that references, in my case to the class InputSensor, can't
be found by the usual cross reference methods.

IMHO we should come up with "something" so we can re-generate the
current preferences from code if needed. That initialization code would
also provide the necessary cross references.

Not sure how that plays with the pragma preference stuff...

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Hehe, a lot of class initialization code could be removed once used...
That would make the system even harder to understand/change.

Among obvious reasons why this kind of code should be kept somewhere
else than a doIt in a forgettable changeLog:
- going toward a more modular system...
- ...that can enable a change of UI,
- making system easier to understand by making some object
relationships explicit,
- and being able to build an image ex-nihilo

You gain a +(5 raisedToTheSuperPowerOf: 5) (Don't try and evaluate it)
Integer>>#raisedToTheSuperPowerOf: anInteger
    anInteger < 0 ifTrue: [^self error: 'requires a positive integer argument'].
    anInteger = 0 ifTrue: [^1].
    anInteger = 1 ifTrue: [^self].
    ^self raisedTo: (self raisedToTheSuperPowerOf: anInteger - 1)

Nicolas

2009/4/27 Michael Rueger <[hidden email]>:
_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

2009/4/27 Michael Rueger <[hidden email]>: You're right. An image should not contain artifacts, which can be
reproduced only by wizardry (manual doits).

> Not sure how that plays with the pragma preference stuff...
>
> Michael
>
> _______________________________________________
> Pharo-project mailing list
> [hidden email]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>



--
Best regards,
Igor Stasenko AKA sig.

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Michael Rueger a écrit : If I well understand, the problem is as follow:
You have a preference which value is a class (InputSensor).
The problem is that the class InputSensor can be removed or changed,
letting your preference value
point to AnObsoleteInputSensor. You would like to be warned that
InputSensor is used as a preference value
when you're about to remove that class.
Do I understand well ?

For such a situation, the new setting package can provide the
initialization code you would like with the help of a SettingStyle.
A SettingStyle only responsibility is to provide a load method which,
when evaluated, re-generates
settings.
We could have a "current" SettingStyle always up-to-date and which would
be automatically changed (generating of the load method)
every time a setting value is changed. Of course, then, a simple setting
change would be time consuming
but I guess this is not very important because settings are set rarely.

what do you think ?

alain

> Michael
>
> _______________________________________________
> 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

On Tue, Apr 28, 2009 at 9:15 AM, Alain Plantec <[hidden email]> wrote:


> If I well understand, the problem is as follow:
> You have a preference which value is a class (InputSensor).
> The problem is that the class InputSensor can be removed or changed,
> letting your preference value
> point to AnObsoleteInputSensor. You would like to be warned that
> InputSensor is used as a preference value
> when you're about to remove that class.
> Do I understand well ?

Yes and no. ;-)
I don't think classes should be referenced directly as preference
values, but that is a different discussion.

In my case it was the changeInformee inst var that pointed to that
class. And that inst var can only be set programmatically. But, there
is no code in the system that does that anymore.

I think that would be overkill. Preference initialization code doesn't
need to be able to create the current settings, only a default set of
settings.

But your proposal have me a different idea how to solve the problem
for preference values:

For references to objects or classes in the value entry it would help
to have the class reference search also go through the preference
values. That way you would get informed of references to a class from
preferences before removing the class.
There are probably other well known locations that should be checked
(e.g. Object Dependents).

Michael

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

still
Don't you think that having a default can can be regenerated is not  
better and simple?
May be I missed something.\

_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Stéphane Ducasse wrote:
> still
> Don't you think that having a default can can be regenerated is not  
> better and simple?


Not sure what you are saying here. I'm proposing having "something" so
we can regenerate the default setup.
Alain proposed to be able to regenerate the current settings, which I
don't think is what we want, especially as that would mean dirty
packages every time you change a setting.

Michael


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

On Apr 29, 2009, at 9:44 AM, Michael Rueger wrote:

> Stéphane Ducasse wrote:
>> still
>> Don't you think that having a default can can be regenerated is not
>> better and simple?
>
>
> Not sure what you are saying here. I'm proposing having "something" so
> we can regenerate the default setup.

OK
>
> Alain proposed to be able to regenerate the current settings, which I
> don't think is what we want, especially as that would mean dirty
> packages every time you change a setting.

OK I understand
and I agree with you.


_______________________________________________
Pharo-project mailing list
[hidden email]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project