On Tue, 28 Oct 2008, Mel Chua wrote:
1) Compatibility with existing applicationsFeature: Making it possible to convert Linux/X applications into Activity bundles, retaining all important functionality, without source code alterations. Current Sugar: Has a custom API for saving data that's "difficult to work with" (help clarifying, please - why is this hard?)
part of it is that it's just so different than any other system, part of it is that there are many more pieces involved (for many apps there is no other reason to use dbus for example)
3) Resting on upstream stability: Feature: It should be possible for upstream contributors to see, at any given point in time, how features on, code in, and bugs filed against the XO trace back to the applicable things that they can fix in the standard version of their upstream project. Current Sugar: Actually, I don't know how this works at all. Have there been problems getting needed help from upstream? Why?
there are probably many things that never get submitted to upstream, simply becouse they are such drastic departures
Potential solutions: Use the standard versions of upstream projects without modification. Others?
seperate out the modifications that you want to support small screens, low memory, etc from those that would be needed to support sugar specific things like the journal.
4) Collaboration Feature: Provide a standard mechanism for Activity collaboration between an XO and another computer not running Sugar. Current Sugar: Install Sugar on the other computer and use Jabber to collaborate. (Time-consuming, and not always possible given time and privilege constraints on the non-Sugar computer.) Potential solutions: Use standard non-Sugar-to-non-Sugar computer collaboration systems, including thoes based on file-based asynchronous collaboration. Make cross-platform non-Sugar versions of Sugar Activities (and a script to autogenerate these from native-Sugar Activities) that can somehow collaborate seamlessly with XOs. Others?
there are other softwrae packages out there that can collaberate over a Jabber server. In many ways I'd love to see the Jabber-based collaberation become the standard mode with the pure XO-XO mode intercepting the Jabber communication from the software and doing more efficiant distribution of the information. this would also let the XO serve as a Jabber server for a non-Sugar machine. it doesn't need to handle many users, just handling a few would be enough.
5) Hackability Feature: Indicate how an Activity's functionality and the objects it creates in the Journal map to editable source code files on the XO. This indication should be shown directly in the Sugar GUI for an Activity and also when a user is viewing source code for that Activity. (This can probably be phrased much more coherently. Help?) Current Sugar: There are currently two "views" that coders have to switch between; the underlying filesystem with .py files in nested and named folders, and the Journal view for the same Activity, which does not (afaik) expose a way to get into the source code through the GUI. (Exception: if you hit the "view source" key for Chat, one file of the Chat code opens in Pippy and is editable. Even for this, though, if you want to edit other Chat files, you have to navigate the filesystem.) Potential solutions: Have them be the same view. Others?
they don't need to be exactly the same view, but if you know one you should be able to track it down in the other.
David Lang
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
_______________________________________________ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
