[sugar] RFC: activity bundles

[Dan Williams]

On Mon, 2006-09-04 at 11:40 +0200, Marco Pesenti Gritti wrote:
> 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.

Right; I've worked with Apple bundles before quite a bit and thought
about them for this too.

> > 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.

Good point.  Hopefully we'll never have to show that; we should have
very well-defined failure cases here, and that was the point of a
single, unambiguous build number.  If the type_id and version number of
an activity are the same as another activity that's being installed,
then the new installation fails.  Only if the build number were higher,
or of course if the type_id is different, does the new one get
installed.

Another thing that will go into the spec is arbitrary directory names.
The activity _cannot_ rely on the activity bundle directory name, as
Sugar will change that name at will to prevent activity bundle
conflicts.

> > 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 :)

Right; there won't be very tightly-defined type/creator stuff; and
hopefully we won't be displaying data by a document icon either.

> > 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.

Yeah; since localization is activity-defined (GTK and pygtk apps would
use gettext, but I'm sure other methods will crop up) the activity
bundle spec only defines where to get the activity name localizations
from.  To this end there I'm going to update the proposal to include
individual activity name localization files in a separate directory.
Cramming them all into one file, as Blizzard pointed out, is madness :)

Dan

> Thanks,
> Marco
> _______________________________________________
> Sugar mailing list
> Sugar at laptop.org
> http://mailman.laptop.org/mailman/listinfo/sugar