[sugar] RFC: activity bundles

[Marco Pesenti Gritti]

Jacob Rus wrote:
> Dan Williams wrote:
>> http://wiki.laptop.org/go/Activity_Bundles
>>
>> Comments welcome. Especially from you, Blizzard, since easily
>> installable and transferable activities is your baby :)
>>
>> Dan
> Apple's very similar application bundles may be a useful inspiration 
> here.  They are quite well [documented][1] at Apple's developer 
> website.  In particular, there are a few things in OS X application 
> [info.plist files][2] that may be useful for OLPC info files.
>
> 1. Info.plist files have both a monotonically increasing integer
>    version (CFBundleVersion), and a human-readable version string,
>    (CFBundleShortVersionString).

I tend to think this would be useful. I don't think we should expose it 
during a normal installation process but when things breaks or there are 
anomalities, it would be preferable to show a human readable version to 
the user then an integer.

> 2. Applications declare which file types they are able to open,
>    and which icons to use for those file types.

I think the associations between files and activities in sugar will not 
be usually MIME based.
There is still the case of files downloaded from the web, which I'm not 
sure how to handle yet (pdf for example). Maybe this could work for that 
case but I want to avoid to get in the business of file types 
association editing at any cost :)

> 3. The LSMinimumSystemVersion key is used to indicate the minimum
>    operating system version the application will run on.
>

Yeah I think I brought this up with Dan too. Indicating a minimum 
version or an exact one depends on which kind of ABI policy we decide to 
adopt.

> Also, OS X handles all internationalization through ?LangName?.lproj 
> folders inside the resources folder for the application bundle.  These 
> contain localized versions of every string applicable to the 
> info.plist files, in files called InfoPlist.strings, and other 
> internationalized strings in a file called Localizable.strings.  This 
> way isn't necessarily better, but keeping all the localized strings 
> for a particular language for a particular application in one place, 
> instead of leaving some of them in the main info file, and others 
> elsewhere, seems like a good idea to me.

Yeah, Dan was considering something similar if I'm not mistake.

Thanks,
Marco