Relative Paths

[Richard Gaskin]

Monte Goulding wrote:
>>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
  ___________________________________________________________
  Ambassador at FourthWorld.com       http://www.FourthWorld.com