Heath Martin <[EMAIL PROTECTED]> writes:
> If I'm not mistaken, currently there are no options being saved
> from one session to the next, but that a lot of the framework
> for saving is already in place; for the gnome version, it seems
> like option-util.[ch] is the primary entry point to the guile
> code that does the work. Correct?
Yes. The current options code is supposed to handle that. It's
supposed to allow you to define an "option" which will then
automatically have a gui-representation for configuration, and will be
saved to disk as scheme code that will re-establish the current
setting on exit iff the user has changed the option from the default.
The code should be saved to ~/.gnucash/config.auto. Then, the startup
procedure is as follows: if there is a ~/.gnucash/config.user, load
that. If not, load ~/.gnucash/config.auto. So if the user creates
their own startup file, they don't get any of the automatic
configurations unlesss they load ~/.gnucash/config.auto from their
startup file.
As I recall, right now the code to save the settings to config.auto
doesn't exist, but it should be a simple matter of traversing the
registered options and spitting out the right scheme forms. I just
never got to it. I got side-tracked with the GUI stuff. Now that
Dave's on top of the options GUI stuff, I can probably get back to it.
Though if you have interest in working on it, I'd be happy to just
assist..
> However, there are two possible issues here as far as what and how to
> save. First, there are the "user preferences," things that the user
> actually modifies directly, such as what columns to show in the
> account tree, colors/fonts/spacing/date ranges in the register, and
> all that. Second, there is the "session management" stuff, which may
> be gnome/motif dependent, such as which accounts in the account tree
> are currently expanded, which register windows are currently open, and
> so forth. There may also be a kind of "transient user preferences"
> for things that get changed fairly often, but still need to be saved
> across different sessions; date ranges in the register might be such a
> thing.
I think all of this should just go into config.auto. Since we can put
arbitrary scheme code in there, we can organize it however we like.
We could even handle generating the contents of the file from
functions attached to a "save-config-file" hook so that all you have
to to is add thunks to that hook to make sure things get saved. Of
course, that might not be the best way. I'd have to think about it.
We can even handle GUI specific stuff with an appropriate guile-level
predicate function "(gnc:gui-flavor)" so we can say:
(case (gnc:gui-flavor)
((motif) ...)
((gnome) ...)
(else ...))
> To get the discussion started, I'll propose the following: use the
> guile options code to keep track of "user preferences", but use the
> gnome-config API to track "session management" stuff.
I'm not familiar with the gnome session stuff. What would that buy us
over just putting guile code in config.auto? If there's a file that
GNOME needs in order to know things about the app, we could just
generate that as a side-effect.
--
Rob Browning <[EMAIL PROTECTED]> PGP=E80E0D04F521A094 532B97F5D64E3930
--
Gnucash Developer's List
To unsubscribe send empty email to: [EMAIL PROTECTED]
