[Community-news] on splitting Sugar

[Tomeu Vizoso]

On Wed, Apr 23, 2008 at 10:43 PM, John Gilmore <gnu at toad.com> wrote:
> > > That said, Sugar needs to
>  > > be disentangled. I keep using the omelet analogy, claiming it needs to be a
>  > > fried egg, with distinct yoke and white, rather than having the UI,
>  > > collaborative tools, power management and radios merge into one amorphous
>  > > blob.
>  >
>  > My understanding is that the Sugar UI is composed of inseparable
>  > components because we wanted to give an integrated and coherent
>  > experience. In which way are you suggesting to split Sugar?
>
>  It's possible to provide a coherent experience by coordinating work
>  among several projects, rather than by forcing all the work into a
>  single "take it or leave it" project.
>
>  Some of the work below is already done, some is agreed to, some may
>  never be done.  Here's my take on the fracture lines on which to
>  shape the diamond of Sugar:
>
>  The collab framework should definitely be split, so that apps that run
>  on any GUI can collaborate (with apps that run on their own GUI or on
>  another).
>
>  The window manager ("shell") should be split from the application
>  toolkit.  This is a fairly small job, but nobody's done it.  Right
>  now, Sugar apps don't run on other window managers (they lack icons),
>  nor do they work across a TCP connection (like every other X
>  application) because the Sugar shell is looking *in its own local
>  filesystem* for the application's icon.  There appear to be other
>  problems, which are easy to reproduce by setting DISPLAY on your OLPC,
>  pointing it to any Linux machine that runs X, and then trying to start
>  a Sugar activity.  Similarly, it should work cleanly for an ordinary
>  Linux app to be displayed remotely on an OLPC screen.  This is the basic
>  promise of X, but small dumb bugs break it currently.
>
>  The Sugar file system ("datastore / journal") is in my opinion a major
>  mistake, and should be separated from the application toolkit.  There
>  are good reasons that hierarchical filesystems rather than
>  blog-structured journals (or more complex databases) are the norm on
>  every major OS.  Apps should be able to use a standard "file open
>  dialog", and get the journal on OLPC, while the same source code gets
>  the Finder/Open Dialog Box on MacOS, for example.
>
>  The presence implementation only works on access points and on meshes --
>  but not on non-meshed, ad-hoc 802.11.  The vast majority of computers
>  with 802.11 don't have mesh, but they would benefit from being able to
>  "see" nearby laptops and share applications with them (whether or not
>  a local access point, or global Internet access, is working).  For full
>  integration, this probably requires some driver work, but most of the work
>  is probably at a daemon and library level.
>
>  These are the four major axes I see refactoring Sugar along.

I agree with most of that, but I think that the biggest problem with
sugar on windows is the shell. It provides several features already
provided by the windows shell, and that overlap would cause severe
confusion and frustration to users.

Any suggestion on how to approach this?

Thanks,

Tomeu