An initial response based on what I do.
1. My experience has been that script users have an uncanny knack for not installing things right so step by step I have moved towards the position where they have to do nothing expect unzip the package into the Scripts folder. I specifically do not expect them to create any new folders or be able to decompress a folder structure type zip file to the right place.
I realise there are possible disadvantages with this - if something goes wrong the files get left in the Scripts folder - but I think the advantages outweigh the disadvantages.
It may be useful to create some sort of tidy-up script that can clean up inappropriate files which have been left in the Scripts folder. It could for example look at the file created date and delete files in the scripts folders which are more than 2 days old and which are not js or jsx file (add to that list as you wish) - I do not believe that html, dat or image files belong in the Scripts folder except during installation.
2. On the same theme, I only ever have one script in a package and that script is the main script and handles all installation as well. I never have a separate installation script (though I have considered creating a standardised one). Actually the important point here is not that there is only one script, but that there is only one script the user has to deal with.
3. [Indirectly related issue] As my larger scripts develop, sometimes they get into trouble because the new script looks for a different 'start-up' structure from the external dat file than it previously did. So, most scripts reading from a dat file have a version system whereby if necessary they can recognise and delete an old dat file.
Andrew
Options/Preferences directory for scripts
-
xbytor
Options/Preferences directory for scripts
Andrew wrote:An initial response based on what I do.
1. My experience has been that script users have an uncanny knack for not installing things right so step by step I have moved towards the position where they have to do nothing expect unzip the package into the Scripts folder. I specifically do not expect them to create any new folders or be able to decompress a folder structure type zip file to the right place.
I was kind of intending for there to be an install script that would be run after installation. They could unzip into ScriptsData/pkg and run the script there which does whatever package initialization is needed. The script could be either a shell script or a PS script.
Andrew wrote:I realise there are possible disadvantages with this - if something goes wrong the files get left in the Scripts folder - but I think the advantages outweigh the disadvantages.
It may be useful to create some sort of tidy-up script that can clean up inappropriate files which have been left in the Scripts folder. It could for example look at the file created date and delete files in the scripts folders which are more than 2 days old and which are not js or jsx file (add to that list as you wish) - I do not believe that html, dat or image files belong in the Scripts folder except during installation.
Would this be like an 'uninstall' script or more like a 'repair' script?
Andrew wrote:2. On the same theme, I only ever have one script in a package and that script is the main script and handles all installation as well. I never have a separate installation script (though I have considered creating a standardised one). Actually the important point here is not that there is only one script, but that there is only one script the user has to deal with.
My packages tend to have several files, unless its a simple task or one that requires portability to PS7 (no includes). I am also kind of looking forward to the formal 'library' script concept in CS2 and multiapplication script applications available in CS2.
Andrew wrote:3. [Indirectly related issue] As my larger scripts develop, sometimes they get into trouble because the new script looks for a different 'start-up' structure from the external dat file than it previously did. So, most scripts reading from a dat file have a version system whereby if necessary they can recognise and delete an old dat file.
I like the versioning idea though haven't had the need for it yet. We may want to start another thread on good coding practice for things like this. One problem I keep having, for instance, is dealing with recursive include dependency chains where file A includes file B which includes file C which includes file A. Nice little infinite loop possibilities there. Photoshop doesn't like them too much.
1. My experience has been that script users have an uncanny knack for not installing things right so step by step I have moved towards the position where they have to do nothing expect unzip the package into the Scripts folder. I specifically do not expect them to create any new folders or be able to decompress a folder structure type zip file to the right place.
I was kind of intending for there to be an install script that would be run after installation. They could unzip into ScriptsData/pkg and run the script there which does whatever package initialization is needed. The script could be either a shell script or a PS script.
Andrew wrote:I realise there are possible disadvantages with this - if something goes wrong the files get left in the Scripts folder - but I think the advantages outweigh the disadvantages.
It may be useful to create some sort of tidy-up script that can clean up inappropriate files which have been left in the Scripts folder. It could for example look at the file created date and delete files in the scripts folders which are more than 2 days old and which are not js or jsx file (add to that list as you wish) - I do not believe that html, dat or image files belong in the Scripts folder except during installation.
Would this be like an 'uninstall' script or more like a 'repair' script?
Andrew wrote:2. On the same theme, I only ever have one script in a package and that script is the main script and handles all installation as well. I never have a separate installation script (though I have considered creating a standardised one). Actually the important point here is not that there is only one script, but that there is only one script the user has to deal with.
My packages tend to have several files, unless its a simple task or one that requires portability to PS7 (no includes). I am also kind of looking forward to the formal 'library' script concept in CS2 and multiapplication script applications available in CS2.
Andrew wrote:3. [Indirectly related issue] As my larger scripts develop, sometimes they get into trouble because the new script looks for a different 'start-up' structure from the external dat file than it previously did. So, most scripts reading from a dat file have a version system whereby if necessary they can recognise and delete an old dat file.
I like the versioning idea though haven't had the need for it yet. We may want to start another thread on good coding practice for things like this. One problem I keep having, for instance, is dealing with recursive include dependency chains where file A includes file B which includes file C which includes file A. Nice little infinite loop possibilities there. Photoshop doesn't like them too much.
-
xbytor
Options/Preferences directory for scripts
I'm in the final stages of packaging up my toolkit and I've run into a problem.
It turns out that if you have scripts in any subdirectory anywhere under the Presets directory, the scripts will appear in the 'File->Scripts' menu.
This suX0Rs.
I was planning on dropping my library scripts under Presets/ScriptsData/xlib. When I do that I end up with a 'File->Scripts' submenu that is longer than my screen is tall. Less than useful.
We need to pick another directory for script libraries. My initial suggestion would be to use app.path + '/Scripts Library' or something similar, but I thought I'd check in here in case someone has any other ideas.
It turns out that if you have scripts in any subdirectory anywhere under the Presets directory, the scripts will appear in the 'File->Scripts' menu.
This suX0Rs.
I was planning on dropping my library scripts under Presets/ScriptsData/xlib. When I do that I end up with a 'File->Scripts' submenu that is longer than my screen is tall. Less than useful.
We need to pick another directory for script libraries. My initial suggestion would be to use app.path + '/Scripts Library' or something similar, but I thought I'd check in here in case someone has any other ideas.
-
Andrew
Options/Preferences directory for scripts
I noticed that a while back. Maybe we should shift ScriptsData up a level too and put everything in there, I think a single external place to put scripting things is important.
Andrew
Andrew
-
Andrew
Options/Preferences directory for scripts
Looking into this a bit further there are some potential ways around the problem.
In the Bridge JS docs it suggests that included files have the extension jsxinc - I just tested and only files with js and jsx get seen by the PS Scripts menu, so that works.
Similarly, ES does not care what the extension is when it comes to including so you could use any other extension you want.
In a way I find the idea of identifying JS includes differently from JS scripts attractive, it means they do not mess things up if placed in scripts folders, startup folders etc.
That allows us to stick with the current location of ScriptsData
Andrew
In the Bridge JS docs it suggests that included files have the extension jsxinc - I just tested and only files with js and jsx get seen by the PS Scripts menu, so that works.
Similarly, ES does not care what the extension is when it comes to including so you could use any other extension you want.
In a way I find the idea of identifying JS includes differently from JS scripts attractive, it means they do not mess things up if placed in scripts folders, startup folders etc.
That allows us to stick with the current location of ScriptsData
Andrew