Bridge - Voluntary Scripting Guidelines

Question

I made a first post on this at ps-scripts:
http://www.ps-scripts.com/bb/viewtopic.php?t=176
It seems to me we would benefit from developing 'good practice' guidelines for Bridge scripting. Here are some intial issues that occur to me:
1. Function namespaces:
Given the use of start-up scripts and the loading of script libraries at start-up it is important we keep function names unique. I am going to use ah_myfunction() for all my own function names. It is also sensible that scripts should use libraries where one already contains a function, rather than duplicating the library function within another script - giving rise to a potential namespace conflict between different versions later.
2. Bridge menus:
Given how central scripting is to Bridge I feel there should be a top-line scripts menu (which I wish could be accessed via an FKey). We could call it 'Scripts' (lol). All non-startup scripts could be listed within that menu - perhaps some guidelines as to order would be useful - maybe alphabetical. It would then be optional to group those further as to application target (in many cases this would be unnecessary). If they are to be grouped by application it may be better to simply organise them with separators rather then put them in further submenus - I resent every extra click I have to make when accessing menus, especially when I am using automation to start with.
To add some background to this point - while the menu customization potential of Bridge is attractive I believe it will mainly be used by scripters rather than by the broader user community. If scripters start creating individual menus as part of scripts they then distribute to a wider audience without consideration of what other scripters are doing things are going to get very messy very quickly. I could start off making an Andrew Hall Scripts menu and why not put next to that a link to my website and maybe to my artsite too etc.etc.
3. Start-up versus one-off scripts.
In many cases it is possible to create a script that does a particular task either as a startup script (the openshut.jsx script is an example of this) or as something that only gets run when required but which is not loaded at startup. I would say that where-ever possible scripts should be created as one-offs (ie not within the startup folder).
4. A Non-Startup Scripts folder and a ScriptData folder
With people writing and releasing non-startup scripts for Bridge, we (and especially the users) would benefit from having them generally put in the same place. My suggestion is to follow the organisation of Photoshop ie Bridge/Presets/Scripts.
Then, some scripts generate data files, access help files, etc, these need to go somewhere. Xbytor and I discussed this a while back in relation to Photoshop and agreed to use subfolders (I use the subfolder AndrewHallScriptData) within a new folder ScriptsData within the Presets folder. I suggest the same would work for Bridge ie Bridge/Presets/ScriptsData/YourFolder/
I am an absolute beginner to Bridge scripting so don't take the above as indicating I think I know better about this stuff than anyone else, I don't. Maybe some of these issues are misguided due to a lack of thorough understanding - if so I am happy to learn more. My issue is that I am about to release some Bridge / Photoshop scripts and I would like to organise them sensibly along the sorts of lines outlined above.
Andrew

Answer 1

I agree that, in the long run, things will get to be a real mess with global variables and function names conflicting right and left and anarchy in the menus if there aren't some guidelines. It probably won't happen soon because there won't be a flood of add-in scripts for awhile, so Adobe probably has some time to figure this out.
Along the lines that Andrew started, here's what I would suggest:
1) To solve the conflicting name problem, use the "#script script_name" directive (or invent a new #namespace directive) to automatically scope all global variables/function names to a single namespace under that directive. Since some functions need to be public, make a new way to declare just those as public. Perhaps use the #export directive to explicitly declare variables/functions that should be visible outside your #script namespace. Allow all script files with the same #script name to automatically be in the same namespace.
This would give you the best of both worlds. You'd have easy sharing between your own scripts by just using the same #script name on all of them, all variables would be private by default and you'd have a simple way to list the few functions/variables that you wanted to be public.
2) Menus. I like the menu flexibility we have now. It needs to be expanded to include other user interface elements like the filter's drop-down menu and other interface elements like toolbars. What I think is missing (or I haven't found) is the ability to have non-startup-loaded scripts that just automatically appear in a generic "scripts" menu. This would be just like actions automatically appear in the actions UI in Photoshop or filters automaticaly appear in the filters menu. Bridge should have a "scripts" menu for scripts that don't need to be loaded at startup and only need to run when invoked. This would also contribute to the namespace collision problem because scripts loaded in this manner would run, do their thing, and then be unloaded and wouldn't have a chance to conflict with other scripts that were run the same way.
--John