mozilla

Compare Revisions

Preferences

Change Revisions

Revision 628975:

Revision 628975 by BenjaminSmedberg on

Revision 628979:

Revision 628979 by BenjaminSmedberg on

Title:
Preferences
Preferences
Slug:
Mozilla/Developer_guide/Preferences
Mozilla/Developer_guide/Preferences
Content:

Revision 628975
Revision 628979
n19      Name of preference is period separated. For example:n19      By convention, preference names are period separated. Prefe
 >rences for a feature are grouped together with a common prefix. F
 >or example:
n27      Like this example, the period separated preference names man27      If code may want to observe preference changes for a group 
>ke you understand which preferences are used togetter for a featu>of preferences, they should be grouped together with a common pre
>re easy. These structure means:>fix to improve observer performane.
28    </p>
29    <pre>
30&lt;root&gt;(.&lt;sub-group&gt;)*.&lt;item&gt;
31</pre>
32    <p>
33      The sub-group should be a feature name or sub module name a
>nd it should be separated for each feature with using two or more 
> sub-groups as far as possible. If somebody wants to observer cha 
>nges of some preferences under <code>"foo.bar."</code>, it might  
>involve innecessary preferences if sub-groups are not separated a 
>s enough small group. 
n36      The item name should be easy to understand. It's okay to ben30      Preferences which enable or disable a feature should be nam
>come long name like <code>"use_it_only_when_it_is_available"</cod>ed &lt;root&gt;.featurename.enabled with a boolean type. If an <c
>e>.>ode>"enabled"</code> pref does not always enable or disable the f
 >eature, you may need to add another pref which enables or disable
 >s the feature forcibly (i.e., ignoring the condition). The pref n
 >ame should be <code>"force_disable"</code> or <code>"force_enable
 >"</code>.
n39      Preferences which enables or disables a feature, the item nn33      Preference names should be easy to understand. It's better 
>ame should be <code>"enabled"</code> and the type should be <code>to use a long name such as <code>"use_it_only_when_it_is_availabl
>>boolean</code>. Don't define a preferences as <code>"&lt;root&gt>e"</code> than a cryptic name which might cause confusion.
>;.&lt;feature-name&gt;"</code> for the purpose since when somebod 
>y adds preferences for the feature, <code>".enabled"</code> is mo 
>re explicit and consistent name with new preferences. If an <code 
>>"enabled"</code> pref does not always enable or disable the feat 
>ure, you may need to add another pref which enables or disables t 
>he feature forcibly (i.e., ignoring the condition). The pref name 
> should be <code>"force_disable"</code> or <code>"force_enable"</ 
>code>. 
n41    <h2>n35    <h2 id="When_to_use_Preferences">
42      When to use Preferences36      When to use preferences
n61      How to add new prefencen55      How to add new preference
n85      Float value preferencen79      Float values
t88      Prerefences system doesn't support float type. Therefore, tt82      The prerefences system doesn't support float types natively
>here are two approach to implement it.>. One workaround is to use integer preference whose value is muti
 >lplied by 10, 100 or 1000. You should explain the value meaning i
 >n {{Source("modules/libpref/src/init/all.js")}} if you define its
 > initial value. The other is to use string preference and convert
 > to float using <code>parseFloat</code> (JavaScript) or <code>ato
 >f</code> (C++).
89    </p>
90    <p>
91      One is to use integer preference whose value is mutilplied 
>by 10, 100 or 1000. You should explain the value meaning in {{Sou 
>rce("modules/libpref/src/init/all.js")}} if you define its initia 
>l value. 
92    </p>
93    <p>
94      The other is to use string preference and convert to float 
>using <code>parseFloat</code> (JavaScript) or <code>atof</code> ( 
>C++). 

Back to History