Mike Hearn wrote:
On Thu, 31 Aug 2006 20:36:27 -0400, 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 :)
Hey,
A few assorted thoughts:
* Host Versioning: I think it may be better to let activities
handle this themselves. Consider an activity that can run on
Sugar v1 but will use some new APIs added in Sugar v2 if
they are available. If this (critical) information is
expressed via bundle metadata then Sugar itself will end up
displaying a generic message like:
"This activity is designed for a newer laptop. It will run on
yours but with reduced functionality"
But that might not be right! If the activity code itself takes
care of this (maybe helped by some convenience apis) then it can
take a more appropriate action. Maybe the new APIs it needs
improve performance or looks but nothing else. It would be dumb
to scare the user by mentioning this. On the other hand maybe
some critical feature won't work unless Sugar v2 is present.
It would be worth notifying the user exactly what won't work,
in that case.
None of this is possible if Sugar itself checks activity host
versioning.
I think both should be possible. We don't know how the activities ABI
will be changing yet and how much work will be necessary to support
multiple versions of the platform (even degradating functionalities). I
think in some cases requiring a certain platform version to install the
activity will be the simpler solution.
* SVG icons take a lot of CPU time to render, relative to uncompressed
bitmaps. Maybe there should be some support for noticing if they
change and caching them?
Yep, I think so.
* XML is fully specified and the edge cases are handled whereas an
INF/.desktop style derivative isn't really. I know XML is ugly
but still ....
Hmm not sure. Desktop files has some simple specification we might want
to inherit:
http://standards.freedesktop.org/desktop-entry-spec/latest/
Glib key files implementation is based on this.
Marco
_______________________________________________
Sugar mailing list
[email protected]
http://mailman.laptop.org/mailman/listinfo/sugar
