[Dev] persisting a preference
pbossut at osafoundation.org
Fri Nov 11 00:22:08 PST 2005
First, I'd like to say +1 on this proposal though I'd like some things
to be clarified.
In general, a problem I always had with preferences is that it's an
amorphous aggregate of info without much semantic attached to it. It
rapidly becomes a clutter of everything no one knows exactly where to
fit. Preferences were invented to persist data between sessions for
document oriented applications that lacked a way to persist their own
data. In the context of Chandler, it's not a problem we really have
though we still need to persist things (I won't call them
preferences...) that are not user data per se (see Jeffrey initial
example in this thread).
Also, I know no one is advocating having UI for preferences (under a
"Preferences..." menu item), but, in case anyone has doubt, I advocate
against having a "Preferences..." menu item at all. Preferences menu
lead to countless discoverability issues. I'm of the opinion that if a
function foo is dependent of data "x", data "x" should be available in
the UI of function foo, not buried in some obscure preference panel (you
can tell I suffered through that one, can you?... :) )
In general, I see 2 big types of preferences:
- state info: info that we want to persist between sessions (last
selected item, options chosen by the user in dialog x, prefered behavior
for action z...). Jeffrey's default folder for instance falls in that
- style info: info that relates to how things are displayed (font types,
font size, colors, border info, etc...). Having a clear and simple way
to modify those in Chandler would indeed be a god send.
There may be other types.
User data (like account information for instance) are not preferences
but, well, user data. The criteria between preferences and user data is
that preferences can be purged or reset without the user loosing
anything or having to reconfigure anything. The worst that could happen
is that states and styles are lost. We don't need for instance to
implement schema evolution for preferences but we do need to implement
it for user data. That's another criteria to semantically discriminate
one from the other.
It's not always obvious. Consider that Mail.app for instance has its UI
to set up accounts under a Preferences... panel. Admitedly, nixing
accounts in an e-mail app is not semantically the same thing that nixing
the default e-mail font. Still, those 2 things are at the same UI level.
So I guess that my vote is +1 for having such a general mechanism,
assuming we don't call them indiscriminately "preferences" but something
else semantically meaningful (like "config" and "styles" for instance,
so that we really think about their semantic when creating them) and
that we don't take advantage of this to bury important UI controls in
hidden preferences panels... :)
Alec Flett wrote:
> I think there's something to be said for exploring a somewhat generic
> preferences architecture, or at the very least a set of conventions -
> duck typing for preferences if you will (if it looks like a
> preference, and acts like a preference, its probably a preference)
> In the mozilla project (full disclosure: I was the owner of the
> preferences backend) we developed a system where all prefs are stored
> in a central place, and each pref has its own name within the a
> private namespace, such as "browser.cache.memory.enable". 3rd party
> plugins/extensions can "register" new prefs. This allows for a
> particularly useful feature in mozilla, 'about:config' - go ahead -
> type this into the URL bar in FireFox. What you'll get is a UI to edit
> all global prefs across the system. Neat, huh?
> However, I personally don't think that kind of system is quite
> appropriate for a project like ours, especially given the dynamic
> nature of both python and the repository.. but there are a few things
> about the mozilla prefs system that were useful specifically for
> 1) a global list of 'all preferences' so that they could be reflected
> into the UI dynamically like about:config.
> Of course, all of our repository can be reflected into the UI, but I
> think there is value in distinguishing those values in the repository
> that give some obvious, useful, and predictable change in the behavior
> of the application.
> 2) the ability to register for changes to a preference, or a set of
> preferences. This is useful because any one of a number of actions
> could change the value of a preference, not just a preferences dialog
> For instance, you can register a callback for when the value of
> "network.protocol-handler.external.mailto" changed, or for
> "network.protocol-handler.external.*" to capture all sub-changes.
> Both of these features are almost trivial given the repository.
> I like philip's PrefsForMyParcel, and in fact I think we could
> accomplish most of 1) and 2) by making a base Kind/class, ParcelPrefs
> (or something..maybe just 'Preferences') that each parcel could derive
> from, and declare new schema attributes to store individual
> preferences. The KindCollection for ParcelPrefs would then be the
> 'registry' of all prefs in the system.
> the only trick at that point is the notification when preferences
> change... but we have a number of systems for notifications, so I'm
> willing to bet that would be fairly easy and we can address it when
> there is actually a need.
> Phillip J. Eby wrote:
>> At 08:57 PM 11/2/2005 -0800, Jeffrey Harris wrote:
>>> Hi Folks,
>>> What's our current thinking on how a developer should go about
>>> establishing and using what I'll call a preference, essentially a
>>> persistent value with a well-known name (in this case, I'm wanting to
>>> persist the last directories chosen for import and export)?
>>> We've got lots of well-known collections living in
>>> parcels/osaf/app/__init__.py, perhaps that's the appropriate place for
>>> preferences? It doesn't feel quite right to me...
>>> I'm sending this question to the list instead of asking one person or
>>> another because
>>> A) I think there might be different opinions, and
>>> B) I'm hoping someone will write up a detailed example so that
>>> can live on in the list, not just my brain :)
>> The simplest thing that would work:
>> class PrefsForMyParcel(schema.Item):
>> some_pref = schema.One(sometype, defaultValue=something)
>> # ... other preferences
>> def installParcel(parcel, oldVersion=None):
>> PrefsForMyParcel.update(parcel, "prefs")
>> Accessing preferences can then be done via:
>> schema.ns("my.parcel", view).prefs.some_pref
>> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>> Open Source Applications Foundation "Dev" mailing list
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
> Open Source Applications Foundation "Dev" mailing list
More information about the Dev