[Dev] persisting a preference

[Philippe Bossut]

+1 also. That's very clean Python that even I can understand... :)

Again, I understand the need and I'm not opposed to having such a 
mechanism, "au contraire" (especially for what I call styles info... :) 
). I was warning against it's abuse and saying that having one is no 
substitute for the hard thinking about the real semantic of the data we 
store, the happy "hey, let's stick that under a preference" trick when 
no clear scenario can be found... The sad state of preferences in 
Mail.app for instance makes me think that this is, alas, still too 
common among application designers these days.

Cheers,
- Philippe

John Anderson wrote:

> +1 This is along the lines of what I thinking too.
>
> Alec Flett wrote:
>
>> John Anderson wrote:
>>
>>> Chandler's repository already provides a great way to persist user 
>>> data, state between sessions and a host of other stuff in the system 
>>> (e.g. the order of items in tables), which we already use everywhere 
>>> and it works great. I think calling all of this persistent data 
>>> "preferences" would be confusing. I like Philippe's suggestion (see 
>>> below) that we call user settings (e.g. style information) preferences.
>>
>> Yeah, I think there is really no technical difference between 
>> preferences and any other data in the repository.. however there is a 
>> /semantic/ difference, and that's what I think is worth trying to 
>> capture. There are plenty of persisted values in the repository that, 
>> if tweaked by the user, would probably just wreak havoc on chandler.
>>
>> Preferences, on the other hand, are safe to muck with a bit, and 
>> provide some 'back door' hacks to allow us to try out experimental 
>> behavior or features in the application by letting users turn them on 
>> manually. For instance, here's a page of FireFox "hidden preferences" 
>> - prefs which have no UI:
>> http://www.geocities.com/pratiksolanki/
>>
>> So Philippe, you asked for a few things to be clarified. Here's what 
>> I'd suggest:
>>
>> somewhere, say osaf.app, we have:
>>
>> class Preferences(Item):
>>     pass
>>
>> Then, in an individual parcel's .py file, lets say this is for john's 
>> MP3-organizer, somewhere:
>>
>> class MP3Prefs(Preferences):
>>     favoriteGenre = schema.One(schema.String)
>>
>> and in their __init__.py's installParcel():
>>
>>     MP3Prefs.update(parcel, 'preferences', favoriteGenre='Rock')
>>
>> Then, to access that particular preference:
>>     mp3prefs = schema.ns('mp3player', view).preferences
>>     genre = mp3prefs.favoriteGenre
>>
>> If a tool wanted to iterate all preferences in the system, and print 
>> them to the screen:
>>
>> for parcelPrefs in osaf.app.Preferences.iterItems():
>>     print "Preferences for: %s:" % parcelPrefs.__class__.__name__
>>     for prefname, prefvalue, preftype in 
>> parcelPrefs.iterAttributes(inherited=False):
>>         print "    %s = %s" % (prefname, prefvalue)
>>
>> This would (hopefully) print:
>>
>> Preferences for: MP3Prefs:
>>     favoriteGenre = Rock
>>
>> you could even imagine a UI like about:config that uses 
>> AttributeEditors to edit the prefs and make sure they have the right 
>> sort of UI for each type of attribute.
>>
>> Alec
>>
>>------------------------------------------------------------------------
>>
>>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>>
>>Open Source Applications Foundation "Dev" mailing list
>>http://lists.osafoundation.org/mailman/listinfo/dev
>>  
>>
>------------------------------------------------------------------------
>
>_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
>Open Source Applications Foundation "Dev" mailing list
>http://lists.osafoundation.org/mailman/listinfo/dev
>  
>