[sugar] Write needs your help (was Re: Programming environments on the XO)

[Benjamin M. Schwartz]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Erik Garrison wrote:
| On Thu, Jul 17, 2008 at 10:16:07AM +0200, Tomeu Vizoso wrote:
| Given the quantity of free software available for Linux distributions
| relative to the quantity of available sugarized applications, I believe
| that repeats of this pattern will be inevitable.

I am not so sure.  Given the tremendous amount of crappy duplicate
software, I suspect that we only need to execute a handful of ports to
achieve complete functionality.  Conversely, there is no good Free video
editor for Linux, easy 3D modeler, numerical analysis environment .... so
in many cases, there's simply nothing to port.

| As I understand, there are a variety of problems with the use of
| unsugarized applications:
|
|     - UI issues because of high screen dpi and small size.
|     - Journal integration.
|     - Resource utilization.
|     - Bitfr?st and security concerns.
|     - Collaboration.
|
| I expect there are others and would be happy to know them so that I
| better understand this problem.

The biggest one, much higher on my list than any of the above, is
incompatibility with the Activity launching mechanism and window manager.
~ Because of this issue, standard X/Linux applications that have been
correctly repackaged as .xo bundles won't even start.  It appears that
switching to the Freedesktop.org startup notification system and a
modified metacity window manager may be able to resolve this.

| To simplify Journal/datastore integration:
|
|  *) Remove the Bitfr?st application isolation scheme or modify it such
| that Activities could write to arbitrary locations in which the olpc
| user has write permissions.

It is already the case that every activity can write to $HOME, which is
currently set equal to $SUGAR_ACTIVITY_ROOT/instance/ .  This was not
always the case, but in any recent build this is not a problem.

|  *) Make the Journal a watcher and indexer instead of a gatekeeper to
| the user's data so that applications no longer need to be ported to
| write data and metadata via the datastore API.

In my view, the principal reason that this has not been done is that the
Journal does not support multiple-file entries.  We could tar up all files
created into a .tar file, but what is its mime type, and how do you access
its contents?  Once the datastore supports multi-file entries, it will be
trivial to save all created files after each session.

| To provide a fallback, base-level collaboration system:
|
|  *) Offer a collaboration directory in the user's /home/olpc/, such that
| simple filesharing can take place.

I am not sure what you envision here, but I would caution that the
difficulty in sharing files is in the low-level network and high-level GUI
design.  TCP on the mesh has been problematic (#6463), and users cannot be
expected to make use of a sharing mechanism that operates only at the
command line.

- --Ben
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkh/g/QACgkQUJT6e6HFtqTKVgCgka7WH2Q0AdmOFX4QMCC4eBXT
5pEAoJ3kh0eH8Y0IP6Zul8GYxqsaqFIn
=WGf+
-----END PGP SIGNATURE-----