On Tue, Oct 12, 1999 at 07:24:27PM -0700, Paul Rohr wrote:
> >I have some questions about the internal storage. These options, most of
> them
> >if not all, will be appPersistant. Where will the information be stored? I
> >know that the AppPers class takes care of initializing one instance and such.
> >But, my question is, is their some global repository of configurations data?
> >or should I query the dialog (yuck)?
> >
> >I've not looked around too much as of yet, but i'll be needing some place to
> >start.
>
> Jeff's travelling (yes, again) so here are a few pointers to get you
> started. Believe the code if it conflicts with my ultra-quick gloss, and if
> the code's not clear, ask more questions on this list. By the time you get
> to that point, he should be back.
>
> The existing prefs mechanism uses an XAP_Prefs member variable hanging off
> the XAP_App which allows you to switch between various XAP_PrefsScheme
> instances. These schemes can be partial, in that the prefs mechanism will
> always fall back to a hardwired set of builtin defaults. (Never let it be
> said that Jeff doesn't believe in full generality when he solves a problem.)
>
> Each individual preference setting is stored as a key / value pair of
> XML_Char strings. The keys and default values are defined in the following
> files:
>
> abi/src/af/xap/xp/xap_Prefs.h
> abi/src/wp/ap/xp/ap_Prefs_SchemeIds.h
I noticed that there is only one "boolean" preference option, but I'm about to
add many more. I've been sticking to the 0/1, but have been considering
adding a
XAP_PrefScheme::getPrefsValueBool(XML_Char * szKey, UT_Bool ** pbValue);
(of course w/ the consts back in)
function to accept 0/1 t/f true/false yes/no.
Will this be over kill? Even if we limit it to 0/1, I think we should have a
function to return just a bool. That way, any changes to the acceptable
values will not require a recursive grep on getPrefsValue
If so, I could send a patch.
> For examples of how they're referenced, do a recursive grep across the tree
> for usage of "getPrefsValue" from an app pointer. It's pretty simple,
> really.
>
> Currently the prefs mechanism loads back and forth from disk, but as far as
> the app's concerned it's still read-only. For your purposes, I presume
> we'll need to add a setPrefsValue() member to XAP_Prefs or something. It
> also looks like there'll need to be corresponding methods added to the App
> classes, but you may want to get Jeff involved for that. He may remember
> why they got factored all the way out to app-specific platform code. At the
> moment, I don't.
I have not had a problem adding values (or atleast changing values) to a
preference scheme.
I saw a reference in a source code TODO to a future feature to be added to the
preferences code. This feature, event call backs for when prefs get changed.
This will allow the XAP_Prefs (and friends) keep track and notify the
appropriate sections of code to handle the changing of preference values.
Is there any plans or talk on this?
> If you're comfortable going ahead to implement this yourself, just make sure
> that any prefs changed by the UI get stored to a scheme other than
> "_builtin_" because that represents the hardwired defaults. If any other
> scheme is currently selected, use that. Otherwise, create some new scheme,
> say "_custom_" or something. (I'm guessing that the logic to implement this
> particular rule probably belongs in XAP_Prefs.)
>
> Hope that helps.
>
> Paul
>
Well, hopefully either tomorrow or tuesday I should have some code to submit.
Currently I have the dialog changing values and saving the appropriate stuff
in the Abiword.prefer file. Most of what needs to be done is clean up...
move stuff from unix/ap_UnixDialog_Options to the ap/ap_Dialog_options files.
and attempt to stub in dialogs for windows and beos.
-shack
