[sugar] RFC: activity bundles

[Dan Williams]

On Fri, 2006-09-01 at 11:22 +0200, Marco Pesenti Gritti wrote:
> Bert Freudenberg wrote:
> >
> > Am 01.09.2006 um 02:36 schrieb Dan Williams:
> >
> >> http://wiki.laptop.org/go/Activity_Bundles
> >>
> >> Comments welcome.  Especially from you, Blizzard, since easily
> >> installable and transferable activities is your baby :)
> >
> > You wrote: 'Each activity bundle must, in its root directory, contain 
> > a file with the same name as the activity bundle, but ending in 
> > ".info" rather than ".activity"'.
> >
> > IMHO a fixed name, like "activity.info" would be preferable.
> >
> > We could then rename the bundle, try different versions etc. without 
> > needing to touch the inside. Also it would be simpler to script:
> >
> >     grep default_type *.activity/activity.info
> >
> > It's common practice as well, like JAR's manifest.mf or OS/X bundle's 
> > info.plist.
> 
> Dan,
> 
> I tend to agree with Bert reasoning here.

Ok, will fix.

> 
> More comments:
> 
>  >These should always be stored in an activity-specific directory in the 
> user's sugar profile, available >through the SUGAR_PROFILE environment 
> variable
> 
> Currently SUGAR_PROFILE is the profile name and the actual profile path 
> is ~/.sugar/$SUGAR_PROFILE. We might specify this or have the session to 
> export SUGAR_PROFILE_PATH based  on SUGAR_PROFILE.

I'm a bit hesitant to rely on hardcoded magic paths like ~/.sugar :)  We
may not end up calling this thing "sugar".  So I'd prefer to have the
full path to the profile specified in the environment variable.

> >icon = activity-web
> >This key is optional. It points to the activity's icon. The
> >icon is first searched for in the >activity bundle's root directory, and
> >if not found, is looked up in the current GTK icon >theme. It cannot
> >contain a path.
> 
> What is the actual icon filename when looking up the bundle directory? 
> $icon + '.svg' or should the field be icon = activity-web.svg in that case?

Should make this more clear.  To be honest, I think we should restrict
icons to be SVG, and require them to use the CSS styles we specify so we
can enforce a consistent visual style.  That way, we don't get into the
whole file extension mess, and where if you specify the extension it's
looked up in the activity first, etc.  If the visual characteristics of
icons in the panel are important, which they are, we should enforce
that.

> We also need to specify the icon format (maybe thinking a bit more to 
> the css properties and possibly improving them). Something I was 
> thinking is that the css should be external, only the class attributes 
> should be required in the svg files... librsvg does not support external 
> css yet but we can just add the whole css to the svg file after loading.

Sounds good.  We should then reject icons that don't have every element
be part of one of the CSS classes Sugar specifies.

> >default_type = _web_olpc._udp
> >Each activity must have a default type. This must follow the
> >mDNS specification for serivce types and must be globally unique. This
> >key is required. It is used as the service type for the mDNS service
> >when the activity is shared.
> 
> Do we actually want to make this required? There are activities that 
> might not be sharable (terminal for example) or that haven't implement 
> sharing yet.

They should probably all have a default type though...  the other
alternative is to reverse the D-Bus service name, s/./_/ and use that as
the default type.  I'm not sure that having two such unique identifiers
is useful.  The simpler the better.  We also have to think about how
we're presenting this to kids when they make their own activities.

>  >show_launcher = yes
>  >This key is optional. If specified, it indicates that the activity 
> should show in the Sugar <http://wiki.laptop.org/go/Sugar> panel 
>  >launcher, represented by the activity's icon. If specified, the 'icon' 
> key must also be specified.
> 
> Since it's optional might be worth adding that it defaults to no.

Per your next mail, I'll default it to yes.

Dan

> Marco