[sugar] Re: RFC: activity bundles

[Mike Hearn]

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.


* There is no convenient API to refer to binary-relative files 
  on Linux. For autopackage we now have a simpler approach to
  making relocatable software - a file descriptor with a pre-determined
  number is opened before main() runs pointing to the right
  prefix. Software can then simply open("/proc/self/fd/200/myfile.png")
  I think this is better than relying on the current working dir
  being set ... the program may want to change it during operation.

  This also solves problems with the ton of legacy code that does
  not ever expect to be outside of /usr


* 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?


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


Hope that helps!

thanks -mike