Preferences

This forum is a working group for community contributors to the LiveCode IDE included in the main LiveCode distribution.

Moderators: Klaus, FourthWorld, heatherlaine, kevinmiller

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2570
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Preferences

Post by mwieder » Mon Jun 10, 2013 5:57 pm

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.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5384
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Preferences

Post by FourthWorld » Mon Jun 10, 2013 6:26 pm

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.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2570
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Preferences

Post by mwieder » Mon Jun 10, 2013 9:07 pm

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.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5384
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Preferences

Post by FourthWorld » Mon Jun 10, 2013 10:30 pm

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.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2570
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Preferences

Post by mwieder » Mon Jun 10, 2013 10:45 pm

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.

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5384
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Preferences

Post by FourthWorld » Mon Jun 10, 2013 10:51 pm

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?
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2570
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Preferences

Post by mwieder » Tue Jun 11, 2013 12:34 am

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

FourthWorld
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 5384
Joined: Sat Apr 08, 2006 7:05 am
Location: Los Angeles
Contact:

Re: Preferences

Post by FourthWorld » Tue Jun 11, 2013 1:48 am

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.
Richard Gaskin
Community volunteer LiveCode Community Liaison

LiveCode development, training, and consulting services: Fourth World Systems: http://FourthWorld.com
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

shaosean
Posts: 828
Joined: Thu Nov 04, 2010 7:53 am

Re: Preferences

Post by shaosean » Tue Jun 11, 2013 6:05 am

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)

Simon
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 3900
Joined: Sat Mar 24, 2007 2:54 am
Location: Palo Alto

Re: Preferences

Post by Simon » Tue Jun 11, 2013 7:00 am

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
I used to be a newbie but then I learned how to spell teh correctly and now I'm a noob!

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1558
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Preferences

Post by monte » Tue Jun 11, 2013 10:33 am

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...
LiveCode User Group on Facebook : http://FaceBook.com/groups/LiveCodeUsers/

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2570
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Preferences

Post by mwieder » Tue Jun 11, 2013 6:44 pm

@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.

monte
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 1558
Joined: Fri Jan 13, 2012 1:47 am
Contact:

Re: Preferences

Post by monte » Tue Jun 11, 2013 9:23 pm

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/

shaosean
Posts: 828
Joined: Thu Nov 04, 2010 7:53 am

Re: Preferences

Post by shaosean » Wed Jun 12, 2013 5:16 am

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..

mwieder
VIP Livecode Opensource Backer
VIP Livecode Opensource Backer
Posts: 2570
Joined: Mon Jan 22, 2007 7:36 am
Location: Berkeley, CA, US
Contact:

Re: Preferences

Post by mwieder » Wed Jun 12, 2013 6:17 am

@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?

Post Reply

Return to “IDE Contributors”