On Nov 21, 2007 1:32 PM, Bill Kendrick <nbs@...> wrote:
> On Wed, Nov 21, 2007 at 01:49:59AM -0500, Albert Cahalan wrote:
> > I'd like to check in lots of OLPC-related changes as soon as I get
> > them done, hopefully this weekend. It really can't go into this
> > release though.
> Excellent. A number of people have contacted me, recently, about Tux Paint
> on the XO. Glad to hear you're looking into it again! Out of curiosity,
For 2/3 of a year I just put it aside.
There is a Python cabal that loves non-standard undocumented
interfaces that are only provided via Python libraries, so it has
been like pulling teeth to expose the non-Python interface and/or
get things switched over to being more standard.
Also the hardware changed. The old hardware had 50 MB left
over after all the bloated Python code got loaded. Now there is
an additional 128 MB, though of course more Python bloat too.
I didn't get the new hardware until just recently.
> what kind of changes will you be making to Tux Paint? Will they be XO-specific
> (via #ifdef, for example), or broader changes?
It's a mix. Some things will need #ifdef, and some things not.
Stuff falls into two catagories, hardware and UI. You may have
noticed two types of #ifdef I added; "SUGAR" is for the UI.
The screen is 1200x900, but blurry. There is often a key on
the keyboard for multiply and divide, with the gradeschool
math symbols. The CPU has 3dNow! instructions. The CPU
does floating point faster if set to 32-bit; I think this may
require setting a mode bit in the CPU. The speakers are
strong from 3500 Hz to 4000 Hz, but weak below 600 Hz
and nothing below about 300 Hz.
The system UI expects to hand files to Tux Paint. It is not
normally allowed for an unpriviliged program to request a
specific file. Looking around in $HOME is blocked. There is
some per-program persistant storage that I can use, but
really I'm supposed to let the system UI handle the files.
The quit button is kind of forbidden, being replaced by
a stop button that kind of does a suspend. The idea is
that one can always keep going from where they last
were. So "stop" is really "save and quit w/o asking".
One can later select the saved data from the system UI
and ask to resume the activity.
I don't even like thinking about scrolling and zooming,
but they might be needed for this slightly older audience.
The competition, a normal wimpy paint program written
in Python, does have those features.
I think we're missing many of the languages from
south-east Asia, western Africa, the Middle East,
India, and the rural areas of South America. A few
of these languages present nightmare-level rendering
difficulties. Letters go in spirals, sort of, with the
whole bunch of them wildly mutating as you add
each additional letter. (connected, of course)
Currently OLPC is not using dead keys. Accents get
typed after the letter they modify. So you get the letter
"A", render it, and then find out later that the user adds
a ring on top... and then the user adds a second accent,
and maybe a bunch more! You only know the letter is
done once a non-accent letter is typed.
I'm going to need to place an X window property on the
window. I hope SDL lets me get at the low-level stuff.
Got any ideas for sharing? Apps are supposed to be
able to be usable by multiple people at once. I guess
the ideal would be that all users edit the same image,
but that doesn't sound easy to code.
There is a camera that does 640x480.
There is a 7-level button for brush size. It maps to
the keys F5 through F8, plus 3 in-between keys.
The mouse pointer is terribly inaccurate.
Programs can't see each other. It seems that the
stamps must go in the main package.
If much of this makes no sense, remember that
the OLPC is designed to let users share hostile
code with each other. Bad programs can't swipe
your files, upload your picture somewhere, etc.
> I'd like to add some fixed-point math support to the Magic API at some point,
> but it'd probably be best if I used some existing library for that, rather
> than try to roll my own. Anyone have recommendations? (The best would
> be something that could somehow be compiled using floating-point for systems
> with FPUs, and compiled as fixed-point for systems that don't (Nokia, Zaurus,
I was thinking I might do that and/or assembly.
Any part in particular that needs to be optimized?
> > BTW, I'm not so sure pre-XP is anything these days.
> > If nothing else, the hardware itself will have died.
> Heh, yeah. I wouldn't be surprised to hear that many schools are still
> running older stuff these days. (When I was in high school, we had nothing
> but Apple IIe systems, aside from the random Mac, until 1992! I have no
> idea how soon the lab full of 486es running Windows 3.1 was replaced when
> Win95 came out...)
It's not like that. Those old Apple IIe systems were tough.
They lacked: hard disk, CPU fan, power supply fan, CD
Also, malware makes old Windows systems hopeless.