On Thu, Feb 19, 2009 at 18:23, Tomeu Vizoso <to...@sugarlabs.org> wrote: > On Thu, Feb 19, 2009 at 18:18, Carol Farlow Lerche <c...@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. Tomeu > Regards, > > Tomeu > >> On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd <wad...@gmail.com> wrote: >>> >>> On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso <to...@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. >>> Best, >>> Wade >>> >>> _______________________________________________ >>> IAEP -- It's An Education Project (not a laptop project!) >>> i...@lists.sugarlabs.org >>> http://lists.sugarlabs.org/listinfo/iaep >> >> >> >> -- >> "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!) >> i...@lists.sugarlabs.org >> http://lists.sugarlabs.org/listinfo/iaep >> > _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
