+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
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
Open Source Applications Foundation "Dev" mailing list
http://lists.osafoundation.org/mailman/listinfo/dev
