[Sugar-devel] [IAEP] addons.sugarlabs.org is starting to work
tomeu at sugarlabs.org
Thu Feb 19 12:24:39 EST 2009
On Thu, Feb 19, 2009 at 18:23, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
> On Thu, Feb 19, 2009 at 18:18, Carol Farlow Lerche <cafl at msbit.com> wrote:
>> How does the Mozilla add-on functionality decide if there is a version or
>> platform conflict for browser add-ons? it must be a piece of the browser
>> that does this via some interaction with data on the server. Shouldn't
>> there be a similar process here? It is frustrating to download something
>> (which can be a problem with bad/intermittent connectivity) only to find
>> that you can't use it.
> Addons allow the uploader to specify for which versions of the
> platform that addon will work with, and editors do test on those
> platforms before the addon is available to the general public.
Oh, also users can "review" addons and rate then.
>> On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd <wadetb at gmail.com> wrote:
>>> On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso <tomeu at sugarlabs.org> wrote:
>>>> A long time ago, when using bundles was decided as necessary, the idea
>>>> was that there would be something called the "Sugar platform" that
>>>> would specify every component that an activity author can rely on
>>>> being available for their activities to use.
>>>> That would include etoys, csound, pygame, glibc, gtk, and any other
>>>> components on which the sugar shell may not depend but activities can
>>>> expect to be there.
>>> I've been part of this discussion a couple of times now and to me it seems
>>> like the original vision is pretty much the right way to go. As an activity
>>> author I love the simplicity of activity bundles just being ZIP files.
>>>> Everything on which an activity depends and isn't part of the platform
>>>> should be bundled inside the .xo.
>>> Aside from this point! Some dependencies are simply too complex to
>>> bundle, and can introduce conflicts with the host system.
>>> Aleksey proposed adding a simple "depencencies" line to activity.info.
>>> This would be parsed by Sugar in a distribution specific manner by a
>>> running 'sugar-check-dependencies' script that could be provided by each
>>> distribution. We would define our own set of dependency names and manually
>>> map them to each distro that we package for.
>>> For example, a 3D activity which used OpenGL could list "dependencies =
>>> opengl", and then the various distributions could handle that as needed in
>>> the script.
>>> If the system does not contain the required dependencies for an activity,
>>> in my opinion Sugar should prompt the user to install the dependencies and
>>> then not launch the activity.
>>> IAEP -- It's An Education Project (not a laptop project!)
>>> IAEP at lists.sugarlabs.org
>> "It is difficult to get a man to understand something, when his salary
>> depends upon his not understanding it." -- Upton Sinclair
>> IAEP -- It's An Education Project (not a laptop project!)
>> IAEP at lists.sugarlabs.org
More information about the Sugar-devel