Philippe Bossut wrote:
Hi,
Just a thought: shouldn't we adverize and document through the parcel
tutorial the existence of this pref system so that parcel developers
don't reinvent this (or worse)?
Of course! But this just came into existence in 0.7... so at the
moment, we haven't even released a milestone with this capability.
Alec
Cheers,
- Philippe
Alec Flett wrote:
Just an update on this:
- I've added a Preferences class in osaf.framework: (file
osaf/framework/prefs.py)
from osaf.framework import Preferences
- I've created a "DialogPref" which is the first use of the Preferences
class, used for "prompt dialogs" like Yes/No prompts, etc
class DialogPref(Preferences):
...
Everything else is as documented below, and I've tried to add
appropriate docstrings to Preferences to explain how to store
persistent preferences in the repository.
Alec
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
|
