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. <br>
<br><br><br><div class="gmail_quote">On Thu, Feb 19, 2009 at 9:12 AM, Wade Brainerd <span dir="ltr"><<a href="mailto:wadetb@gmail.com">wadetb@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="gmail_quote">On Thu, Feb 19, 2009 at 6:15 AM, Tomeu Vizoso <span dir="ltr"><<a href="mailto:tomeu@sugarlabs.org" target="_blank">tomeu@sugarlabs.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
A long time ago, when using bundles was decided as necessary, the idea<br>
was that there would be something called the "Sugar platform" that<br>
would specify every component that an activity author can rely on<br>
being available for their activities to use.<br>
<br>
That would include etoys, csound, pygame, glibc, gtk, and any other<br>
components on which the sugar shell may not depend but activities can<br>
expect to be there.</blockquote><div><br></div><div>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. </div>
<div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Everything on which an activity depends and isn't part of the platform<br>
should be bundled inside the .xo.</blockquote><div><br></div><div>Aside from this point! Some dependencies are simply too complex to bundle, and can introduce conflicts with the host system. </div><div><br></div><div>Aleksey proposed adding a simple "depencencies" line to <a href="http://activity.info" target="_blank">activity.info</a>. 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.</div>
<div><br></div><div>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. </div><div><br></div><div>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.</div>
<div><br></div><div>Best,</div><div>Wade</div><div> </div></div>
<br>_______________________________________________<br>
IAEP -- It's An Education Project (not a laptop project!)<br>
<a href="mailto:IAEP@lists.sugarlabs.org">IAEP@lists.sugarlabs.org</a><br>
<a href="http://lists.sugarlabs.org/listinfo/iaep" target="_blank">http://lists.sugarlabs.org/listinfo/iaep</a><br></blockquote></div><br><br clear="all"><br>-- <br>"It is difficult to get a man to understand something, when his salary depends upon his not understanding it." -- Upton Sinclair<br>