[sugar] First impressions of a B4 machine

[Albert Cahalan]

Ivo Emanuel Gongalves writes:

> Paint, is this the famous Tux Paint?  I have heard that it is a very
> neat drawing app for kids, but what I saw so far was an Open/Save
> interface more awful than the one used by the other porgrams.  What
> the Niflheim where the developers thinking?  It doesn't make any sense
> for the children.  Heck, it doesn't make any sense to me.  Somoene,
> please fix it.

No way. This is Tux Paint:

http://www.tuxpaint.org/screenshots/tuxpaint_nokia770.jpg
http://wiki.laptop.org/wiki/Tux_Paint

Getting Tux Paint properly adapted to the OLPC XO was a project I was
working on while waiting for the chipset (EC,CaFE,Marvell) docs which
were supposed to appear. (I really wanted to write free firmware.)

I put the Tux Paint adaptation aside four months ago. It was all
very frustrating, and I got the feeling that outsiders weren't all
that welcome. I'm just catching up on news for the past few months,
and it looks like very little has changed.

The first problem was the needless use of undocumented and non-standard
interfaces for everything. I really don't wish to guess at how a sugar
app is supposed to behave, especially when the interfaces are/were
somewhat volatile. Python APIs won't do. Pardon me for suspecting that
all information is word-of-mouth over the cubicle walls in Cambridge.
I do see that sugar is now supposed to tolerate a regular full-screen
X11 app as a sort of second-class citizen; this is an improvement.
Perhaps somebody would be happy to fix the "Hello World!" program
included below, not cheating with wrappers or extra libraries.

The second problem was the hardware change. Despite being decently
optimized for performance, Tux Paint is difficult for the hardware.
The graphics are pretty, anti-aliased and alpha-blended. The sounds
are nice, with stereo according to mouse position. On B2 hardware,
there isn't much memory available for the app. I remember it being
about 50 MB, but it looks like about 37 MB right now. B2 hardware
also has a very slow CPU. (clocked slower, no cache, and a USB bug)
To run on the B2 hardware, Tux Paint needs to be butchered. I'd have
to remove all sound support, remove all stamp (clip art) support,
remove the "undo" feature, remove odds and ends like printing, cut
back on the color depth to 15bpp (despite this being even slower),
and so on. I was starting this sad task when the surprise announcement
about production hardware (256 MB, decent CPU) was made. It looks
like the production hardware can run Tux Paint in full glory as long
as sugar doesn't grow to consume the extra 128 MB, but I wouldn't
be able to test the result. Should I keep butchering? Why bother?
I can't test on anything like what the kids will be using.

BTW, the Nokia 770 (screenshot above) is 800x480 with 64 MB.
The lower screen resolution helps save memory. There is a bit
of mild butchering too, but nothing like a B2 XO requires.

//////////////////////////////////////////
//
// Hello World!
//
// CFLAGS:  -Wall -I/usr/X11R6/include
// LDFLAGS: -Wall -L/usr/X11R6/lib -lX11
//
#include<X11/Xlib.h>
#include<stdio.h>
#include<stdlib.h>

#if 0

#include <dbus/dbus.h> /* for <dbus-connection.h> */

struct DBusObjectPathVTable dbopvt = {
        .unregister_function = ,
        .message_function = ,
};


static void do_dbus_bloat(void){
        DBusError *dbe; // can use NULL if we don't care about the reason

//      DBusConnection *dbc = dbus_bus_get(DBUS_BUS_SYSTEM,&dbe);
//      DBusConnection *dbc = dbus_bus_get(DBUS_BUS_SESSION,&dbe);
        char *addr = getenv(DBUS_SESSION_BUS_ADDRESS);
        DBusConnection *dbc = dbus_connection_open(addr,&dbe);

        // Use the Presence address, or my own address?
        // Fuck if I know. I probably need to send the
        // "ActivityAppeared (o: activity)" signal.
        DBusMessage *dbm =
        dbus_message_set_interface(dbm,"org.laptop.Sugar.Presence");
        dbus_message_set_path(dbm,"/org/laptop/Sugar/Presence");


        dbus_connection_register_object_path(dbc,"path goes here",&dbopvt,vp);
}

#endif

static void showenv(char *envp[]){
        FILE *fp = fopen("/tmp/environ","w");
        while(*envp){
                fprintf(fp,"%s\n",*envp);
                envp++;
        }
        fclose(fp);
}

int main(int argc, char *argv[], char *envp[])
{
        showenv(envp);
        Display *dpy = XOpenDisplay(NULL);
        if (!dpy) {
                fprintf(stderr, "ERROR: could not open display\n");
                exit(1);
        }
        int scr = DefaultScreen(dpy);
        Window rootwin = RootWindow(dpy, scr);
        //Colormap cmap = DefaultColormap(dpy, scr);
        Window win = XCreateSimpleWindow(
                dpy, rootwin, 0,0, 1200,900, 0,
                BlackPixel(dpy,scr), BlackPixel(dpy,scr)
        );
        XStoreName(dpy, win, "hello");
        GC gc = XCreateGC(dpy, win, 0, NULL);
        XSetForeground(dpy, gc, WhitePixel(dpy, scr));
        XSelectInput(dpy, win, ExposureMask | ButtonPressMask);
        XMapWindow(dpy, win);

        for (;;) {
                XEvent e;
                XNextEvent(dpy, &e);
                switch(e.type) {
                case ButtonPress:
                        XCloseDisplay(dpy);
                        return 0;
                case Expose:
                        if (e.xexpose.count < 1)
                                XDrawString(
                                        dpy, win, gc, 10, 10,
                                        "Hello World!",
                                        12
                                );
                        break;
                }
        }
}
/////////////////