Okay, so I actually had posted the prior one you gave me to the FTP
site, the one without the embedded Zip, before I saw this new one,
WITH the embedded zip.

Between Tobias' and Eliot's responses,

Tobias> The app does not run for me:
Eliot> and the app runs just fine on 10.6.8.
Tobias> Then it might be a “version 1 vs Version 2 signature” as in
the Apple note...

I can't tell what our status is.  Can the one Craig signed and I
posted (w/o the embedded zip) be run by Mac users or not?

>> Why uncompressed by itself?  If one uncompresses an archive
>> ...snip...
>>
> -    If you sign the .app, then make a ZIP archive with the .app folder
>      and the scripts as siblings, then unarchive it, then MacOS 10.9.5
>      Gatekeeper rejects the signature (unless you have Gatekeeper
>      turned off).

Can't you sign the .app + the two scripts together?

> -    If you use anything other than the Mac Finder GUI to make the
>      archive, or open it, then MacOS 10.9.5 Gatekeeper rejects the
>      signature (unless you have Gatekeeper turned off).
>
>> > ...the release is now a ZIP archive that contains the two non-Mac
>> > launch scripts, along with another ZIP archive which contains the
>> > .app directory. This also means that non-Mac users will get the
>> > "__MAC" and ".DS_Store" debris after uncompressing, as well.
>>
>> It doesn't have to be this way.  Use zip -u to add the siblings at a
>> later date.
>
>      No; it's the Mac-Finder-GUI way of making the ZIP that adds the
> debris, apparently. At that later date, you've already lost, either by
> using the Mac Finder GUI to make the ZIP (and getting a good signature
> on open, and debris) or making the ZIP some other way (and getting a bad
> signature on open).
>
>> > I still think all this is tolerable. However, I'll say again here
>> > that I strongly prefer having the .app directory be the root of our
>> > release artifact, a totally self-contained thing, and leaving it to
>> > users to set up launch shortcuts appropriate to their local system
>> > (given a directory structure that is obvious enough for them to
>> > realize how to do it).

You keep mentioning this feature about setting up custom launch
shortcuts but ignoring my rebuttal that the audience the All-In-One is
designed for is for newbies.  Newbies are the ones who have only just
heard about Squeak and are saying, "Just Show Me Squeak Right Fucking
Now".

The group you're referring to, who wants to unzip the All-In-One, and
then set it up in custom locations with shortcuts for repeated access
over the long-term, those folks are not who the All-In-One is
targeting.

Besides that, the shortcut scripts are not an impediment to doing what
you said anyway.  If anything, they "document" where and how to launch
it and so if they want to move them to a different place, they'll know
how.

The type of person who is adventurous enough to customize it will not
"fold" and whine "hey it didn't work when I moved / renamed /
whatever."  In fact, they would probably find the documentation on
squeak.org about the invididual components (.image, .changes, vm,
.sources) and set it up truly custom, and now this person is a totally
disparate audience from the All-In-One audience.

> ...snip...
>
>> Why don't you see it as an obligation to provide a pleasant and
>> simple install step to that community rather than asking them to
>> perform a manual step?
>
>      On the contrary, I do see an obligation to make the installation
> process as pleasant as it can be. Those users are already performing
> manual steps: downloading the ZIP file manually, unpacking it manually,

Done at this point.  Once unpacked, it's ready to run.

> and putting the contents somewhere in their filesystem manually
> (especially in the use case you seem to care about most, putting the
> contents in a directory which is already in their executables search
> path).

No, the $PATH variable has nothing to do with launching Squeak from
the All-In-One.  This makes no sense to me..

> Given that they are already performing these manual steps, I
> don't see what I propose as onerous.

If I downloaded a ZIP and I found another Zip inside it, I would think
that the .sh and .bat were things that would unpack that zip FOR ME.
Assuming I figured out that was wrong,I would then wonder am I
supposed to put this inner-zip?  In the same directory or can it stand
alone elsewhere?  If it has to be in teh same dir, then why the fuck
didn't the authors just put it that way?

It's totally confusing, irritating, and repelling.  Exactly the
opposites we want newbies to feel.  The goal is to get them into the
image as quickly and easily as possible.

>> I want to go on record therefore that I think providing the scripts
>> is important, especially for newbies, a group we surely want to
>> appeal to.
>
>      Yes, we surely want to appeal to newbies. I think equating
> disagreeing with you on this with neglecting newbies is disingenuous.

C'mon.  When Eliot said you are a decent human being, he was simply
expressing his disagreement in a way that was trying to avoid you
becoming upset.  It appears he failed, but at least he tried.

>      Anyway, yeesh. The decision was up to Chris and he made it (and he
> agrees with you); this issue is over, for 4.5 anyway. I don't see a lack
> of unanimity about it as a dire thing. Let's debate namespaces and
> modules instead. :)

I appreciate that, but I don't know if we've made any progress
whatsoever from the original post though, which expressed that the
All-In-One was having trouble for Mac users..

I have no Mac.  What's our status of the one that's there now?

>
>
>      thanks,
>
> -C
>
> --
> Craig Latta
> netjam.org
> +31 6 2757 7177 (SMS ok)
> + 1 415 287 3547 (no SMS)
>
>