Annoying trade-off in user interface
Annoying trade-off in user interface
- Subject: Annoying trade-off in user interface
- From: Dodger <email@hidden>
- Date: Mon, 16 Feb 2009 08:08:51 -0800
Hi, all,
I'm wondering if anyone can help me with this little issue I'm having
(actually, 2 little issues)
Okay, the first one is that my distribution requirement script seems
to have to be external -- I have it living as an invisible file in the
DMG itself, which would be mounted with the same name all the time and
all, so this should be OK unless, for instance, the user already has
an extrnal hdd mounted that just happens to have the same name or
something. That would make it fail. This seems a bad way to go about
things, but this script has to be there for things to work properly.
It seems like a cheesy hackish solution though.
Effectively, the script finds a prerequisite and stores it's location
in a file in /tmp so that the postflight script which constructs the
product's file from the other one knows where to get it. (think of it
like a patch into a new file sort of thing, because that's a close
description except that it's not actually a diff/patch)
So there are these drawbacks to this:
1) If the user has it installed in a nonstandard location, like on an
external hard drive or not under /Applications, my "find stuff" script
can't find it. I don't want to do a full drive search, and I cannnot
expect locate's DB to be up-to-date or even be sure that
locate/slocate is installed for certain. I know this because I just
tried to use /usr/bin/locate to find the required file on my machine
and it didn't return anything, and it's very definitely on here.
2) It's hackish and cheap to have a perlscript sitting invisible in
the root of the DMG just so it's there.
3) If the user already has the volume name in use, the DMG will mount
with an alternate filesystem name and the script will not be found.
4) The user must run the installer from the DMG (or at least have the
DMG mounted when running the installer)
Now, if I could figure out what CWD the installer runs the volume
check script starting from, and if that were one consistently relative
to the .pkg drectory, I could get past 2, 3 and 4 by putting the
script *inside* the .pkg directory itself.
So that is question #1: Can I put a script inside the Whatever.pkg
directory of the packagemaker installer and run it, and if so what
path do I give it. I.e. will the PKG run with it's cwd in itself?
Right outside of itself? Where?
Now, I realise that I could go out and hunt down the location of the
required file from a preflight script instead, and that the preflight
script would have the install directory given to it as an argument,
and that that would avoid all 4 of the problems, but it comes with
it's own problem, which is pretty big in my opinion:
1) Preflight scripts fail in an unfriendly way
Preflight scripts, when they fail, simply show a big Triangle-! and
say the script failed. They do not tell the user what's wrong, nor
does PackageMaker provide any mechanism with which to tell the user
what's wrong (whereas the above volume check lets me set some
JavaScript to handle the exception and tell the user "The required
file was not found. Please make sure blah blah blah"
It seems weirdly un-apple to make it so that we have two choices:
Unfriendly input or unfriendly output, and we can't have the
friendlist of both worlds.
So, if anyone knows a solution, I'd really love to know. And if you
happen to be a Poser user, I'll happily give you a copy of the content
for your input!
As much as I think the NSIS scripting language is quite possibly the
worst scripting language I've ever seen in my life (GOTOs are a way of
life in them), I kinda wish they would make NSIS for Mac. I can
customise the hell out of an NSIS installer on Windows.
--
Dodger
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Installer-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden