WSJ

[Albert Cahalan]

Mike C. Fletcher writes:

> If we are serious in our goal of educating children, we need to do a
> few things, and some of this requires a readjustment and a
> detachment from the question of which hardware goes where.  Does the
> hardware matter?

Yes.

Standardized hardware means I can count on having things, and I
can optimize. There is a microphone. There is an input that can
measure DC voltage levels. There is a camera that does 640x480.
The side of the camera with the user's face is quite predictable.
There are 3DNow! instructions. JPEG compression levels can be
made appropriate to the display. Images can be in ideal sizes.
The kernel and X server don't need to ship a zillion drivers.
The control panel can be managable.

> we should port to the other inexpensive laptops, if a country
> decides to go with EEEs or Classmates, we should be in there
> offering an EEE or Classmate-optimised Sugar + Activities +
> Content that they can load onto those machines

This is a mixed bag. It dilutes the message.

> we need to make use on multi-user machines easy, where Sugar
> is just a desktop manager session that is run just as one
> would run KDE or Gnome (so that computing lab situations can
> let children use Sugar's safe, rich  without giving up the
> ability to run KDE/Gnome)

Activities which don't need special XO hardware features
should just run, right from the GNOME menu, without anything
extra. Activity authors should have an easy way to specify
if this means full-screen or 1200x900 in a window.

The ultimate goal should be to have activity isolation be a
normal part of the business desktop. Sugar can melt away as
the ideas get put into regular software.

> For the other countries, we need to address their concerns.  It
> seems that at least some of the concern is because we have
> introduced a huge barrier to entry for application porting.  That
> means we have a pool of dozens of applications instead of hundreds
> or thousands of activities/applications.  Even compared to other
> Linux-based solutions, we have a tiny pool of available
> applications, many of which are still in reasonably early stages of
> development.  We are missing whole classes of application/activity.

I feel like such a conspiracy theorist here, but...

The thought that has always come to my mind is "Python cabal".
At times it feels like things are maliciously non-standard,
as if intended to exclude normal Linux software.

A simple xterm should work, no matter if it is started from
the console or if it is on a separate machine with $DISPLAY set.
Switching to and from the xterm should work perfectly. The icon
and title should be used for the donut display.

Shipping full-screen programs does not mean that the window
manager should be incapable of handling anything else. It may
be good for the window manager to automatically attempt to
size a window to fill the screen, but the window manager needs
to handle the case when that doesn't work.

> * we need some way for a regular, non-Sugar-fied application to
>   be installed (easily) and run (with reasonable support) on a
>   Sugar desktop.  We should at least have the application-depth
>   of a *Linux* desktop available to our students.
>       o Even if they don't integrate nicely and they have file
>         dialogues instead of Journal dialogues (so you'll have
>         to switch to the Journal and add the file manually)...
>         practicality beats purity

Hack every common toolkit. Shared libraries are great.
If you change the toolkit library, you get journal support.