All-in-ones

Who knows how to make one of these?

I'm more than happy to automate the process, but I don't know what the
process is yet!

frank

Frank,

Take a look at Lukas' builder[1] project for an example of building one-clicks...

Dale

[1] https://github.com/renggli/builder

----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Sent: Monday, January 7, 2013 7:11:21 AM
| Subject: [squeak-dev] All-in-ones
|
| Who knows how to make one of these?
|
| I'm more than happy to automate the process, but I don't know what
| the
| process is yet!
|
| frank
|

Ah, that's _exactly_ what I'm looking for. Thanks, Dale!

frank

On 7 January 2013 17:42, Dale Henrichs <[hidden email]> wrote:

Ah. Well, actually.

There's a <data> tag on line 119 of a file [1]. It looks like it's b64
encoded. What's it contain? What makes it?

What process did you follow to make that particular commit?

frank

[1] https://github.com/renggli/builder/commit/613716ee3e23692b98abbeec6def1a703ad6f3a4

On 7 January 2013 20:55, Frank Shearar <[hidden email]> wrote:

Frank,

That particular file is probably an artifact of the vm build process for the mac ... the Info.plist is a text file and the Info.plist.template has some of it's fields replaced by information from the build process (icon names, etc.) to produce the final file in the one-click.

I used diff and a text editor to manually update the Info.plist.template with the new field values for the new vm (leaving the fields that are replaced by the build process alone, like [1]).

So line 119 was a mindless copy/paste operation:)

Dale

[1] https://github.com/renggli/builder/blob/613716ee3e23692b98abbeec6def1a703ad6f3a4/oneclick/Contents/Info.plist.template#L25
----- Original Message -----
| From: "Frank Shearar" <[hidden email]>
| To: "The general-purpose Squeak developers list" <[hidden email]>
| Sent: Monday, January 7, 2013 1:04:06 PM
| Subject: Re: [squeak-dev] All-in-ones
|
| Ah. Well, actually.
|
| There's a <data> tag on line 119 of a file [1]. It looks like it's
| b64
| encoded. What's it contain? What makes it?
|
| What process did you follow to make that particular commit?
|
| frank
|
| [1]
| https://github.com/renggli/builder/commit/613716ee3e23692b98abbeec6def1a703ad6f3a4
|
| On 7 January 2013 20:55, Frank Shearar <[hidden email]>
| wrote:
| > Ah, that's _exactly_ what I'm looking for. Thanks, Dale!
| >
| > frank
| >
| > On 7 January 2013 17:42, Dale Henrichs <[hidden email]> wrote:
| >> Frank,
| >>
| >> Take a look at Lukas' builder[1] project for an example of
| >> building one-clicks...
| >>
| >> Dale
| >>
| >> [1] https://github.com/renggli/builder
| >>
| >> ----- Original Message -----
| >> | From: "Frank Shearar" <[hidden email]>
| >> | To: "The general-purpose Squeak developers list"
| >> | <[hidden email]>
| >> | Sent: Monday, January 7, 2013 7:11:21 AM
| >> | Subject: [squeak-dev] All-in-ones
| >> |
| >> | Who knows how to make one of these?
| >> |
| >> | I'm more than happy to automate the process, but I don't know
| >> | what
| >> | the
| >> | process is yet!
| >> |
| >> | frank
| >> |
| >>
|
|

Not sure if you got it going Frank, but a possible alternative if this
one is difficult would possibly be to simply copy the All-In-One.zip
for 4.3, and then replace the image inside the zip and call it done..?

On Mon, Jan 7, 2013 at 3:04 PM, Frank Shearar <[hidden email]> wrote:

That's a sad possibility though: it means folks run an ancient VM, and an untested VM+image combo.

We have to figure out how to do this anyway so I'm trying to get us to bite the bullet sooner rather than later.

frank

On 09 Jan 2013, at 16:42, Chris Muller <[hidden email]> wrote:

On 09.01.2013, at 09:39, karl ramberg <[hidden email]> wrote:

> It is partly covered here in the Etoys release how-to:
>
> http://etoys.squeak.org/svn/trunk/Documentation/Release-HowTo.txt
>
> But  Bert is the expert here.
>
> Karl

Karl is referring to the Etoys-to-Go description in section 5. Our current process is only semi-automated, it requires hand-editing of the meta data plist files. Basically all VM binaries are checked into SVN http://etoys.squeak.org/svn/trunk/VM/ along with the image and misc files (translation files, example projects etc) http://etoys.squeak.org/svn/trunk/Etoys and then a shell script assembles the directory structure and builds a zip file.

(btw, even though I invented the original all-in-one packaging for Squeak apps, I'm still not convinced it is well suited as primary download, at least not for the Mac, where the image is hidden "inside" the VM)

- Bert -

It is easy to open the application and drag everything out to a simple folder. Maybe all you need is a note suggesting that for those who don't like the all-in-one style.

Cheers,
Bob

(btw, even though I invented the original all-in-one packaging for Squeak apps, I'm still not convinced it is well suited as primary download, at least not for the Mac, where the image is hidden "inside" the VM)

Heh, thanks for looking for a way to automate it.  BTW I just meant,
"manually update the newly desired components in the zip" including
readme's, VM, etc.  Not just the image..  :)

Speaking of... which VM DO we want in the All-In-One?  I'm thinking
with the new Cog, since seems to be stable enough and it can launch
old images too..


On Wed, Jan 9, 2013 at 11:30 AM, Frank Shearar <[hidden email]> wrote:

I say completely scrap the idea of an all-in-one download for releases.
The three times bigger download size and added complexity of building the all-in-one isn't worth any effort IMHO for the three people somehwere that might want to run on more than one platform. Any interested parties are certain to be able to easily pick their appropriate platform download.

Concentrating on making sure the downloads for separate platforms have the Readmes, image, changes, sources and VM, and being a pleasant first experience is important however.

Ken G. Brown

On 2013-01-09, at 12:40 PM, Chris Muller wrote:

On 09-01-2013, at 11:52 AM, "Ken G. Brown" <[hidden email]> wrote:
> Concentrating on making sure the downloads for separate platforms have the Readmes, image, changes, sources and VM, and being a pleasant first experience is important however.


I pretty much agree with not bothering with an 'all-in-one' at least in part because it isn't really ever going to be an *all* in one. I won't argue that Windows & Mac  don't constitute a very large fraction of the potential audience but they're certainly not not all of it.

A good download page for each platform - and maybe for sub-platforms in some cases since some linux systems have fairly strong opinions and Windows n-1 is probably wildly different to Windows n  - is essential. It ought to explain what you need to download, have clearly shown links to the correct file(s), explanations of any further actions needed (for example with RISC OS you may well need to set the FileType of the image file to STimage) and what errors you might see if you get them wrong. I'm fairly sure most platforms could have a single file install suited to the platform but we do need to remember that fairly inexperienced users may well need to fetch a new image file at some point (to upgrade, say) and need to know that a new changelog is required too.

I'd also propose some initial startup magic that strongly advises immediately saving the image under a new name so that the original stays clean. I'm not *completely *convinced that this is required since it ought to be easy enough to re-extract a clean version from an archive but maybe not all users on all platforms get that opportunity. As an example I can see how a unix install might work by having the user start the squeak shellscript, which for a fresh start copies an image from/usr/thingy/hiddenweirdfiles/local/var/etc to the current directory before starting squeak. To restart from a fresh image by using said script they may well be ok but I think it might be valuable to have them save under a more personal name anyway just to provide some context when later helping to debug some problem. Maybe this needs to be platform dependent.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful Latin Phrases:- Utinam logica falsa tuam philosophiam totam suffodiant! = May faulty logic undermine your entire philosophy!

On 1/9/13, tim Rowledge <[hidden email]> wrote:
-1


I like the All-In-One. I can easily move the All-In-one folder from a
Windows machine to a Linux machine and continue my work there. I do
this often. No installation, neither on Windows nor on Linux. Very
convenient.

And I wonder what is difficult about recreating an already existing
artifact (=a collection of files plus a configuration file) for Squeak
4.3 with newer versions of everything for Squeak 4.4

What kind of know-how is missing at the moment to do that?

Here is a model
http://ci.lille.inria.fr/pharo/view/Pharo%202.0/job/Pharo-2.0/lastSuccessfulBuild/artifact/Pharo-2.0-one-click.zip

Can't we copy the build script?

--Hannes

On 9 January 2013 21:26, H. Hirzel <[hidden email]> wrote:
Where did those files come from? How do you put them together? What
magic plists need to have metadata updated?

frank

On 09.01.2013, at 13:55, Frank Shearar <[hidden email]> wrote:

> Where did those files come from? How do you put them together? What magic plists need to have metadata updated?


It's not magic, but we are simply using the Mac OS X application bundle format:

http://developer.apple.com/library/mac/documentation/CoreFoundation/Conceptual/CFBundles/BundleTypes/BundleTypes.html

There is a single Info.plist for the Mac app meta data. It has been created by John McIntosh many years ago and then modified. For a new version, only the entries containing version-dependent strings need to be modified (for Etoys that's CFBundleGetInfoString, CFBundleName, CFBundleShortVersionString, and CFBundleVersion).

The image/sources go into the Contents/Resources/ folder because that's where "misc" files go in the bundle format.

Windows and Linux do not have a bundle format, so there the bundle appears just as a directory. We stuff the VMs for these platforms inside the bundle structure because the Mac just ignores the files it doesn't need.

The Linux shell script sets up the path to the right VM (e.g. Intel/ARM/64 bit) and to the image. On Windows, the VM.ini file does the same (it would be nicer if the Windows VM + plugins were in a separate directory, but I hear that is not easy). If these files had version strings in them, they would have to be updated just like the Mac's Info.plist.

So in short, the all-in-one is a Mac VM with some other VMs stuffed inside.

HTH,

- Bert -

> I'd also propose some initial startup magic that strongly advises immediately saving the image under a new
> name so that the original stays clean. I'm not *completely *convinced that this is required since it ought to be

I had the same thought when I made the first release-candidate with
read-only image and changes file.  That way a reminder warning is
produced on startup where the user can simply save as.  Intsead of
this warning we could simply produce the Save As dialog box (but with
the warning message) offering the user to simply enter their desired
name and press Enter or click Cancel to not.

On 09.01.2013, at 15:12, Chris Muller <[hidden email]> wrote:

>> I'd also propose some initial startup magic that strongly advises immediately saving the image under a new
>> name so that the original stays clean. I'm not *completely *convinced that this is required since it ought to be
>
> I had the same thought when I made the first release-candidate with
> read-only image and changes file.  That way a reminder warning is
> produced on startup where the user can simply save as.  Intsead of
> this warning we could simply produce the Save As dialog box (but with
> the warning message) offering the user to simply enter their desired
> name and press Enter or click Cancel to not.


This is hard with the all-in-one because you would also have to specify a folder where to put the copied file.

And e.g. on Debian the inisqueak script actually copies the image+changes from /usr/share to your current directory IIRC. In that case, another copy would be superfluous.

We'll first have to get our story straight, then add magic if we still deem it appropriate.

- Bert -

On 2013-01-09, at 5:01 PM, Bert Freudenberg wrote:

I think the best way to do the story straight is to keep the releases separate. I really find distasteful the idea of a bunch of big files hidden in a Mac .app package in the interest of all-in-one, especially if it is Windows stuff.
I think if someone wants to easily be able to copy their stuff back and forth between platforms, it should be easy to throw a couple of separate platform downloads into a folder and subsequently move that folder.

Ken G. Brown