Relative Paths

[Monte Goulding]

> 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.

My question would be why is it necessary to ask your users to directly
manipulate files and folders in and around your applications. It's a simple
task to include an interface to abstract the user away from direct file and
folder manipulation. I'd hazard a guess that many windows users don't even
know where their applications are stored let alone want to mess with them.
>
> Note that Revolution's components are also outside the bundle as they
> are with mine.

Well if rev had all the IDE components in the app bundle it would make
standalone building tricky for a start. But that's not a design issue that
many of us need to deal with.

Cheers

Monte