Bizarro behavior explained

Dave Cragg dcragg at lacscentre.co.uk
Wed Feb 9 23:15:06 EST 2005


On 9 Feb 2005, at 21:30, Richard Gaskin wrote:

> J. Landman Gay wrote:
>> On 2/8/05 7:23 AM, Klaus Major wrote:
>>> We wait until the "Home" stack is no longer necessary as Richard 
>>> predicted ;-)
>> I must have missed something along the line -- why/when/how are we 
>> not going to need a Home stack?
>
> Of course some Home stack or another will still be need to be present 
> for licensing, but the one we're all currently will need to be 
> replaced at some point with the next license change so any changes you 
> might have made to it now will be lost at that time.
>
> Also, once FlipsIDE goes final there may be some who prefer the 
> simpler setup and since it runs MC with Rev's license stack it may not 
> be wise to store custom props there, since we can't rely on any 
> features of other people's stuff remaining in place indefinitely.
>
> The upside for what Klaus is working on is that it's generally 
> considered the right thing to do:  both HIGs strongly suggest it, and 
> in circumstances where the current user may not be an administrator it 
> may be the only way to have prefs stored reliably between sessions.
>
I wonder if HIGs should apply to development tools in the same way they 
apply to applications. Like Robert, I keep various versions of both MC 
and Rev on my hard drives. And sometimes multiple copies of the same 
version, for example when messing about with the IDE. So even keeping 
separate prefs by version wouldn't always work. And when testing 
alpha/beta versions, I'd be worried what was being saved to a non-local 
prefs file. So please give the option to save prefs locally in the app 
folder.

The administrator rights issue is one reason I generally keep MC and 
Rev out of the Applications or Program Files folders and put them 
somewhere in user space. Perhaps not so convenient for multi-user 
machines though.


Cheers
Dave

PS
Looking forward to FLIPSide.
Looking forward to seeing Klaus dance again.



More information about the metacard mailing list