So for OS X, unless you move your external stacks inside the bundle (altering the path from what it had been in development, altering the user experience across platforms, and thereby requiring forked documentation for your product) you'll need to prepend your stackFiles to accomodate Apple's break from convention:
By having all external stacks inside your application bundle you are infact
maintaining the same relative path across all platforms and you don't need
to your stackFile altering script.
Only from the perspective of the machine. For people, there are two fundamental metaphors driving the experience: files and folders. An OS X bundle is neither and both, an oddity that differs not only from the rest of the computing world but also from Apple's own legacy of nearly two decades.
This is not to suggest that introducing the bundle concept is without merit, but neither is it a trivial matter to accomodate well.
For apps with user-modifiable components, if I moved those components into the bundle on OS X I would have to inform users of the extra steps to:
1. Control-click on the application
2. Select "Show Package Contents" from the contextual menu
(a violation of their own HIG, that item is not also
available in a primary menu)3. Open the Contents folder
4. Open the MacOS folder
5. Do whatever they need to do as on other platforms
And all of that must follow an explanation of why what appears to be a file isn't really a file at all but is secretly a folder, or refer them to the appropriate section of the sparse Mac OS Help which explains that mystery.
Note that Revolution's components are also outside the bundle as they are with mine.
> The single clickable bundle is the expected user experience on OS X. > I'm not sure how you would need to fork
your documentation based on you application's files being inside the bundle. Generally these files need no user interaction. Certainly it's not appropriate to put files that need user interaction inside the bundle but neither is it appropriate to place them next to the application on most systems.
Consider many of the applications from Adobe, Macromedia, Microsoft, and others:
A lot of apps allow plugins, templates, or other user-modifiable elements, including Flash, Dreamweaver, GoLive, Office, Photoshop, Swift3D, Interarchy, and of course Revolution itself, just to name a few.
Apple's decision to leave "Show Package Contents" out of the primary menus suggests it's not something they expect end-users to deal with.
But even many apps that don't have user-modifiable components are built with external component folders that are the same on all platforms relative to the *.app, not the /Contents/MacOS/executable within in. And I believe a majority of apps keep their documentation external to the bundle in either case.
So yes, many apps can be easily built to accomodate both OS X and the rest of the world without difficulty. But many others, including Revolution, can't, requiring either forked code or forked documentation. Revolution wisely favors the end-user, keeping the experience consistent across platforms and forking the code instead, using a script probably not too different from the one I use.
With the ease of adding extensibility to Rev-based apps (through external media, plugins, etc.) it may be worthwhile exploring ways to make it consistently easy to deliver multi-platform apps in the form so many major vendors do.
-- Richard Gaskin Fourth World Media Corporation ___________________________________________________________ [EMAIL PROTECTED] http://www.FourthWorld.com _______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
