Preferences
Moderators: FourthWorld, heatherlaine, Klaus, kevinmiller
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Preferences
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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 9857
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Preferences
What other programs would need to access LC prefs?mwieder wrote:1. I'd like to have preferences stored in text files rather than as properties of stacks. This would increase portability...
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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Preferences
Well, I think I'm arguing the opposite here...But yes, I agree all prefs for a given version should be stored in a single file.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 9857
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Preferences
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.
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.
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Preferences
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 likeA good plug-and-play API would be provide handlers for getting and setting prefs, completely independent of the physical storage format.
Code: Select all
SetPreference pKey, pValue
GetPreference(pKey)
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.That said, what's wrong with a stack file?
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 9857
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Preferences
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?
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?
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Preferences
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 what if you later need to add binary data to 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.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?
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
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
-
- VIP Livecode Opensource Backer
- Posts: 9857
- Joined: Sat Apr 08, 2006 7:05 am
- Location: Los Angeles
- Contact:
Re: Preferences
I like it.mwieder wrote: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.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?
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
Richard Gaskin
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
LiveCode development, training, and consulting services: Fourth World Systems
LiveCode Group on Facebook
LiveCode Group on LinkedIn
Re: Preferences
Code: Select all
SetPreference pKey, pValue
GetPreference(pKey, pDefaultValue)
-
- VIP Livecode Opensource Backer
- Posts: 3901
- Joined: Sat Mar 24, 2007 2:54 am
- Location: Palo Alto
Re: Preferences
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
Yes, yes and yes!
Take Richard's binary into consideration and I'm all for it.
Any form.
Simon
I used to be a newbie but then I learned how to spell teh correctly and now I'm a noob!
Re: Preferences
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...
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Preferences
@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.
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.
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
Re: Preferences
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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/
Re: Preferences
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..
-
- VIP Livecode Opensource Backer
- Posts: 3581
- Joined: Mon Jan 22, 2007 7:36 am
- Location: Berkeley, CA, US
- Contact:
Re: Preferences
@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?
PowerDebug http://powerdebug.ahsoftware.net
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev
PowerTools http://www.ahsoftware.net/PowerTools/PowerTools.irev