"Krista C. Miller" <email@hidden> wrote:
>Within this application is a configuration utility that is accessed from
>a menu item. This utility can also be invoked from the command line (it
>has its own main function).
>
>I would like to create a double-clickable shortcut for this utility, but
>am unaware of how to do this without duplicating some or all of the .app
>package (which seems too brute-force). The parallel to this on Windows
>is that under the start menu, our program group has two shortcuts that
>point to the same target location for resources but execute different
>commands. This is the type of behavior I would like to achieve on OS X.
It is possible to share most of the bundled resources, using hard links.
Read 'man ln' and 'man 2 link'.
It's also possible to share resources with symlinks, but doing so creates
reliability risks. Specifically, if the apps are ever separated (moved to
different locations on disk), the symlinks will no longer work, and one of
the apps suddenly and mysteriously breaks.
The parallel to Windows is worth considering for what users expect. In my
experience, Windows users don't expect any apps to be movable, and further
expect that app removal most likely involves a deinstaller. Management of
apps is almost always done indirectly, using installers and deinstallers,
rather than directly, using just the desktop (the Mac OS X Finder). Even
tiny insignificant Windows programs usually have installers.
Mac users expect to be able to move third-party applications around however
they want, whenever and wherever desired, and not have anything break.
(hey used to expect that from Apple's apps, too, but time and experience
has changed that, starting with 10.0, and now most know not to mess with
/Applications.) Mac users also expect to be able to remove apps as they
wish using just the Trash, and not suffer unrelated breakage. Hard-links
will meet all those criteria, but symlinks and other tricks will not.
What you call brute-force I call simple, independent, and robust. I wonder
how much disk space you hope to save by sharing the resources, as compared
to making each app completely independent (unshared resources). In view of
the total amount of disk space on today's machines, even relatively puny
ones, anything except 100's of megabytes of duplicated data is
insignificant.
I'm not suggesting that a distribution with shared resources isn't
worthwhile. It is, because it probably makes the distro smaller. To get
that, create a read-only disk-image with hard-links that share resources.
Then users can drag-copy, or run an installer, or launch from the
disk-image, or whatever, and everything will still work. The copied apps
won't share resources, but unless you have 100's of MB, so what?
-- GG
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Java-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/java-dev/email@hidden
This email sent to email@hidden
