Dan,
As far as colour settings are concerned you should be able to Save you colour settings from Edit>Colour Settings d/box as a colour Settings File (.CSF) and LOAD that .CSF into CS
Len —
I appreciate the help, but my message wasn’t intended to ask how about to go about a "brute force" method of migrating to CS. I know how to do that. Sure, I can do a "save" for each of the various configurable features of PS, and then load them into CS. The point is, CS can do that for me with one fell swoop if it were programmed to. This isn’t much effort either. What’s more, CS is aware of any potential incompatibilities between versions, so it could also warn the user of such changes during the "migration" process.
So, my question remains: is there a quick, simple way to do this across all configurable settings, or are we stuck with the "brute force" method?
Dan,
I probably shouldn’t be butting in here, and your point is well taken that CS could have easily picked up this information automatically, but it seems to me that you could do the "brute force" Save and Load in about the same time as it took you to type in your last message. No sarcasm intended.
— Burton —
which explains why they wouldn’t waste one programmer for a week to do this and do it right. the fact that they’ve made the options loadable should be enough for a competant user. no offese intended dan, i’m just saying i’d rather see the healing tool working on new layers and all the other cool features than a feature that i’d use (maybe) all of one time and might save me 20 minutes.
The healing tool doesn’t work on new layers? HUH?
LOL
the cs healing tool will heal to a new (empty) layer as the target. as opposed to 7 where it heals only to the currently selected layer.
I realize there seems to be some sense that this is a frivolous task and that resources could be better spent elsewhere. But that sense is unrealistic. First of all, anyone who’s done programming knows, the process of "loading files" upon startup is done modularly, where a function performs the task based on parameters sent to it. In this case, CS is looking for initialization files directly from the default location for CS. It takes exactly one more line of code to do it (beforehand) on the previous version’s directory location. This doesn’t require a week’s worth of programmers. What’s more, the programmer that does healing tools, patch tools and other things are not likely to be the "installation" programmers who are responsible for the type of things I’m referring to here. (On a similar note, there is no documentation for easing newer users through the "migration" process as well, and that’s the responsibility of an entirely different department.)
You think it’s "not a lot" of dialogs, and that brute force is still less time than typing in stuff like this? Think again about how many various places you can "save" state information, whether it’s "actions", "colors", "preferences", previous dialog states (such as what you get when you do Ctrl+Alt+M to bring up the curves dialog as it was when you last used it, even if it was in a previous session). There are possibly 10s of 10s of "state" information settings that could be "migrated" over, making the entire process much much smoother. Remembering exactly which states your previous settings were at for an application that you haven’t configured in well over a year requires re-investigating data you didn’t need to remember once you configured it properly last time.
And lastly, my comment about PS’s ability to note possible incompatibilities between versions also acts as a failsafe for the user. If a file contained outdated or obsolete features/values/settings, then PS can tell you about it, so you don’t end up with behaviors or results that you didn’t expect.
Lastly, an automated migration path is simply a matter of clean and conscientious coding. It’s like how fine restaurants care about the bread they serve as well as the main courses.
While I realize the posters on this forum may minimize this feature, I hope the Adobe people consider it more seriously.
Dan,
You stated your case rather well and made some good points.
I hope the Adobe people consider it more seriously.
Perhaps they will.
— Burton —
It takes exactly one more line of code to do it (beforehand) on the previous version’s directory location.
Sure it does. Ever heard of error checking?
This doesn’t require a week’s worth of programmers.
I contend that it would take one guy (at least) a week to do this for all settings checking every file for errors and compatability w/cs, like you stated.
the programmer that does healing tools, patch tools and other things are not likely to be the "installation" programmers
you’re not talking about installation, you’re talking initializatoin. and you’d be suprised at how many different areas one programmer can cover. and there’s also the possibility that it would require several programmers. i’m not sure how adobe devides their programming work, but it’s not unfeasable to assume that each programmer in charge of an area would be responsible for implimenting it in his/her own section. ie. styles programmer responsible for loading and checking styles. pattern programmer responsible for loading and checking patterns. etc.
And lastly, my comment about PS’s ability to note possible incompatibilities between versions also acts as a failsafe for the user.
and adds to the programming overhead, negating the "one line" approach you advocated.
Lastly, an automated migration path is simply a matter of clean and conscientious coding.
(lastly again?!! <g>) …necessitating error checking, coding for multiple possibilities on a myriad of different systems and testing, also negating the "one line" approach. Sure it’d be a day? With all you want here (for the minimal – one shot – gains) It might be a couple weeks! Your requirement is getting bigger. Not your fault. It’s typical and us programmers are used to it! 😉
It’s like how fine restaurants care about the bread they serve as well as the main courses.
I hate it when I go to a good resteraunt and the bread is great, but then you find sand in the mussles marinara.
Perhaps they will.
Mayhap they will. But, um, I wouldn’t hold my breath. 🙂
Dan,
But that sense is unrealistic. <<
I would disagree.
You upgrade once per license (possibly twice if also installing to a 2nd machine). If it were something that you did repeatedly, then I grant you that it would be more worthy of consideration. However, with various changes from one version to the next, I believe you would be over-complicating the routines for very minor benefits…….
While I appreciate the desire to have the settings move forward automatically, it just isn’t that simple. Many things change version to version, more information is added to a particular piece’s settings, and the number of different items that could change from old preference file to old preference file is huge. It means for any piece of the app trying to preserve old preferences that 1) some interpretations of "missing" data must be done and 2) the combinations of things to test is rather explosive.
You might say that you could then just drop the preferences for individual items on the floor, but that ends up being true for most of the items. And I would contend that a mix of old and default preferences would be more confusing than just starting with a clean slate.
Don’t get me wrong; I’m not dismissing it out of hand. It’s just that there’s a lot to consider there – it’s most certainly not one line of code.
-Scott
it’s most certainly not one line of code.
Sure it is. One reeeeeeeealy loooooooong line. 🙂
One reeeeeeeealy loooooooong line<<
With LOTS of semi-colons…..
