Re: [Tuxpaint-devel] Changes for OLPC XO (was Re: Tux Paint 0.9.18 coming this week)
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
From: Albert C. <aca...@gm...> - 2007-11-22 03:51:08
|
On Nov 21, 2007 1:32 PM, Bill Kendrick <nb...@so...> 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, > etc.)) 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. |