[Architecture] gsettings prototyping

Gregg Vanderheiden gv at trace.wisc.edu
Wed Feb 22 21:53:55 UTC 2012

Hi Steve, List


 Steve wrote:

>> At what point does the translation between canonical/universal settings to platform specific settings occur? So I assume the 'settings' the user has stored in a CouchDB instance are the same for any platform, Win32, OS X, Linux, and then we'd have some sort of translation mapping for each platform.  So the gsettings/Node.js bridge would likely take the already translated instance of settings so they map to Gnome/whatever applications.  Or would the gsettings/Node.js bridge be expected to take the universal settings and do the translation?

For terminology - here are the terms we are currently using.  These may change but for now lets use them. 

COMMON - (would be the terms in the RtF/GPII Registry) These are preferences that are generic in nature and would be used by multiple applications.  They are intended to be defined and used in common between applications  

There are two types of COMMON preferences

CORE (COMMON):  These are COMMON preferences that have been studied and are believed to be stable and fixed.  A committee will review the LIVE COMMON (or LIVE) preferences and determine when they should become CORE COMMON (or CORE).   In tagging them with CORE designation, the name or definition or value range might be tweaked but care must be take to not break any use of the tag by existing user preference profiles. 

LIVE (COMMON):  These are COMMON preferences that have been entered by someone because there was not already another COMMON preference that met the need.  Anyone can submit a new preference to this set and it will be included unless it is an obvious duplication.    All LIVE preferences are candidates to become CORE.

These two categories of COMMON preferences would be maintained in the MAIN REGISTRY.

APPLICATION SPECIFIC - These are settings that would never be candidates for a COMMON preference because they are so specific to an application that they would not make sense as a COMMON preference.    An example may be whether a particular toolbar in an application is located above or below another toolbar in the application or off to the left.    

APPLICATION SPECIFIC preferences are maintained by whomever is maintaining the application -- and would not be in the MAIN REGISTRY.    (Preferences always include a pointer to which registry they are defined in)


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gpii.net/pipermail/architecture/attachments/20120222/11097c46/attachment.html>

More information about the Architecture mailing list