Hi Folks,
Similar to Grant, I typically look through all the preferences when I
start using an app. Perhaps this is an adaptation to a broken model of
preference setting, though. I can certainly see Philippe's point on this.
+1 on creating semantic separation between preferences and general user
data *for developers*, regardless of whether we provide UI into them for
end users.
Sincerely,
Jeffrey
Grant Baillie wrote:
> Happy Armistice Day, everyone.
>
> I'm +1 on attaching so-called "preferences" to parcels (a la
> PrefsForParcel).
>
> The issue of preferences UI is interesting. I agree the current model is
> frequently abused (in the email world, the extreme case is Eudora, where
> the sheer number and variety of preferences panes is overwhelming), and
> in most cases a direct manipulation model is better. In defence of a
> preferences UI, I should say I think it can sometimes _help_
> discoverability: when I'm trying to figure out how a new app works and
> what it does, I typically go through the menus, and then the
> preferences. But maybe I'm just weird :).
>
> --Grant
>
> On Nov 11, 2005, at 12:22, Philippe Bossut wrote:
>
>> Hi,
>>
>> 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 category.
>> - 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. Bad, bad...
>>
>> 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... :)
>>
>> Cheers,
>> - Philippe
>>
>> 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
>>> preferences:
>>> 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
>>> box.
>>> 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.
>>>
>>> Alec
>>>
>>>
>>> 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
>>>>> single
>>>>> 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
>>>>> knowledge
>>>>> 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
>>>> 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
>
> _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _
>
> 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
