Mini-Conference Proposal: desktop applications

[Tomeu Vizoso]

On Sat, Mar 22, 2008 at 1:02 PM, Marco Pesenti Gritti
<mpgritti at gmail.com> wrote:
> Sugar breaks with the standard desktop metaphor by design and doing so
>  it introduces incompatibilities at several levels. The barrier between
>  activities and standard applications proved to be a critical problem
>  in practice. Fortunately most of the current code base is using GNOME
>  and freedesktop libraries, formats and semantics. I'd like to present
>  an analysys of the points of incompatibility. Discuss how to integrate
>  desktop applications, beginning from the user experience requirements.
>  Propose solutions and trade-offs to reconcile the incompatibilities in
>  the window management and activity launching area.

Things that we do differently and that clash with traditional apps:

- Activities not applications: Traditional applications are more like
tools that can be used to perform several different tasks. A central
point of the Sugar UI is that activities are individual tasks instead
that the user performs with the laptop and that can be stopped,
resumed and shared at any point.

- Sugar shell integration: the sugar shell performs some
functionalities that traditionally were implemented inside each
application. There needs to be some communication between the activity
and shell processes in order to do so.

- Security: activities run in their own space, isolated from the rest
of the software. The security framework tries to give activities all
the capabilities that may be needed, but not the ability to cause harm
to the system or violate the privacy of the kid.

- Small screen: the screen is small so it was decided that activities
would have just one window always maximized. This also matches the
goal of activities like single-tasks.

- Modifiability: source code is interpreted, so the kid can study the
code, modify it, and see the results without more fuss.

Hope that clarifies things a bit,

Tomeu