Saving Preferences

Ken Norris pixelbird at
Wed Oct 1 12:51:00 EDT 2003

> Date: Wed, 1 Oct 2003 02:24:06 -0700 (PDT)
> From: Jan Schenkel <janschenkel at>
> Subject: Re: Saving Preferences

>> 3) I'll also have a PrefDialog substack which will
>> read data from the Prefs
>> stack, which won't be saved in itself, but can
>> operate on it while open,
>> change data as appropriate, then write directly back
>> to the Prefs stack,
>> replacing data (save) there. Is this correct?
> That will work just fine ; and is IMHO a better
> solution than to merge the preferences UI and data
> storage into a single stack.
Well, I thought about that, but it wouldn't save to itself, so it made more
sense to break out the Prefs stack into a separate file by itself. In fact,
it will probably have no controls at all.

But I also think I should make the Prefs dialog stack separate as well.

That's why I'm exploring and asking opinions. I still haven't completely
decided how I should do what I want. I think I'd like to develop a standard
way to build Prefs/Control Panel stacks which can be updated independantly
and remotely.

Suppose I want to offer a new theme package of icons and feedback sounds. I
would like a module that will download the package from a website, and
install it automatically, i.e., the image and sound data files will be
loaded into the Prefs stack folder and the new choice added to the
availability list in the Prefs stack, which can be read and acted on from
the Prefs _dialog_ stack.

I know this can be done in Rev, but I haven't quite worked it out yet. It
should check for duplicates and the like. And, also, for the user's own
sake, a security device to prevent the user from accidentally throwing away
the Prefs or other pertinent data stacks.
>> 4) If all the above is true, then it looks like the
>> Prefs dialog should be
>> another substack opened by the UI stack, correct?
> Yes, you will have to open it in order to get to its
> data ; but you can open it invisibly so nobody ever
> has to know :-)
By opening it offscreen, locking the screen,...what method?

Ken N.

More information about the Use-livecode mailing list