The UX (both keyboard and software) was .. just awful.
I still don't understand why the system performed so poorly, I know a lot of Sugar was written in Python, but there must have been some very fundamental problems with it. Switching to an existing lightweight X window manager was a much better (but still not good) experience.
For example, the icon for each Sugar "activity" was an SVG file. When you started an activity, its icon would "throb" in the center of the screen, fading in and out. Guess how the throbbing was implemented.
That's right, it would perform string substitution on the SVG file, filling in the actual colors for macros embedded in the SVG, then reparse and redisplay the SVG. For each frame.
Had it been a simple matter of being written in Python, Sugar might've been usable. But it was shitty Python and that's what killed it.
That's intriguing!
I can imagine a path to how they got there:
1. PyGTK (or whatever they were using) has methods to load and display an image.
2. A supported image type is svg+xml
3. SVG is vector graphics. Awesome! Let's use that.
4. Animation is needed, so we consider just ramping the opacity attribute, scaling attribute, etc.
5. We don't have any methods for DOM access. Oops.
6. However, we do have our loaded SVG file which is just plain text.
7. Well, we can just s/OPACITY/RAMP_VALUE or whatever and display that for our animation. That at least doesn't require a read from the harddrive for each frame. :)
Speaking of which-- I've seen developers do animation by repeatedly reading a file from the harddrive in the same process/thread as a realtime audio engine.
Edit: clarification
The harddrive was flash memory, no? So we're probably talking hundreds of microseconds to read the file into memory. Let's say 670 microseconds for a rough guess.
That still leaves 41 milliseconds to parse and display the file.
Of course the animation is happening at an arbitrary program's load time which is probably particularly CPU heavy. But OLPC apparently had two cores, so the process controlling the SVG animation should have been able to safely hit its deadlines.
I'm going to guess that the animation was smooth when trivial consumer single-process apps were loaded and janky when something like an office application was opened.
Am I right, or was it always janky?
There were no "office" applications for Sugar. The closest it got were Sugarized versions of Firefox and AbiWord. The animation, as I recall, was somewhat jankier when attempting to load one of these.
Now I'm wondering whether the lack of smoothness was actually jank or just the choice to animate at a low frame rate.
The animation looks bad but generally uniform in its timing. So I'm guessing whoever coded that just assumed their method of animation was so klunky that they went ahead and set the delay interval to a large value.
It might have helped to use a retro-style step animation, like filling up a cup a quarter at a time where each 1/4 cup is a lighter shade of the same color.