"local" vs. "persistent" preferences

Hi -

I have an axe to grind with regards to preferences. In my use, having
project-local preferences is completely pointless and consequently
having the "local" option in the preference browser is pointless too.

What I'd rather like to see are *persistent* preferences, i.e.,
preferences that are picked up automatically in all the images that I use.

What do people think? Worth throwing out "local" preferences and instead
use "persistent" ones?

Cheers,
   - Andreas

On 2010-03-10, at 9:20 PM, Andreas Raab wrote:

> Hi -
>
> I have an axe to grind with regards to preferences. In my use, having project-local preferences is completely pointless and consequently having the "local" option in the preference browser is pointless too.
>
> What I'd rather like to see are *persistent* preferences, i.e., preferences that are picked up automatically in all the images that I use.
>
> What do people think? Worth throwing out "local" preferences and instead use "persistent" ones?

+1.

One of the things I think Squeak is missing is the notion of shared resources. VW has the $VISUALWORKS directory where it looks for parcels and the like, and most other programming languages have directories where libraries and other resources are installed.

The only thing that's currently shared between images in Squeak is the sources file. I think it would be good to have a user-specific, and possibly system-wide location where things that are shared between images could be stored. Off the top of my head:
       
        - the sources file
        - persisted preferences
        - MC cache repository
        - SM cache

Colin

On 11.03.2010, at 06:52, Colin Putney wrote:
I don't think we need to throw out project-local preferences. Seems to be orthogonal to persistent preferences to me.

Persistent preferences are much needed. Here is how I imagine them to work from a user's perspective (had no time to work on it though):

http://tracker.squeakland.org/browse/SQ-134

- Bert -

Keep it simple, this would be my preferred scheme.

preferences are constants, constants are implemented using a method  
#giveMeBigStuff ^ true

Load a MyPreferences class (at start-up if you wish) as a subclass of  
PreferencesDefault with your settings in and point

Smalltalk preferences ^ MyPreferences current

If you want domain specific preferences simply add a method

PreferencesDefault seaside ^ WAPreferences current

So usage becomes something like "Smalltalk preferences seaside port."

You can override seaside preferences by implementing MyPreferences  
seaside ^ WAPreferencesForMySite

For project locals, the project can use a local preferences accessor  
(Project current preferences) which can be pointed at a chosen  
preferences implementation.

As a final nuance, I would extend this by implementing "Preferences  
current" as a thread local variable, giving you per process control.

As a result of this email I have added a new type to InstallSeries  
*.prefs

This works the same as an update stream, except it always loads the  
last item in a *.prefs update series. Running an update at startup  
will then re-load the preferences.

thanks

Keith

 

>> One of the things I think Squeak is missing is the notion of shared  
>> resources. VW has the $VISUALWORKS directory where it looks for  
>> parcels and the like, and most other programming languages have  
>> directories where libraries and other resources are installed.

For cuis I am using

launchpad.net/grow/base-common
launchpad.net/grow/system-common

So when the magma load process notices that cuis is missing Mutex, it  
can find it there (if you have it checked out locally)

Keith

 

Personally, I've not had a need for project-specific preferences.  As
far as persistence, you have the save and load to disk buttons.

But perhaps it would be nice if, instead of looking for the
static-named file "myprefs" or whatever it is, look for the one that
is the "image name".prefs, that way separate images can have their own
persistent prefs.

The only problem with that is how do you easily transfer prefs from
one to the other?  Update save Image as... to also copy over its
.prefs file perhaps?



On Wed, Mar 10, 2010 at 11:20 PM, Andreas Raab <[hidden email]> wrote:

On 11.03.2010, at 22:51, Chris Muller wrote:
>
> Personally, I've not had a need for project-specific preferences.

Project-local preferences are pretty much only useful in Etoys, where projects are the preferred unit of modification.

That's also why persistent preferences are necessary in Etoys, since the image is read-only and not modified. To make customizations, preferences need to be read at startup. I'd favor a preference directory with one file per preference, named after the preference.

- Bert -

> I'd favor a preference directory with one file per preference, named after the preference.

Why not just a Dictionary object of the preferences saved via SmartRefStream?

On Thu, Mar 11, 2010 at 4:31 PM, Bert Freudenberg <[hidden email]> wrote:

On 11.03.2010, at 23:38, Chris Muller wrote:
>
>> I'd favor a preference directory with one file per preference, named after the preference.
>
> Why not just a Dictionary object of the preferences saved via SmartRefStream?

Harder to edit outside the image.

Also, I only want to persist only very few preferences (none normally). Did you read this?

http://tracker.squeakland.org/browse/SQ-134

- Bert -