9.1 Proposal: Files

[david at lang.hm]

On Tue, 28 Oct 2008, Mel Chua wrote:

> 1) Compatibility with existing applications
>
> Feature: 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
-------------- next part --------------
_______________________________________________
Devel mailing list
Devel at lists.laptop.org
http://lists.laptop.org/listinfo/devel