Page 1 of 2
Preferences
Posted: Mon Jun 10, 2013 5:57 pm
by mwieder
Currently some IDE preferences are stored as custom properties of the revpreferences stack, and some as custom preferences of the revpreferencesUI stack.
I'm not wild about this for a couple of reasons:
1. I'd like to have preferences stored in text files rather than as properties of stacks. This would increase portability, eliminate a dependence on stackFileVersion incompatibilities, and reduce inter-stack dependence.
2. I'm torn between wanting all the preferences in one text file and having each IDE component store its own preferences. I'm tending toward the latter, as I think it would help make IDE components more independent of each other and help reduce clutter in a single file.
I'm agnostic as to the format: xml? json? text key-value pairs? I suppose it doesn't matter as much if each stack keep track of its own preferences, but in general I think coding standards would benefit from a common format.
Re: Preferences
Posted: Mon Jun 10, 2013 6:26 pm
by FourthWorld
mwieder wrote:1. I'd like to have preferences stored in text files rather than as properties of stacks. This would increase portability...
What other programs would need to access LC prefs?
For version compatibility in the event of file format changes, I'd advocate just naming the prefs for each version, importing the old ones to start the new ones.
It's hard to beat custom props for robustness and ease of use. Stack files are a favorite file format of mine, so much more efficient than XML, INI, or just about anything else.
But yes, I agree all prefs for a given version should be stored in a single file.
Re: Preferences
Posted: Mon Jun 10, 2013 9:07 pm
by mwieder
But yes, I agree all prefs for a given version should be stored in a single file.
Well, I think I'm arguing the opposite here...
My current thinking is that in order to facilitate a plug-and-play sort of IDE, separate preferences files for the different components (script editor, property editor, etc) would be better kept in separate files. That way replacing, for example, the built-in property editor with the MetaCard property editor would be just a matter of dropping it into place without needing to complicate a single source of all the preferences.
And if there are going to be separate preferences files, then a lighter-weight approach would be small text files rather than carrying around the baggage of a stack.
Re: Preferences
Posted: Mon Jun 10, 2013 10:30 pm
by FourthWorld
A good plug-and-play API would be provide handlers for getting and setting prefs, completely independent of the physical storage format.
That said, what's wrong with a stack file? Seems a very with-the-grain way to store name-value pairs in LC. If the IDE team can't successfully use custom props for something as simple as prefs, what can we expect others to use them for?
The stack "baggage" is just a few bytes. Make an empty stack file and see.
Re: Preferences
Posted: Mon Jun 10, 2013 10:45 pm
by mwieder
A good plug-and-play API would be provide handlers for getting and setting prefs, completely independent of the physical storage format.
Aha! Putting the prefs mechanism into the IDE rather than in individual components! This I like. So part of the IDE's api could include something like
Code: Select all
SetPreference pKey, pValue
GetPreference(pKey)
and the api in the IDE could get the originating component and set the property accordingly.
That said, what's wrong with a stack file?
Every time the stackFileFormat changes the preferences get screwed up. If you test LiveCode X+1 and the file format has changed and you save changes, your preference file is no longer readable by LiveCode X-1. The fiasco with the LC 5.x file formats losing all the IDE preferences is what got me to change to text files. Now my preferences files are completely version-proof.
The overhead of reading a text file vs reading a custom property shouldn't really enter into the discussion. What I do with preferences in general is
1. Load the preferences file on preOpenstack.
2. Set the current preferences from the loaded values as necessary.
3. When a preference changes, save to the preferences file.
It's really only with step 3 where you'll see the speed difference, and this action isn't frequent enough to be noticeable. Preferences files are pretty small.
Re: Preferences
Posted: Mon Jun 10, 2013 10:51 pm
by FourthWorld
But what if you later need to add binary data to prefs?
This would require some good format thinking, perhaps also binhexing it, or use length markers, or...
...oh, that's pretty much what the stack file format already provides.
As I suggested before, as long as we have complete app installs with each version, there's a good argument to make a new prefs file for each version as well. If nothing else, we can expect from time to time that the info in the prefs file might also change between versions, so keeping them separate seems a good solution to the backward compatibility thing.
If we absolutely have to go to a different file format, I'd not argue much if it were simply an encoded array, which would give us more or less the same thing.
But whether the name-value pairs are stored as props or an encoded array, we have a bigger question with regard to the API: should we require another param or naming convention to make sure elements don't walk all over each others' prefs?
Re: Preferences
Posted: Tue Jun 11, 2013 12:34 am
by mwieder
But what if you later need to add binary data to prefs?
LOL. Good point. I base64encode it to get around that and pull a trick to get it out (start the xml data with "base64(encode" and then decode the payload at the other end, but it's rather an ugly hack, and nothing as elegant as using custom properties.
But whether the name-value pairs are stored as props or an encoded array, we have a bigger question with regard to the API: should we require another param or naming convention to make sure elements don't walk all over each others' prefs?
A custompropertyset using the unique name of the component? Even better once we have uuids for stacks instead of short names. I think uuids would solve the namespace problem neatly, although I'm waiting for runrevmark to weigh in on his alternate-universe theory.
Code: Select all
-- in the omnibus preferences stack
set the RichardsPropertyEditor["rect"] of this stack to "42,42,42,42"
-- substitute the stack uuid for "RichardsPropertyEditor" when that's available
Re: Preferences
Posted: Tue Jun 11, 2013 1:48 am
by FourthWorld
mwieder wrote:But whether the name-value pairs are stored as props or an encoded array, we have a bigger question with regard to the API: should we require another param or naming convention to make sure elements don't walk all over each others' prefs?
A custompropertyset using the unique name of the component? Even better once we have uuids for stacks instead of short names. I think uuids would solve the namespace problem neatly, although I'm waiting for runrevmark to weigh in on his alternate-universe theory.
Code: Select all
-- in the omnibus preferences stack
set the RichardsPropertyEditor["rect"] of this stack to "42,42,42,42"
-- substitute the stack uuid for "RichardsPropertyEditor" when that's available
I like it.
Re: Preferences
Posted: Tue Jun 11, 2013 6:05 am
by shaosean
Code: Select all
SetPreference pKey, pValue
GetPreference(pKey, pDefaultValue)
I would recommend adding a default value to the getter incase the property doesn't exist (think of upgrades to the IDE)
Re: Preferences
Posted: Tue Jun 11, 2013 7:00 am
by Simon
OK, this is one of the few threads where you guys talk that I finally understand.
Yes, yes and yes!
Take Richard's binary into consideration and I'm all for it.
Any form.
Simon
Re: Preferences
Posted: Tue Jun 11, 2013 10:33 am
by monte
Default values would be easier to initialise once per component... perhaps in it's preOpenStack handler...
revSetPreferenceDefault pComponent,pPref
What I tend to do for prefs is use arrayEncode/Decode and a script local to hold the prefs so they only get read from file once per session but written each time there's a change...
So what I would suggest is something like:
put pPref into sPrefA[pComponent][pPref]
-- arrayEncode and save here...
Re: Preferences
Posted: Tue Jun 11, 2013 6:44 pm
by mwieder
@Monte-
The idea here is to decouple the preferences mechanism as much as possible from the individual IDE stacks.
What I want to see is a common mechanism that all the IDE stacks can tap into to deal with preferences.
Forcing the setting of default values into the stacks and making each stack developer responsible for enforcing this is error-prone and cumbersome.
So I very much like Sean's idea of allowing a defaultPreference value at the preferences stack level.
Re: Preferences
Posted: Tue Jun 11, 2013 9:23 pm
by monte
Perhaps I misunderstood Sean's idea... I thought it was passing a default whenever you get the preference... That seems more work to me than setting them once on early on...
Re: Preferences
Posted: Wed Jun 12, 2013 5:16 am
by shaosean
The idea of the default value is incase the preference key does not exist in the preferences file, this will stop you from getting errors if someone is upgrading a piece of software from version 1 to version 2 and you want to keep using the old preferences file, but have new preferences to add the preferences file..
Re: Preferences
Posted: Wed Jun 12, 2013 6:17 am
by mwieder
@Sean- I've just gotten back from a rehearsal, so my mind is a bit addled, but I'm having trouble parsing that sentence. Can you help me out and rework it some for me?