> Date: Wed, 1 Oct 2003 02:24:06 -0700 (PDT) > From: Jan Schenkel <[EMAIL PROTECTED]> > 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. _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
