Re: [Tuxpaint-dev] the *.txt files
On Tue, 2005-01-25 at 19:02 +0100, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: First of all, in the CVS, could we keep translations out of the *.txt files? They can be added at build time. No, that would an enormous dependency (Python) on all platforms + making the build much slower. Well, how about just using gettext() then? That's the way the whole rest of Tux Paint operates. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] the *.dat files
On Tue, 2005-01-25 at 19:08 +0100, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: How about merging these into the *.txt files? I think it would only make things (extracting, merging and manually editing the files) more complicated and error-prone. Disk reads and space is cheap, especially now with the new threaded stamp-loading code. The funny thing about disk reads is that bulk reads are cheap, while tiny reads are costly. The disk might go at 100 MB/s, but every seek will cost you 5 ms. BTW, how does Tux Paint from CVS work for you? Font scanning is now done in a separate process. For filling in the tool option buttons and for the selected item, both fonts and stamps are loaded on demand by the main thread. If you really want to reduce disk reads, creating some sort of internal stamp description cache file, and only checking last modification times when loading stamps may be a better solution (but still unnecessary, IMHO). I've thought of doing that. It has another huge gain: stamp scaling need not be done if thumbnails are cached. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] thread problem found; possible fix
The libSDL_ttf code shares one FreeType instance for all fonts that are loaded. This means that simultaneous operations on multiple fonts will cause data corruption. I notice that the code is only 1748 lines long. Perhaps I should just toss it into src/tuxpaint.c and fix up the thread safety bugs? I can just delete the threaded font code. Assuming libSDL_ttf gets fixed, Tux Paint could check the version info. Then, if the library is not thread-safe, Tux Paint can just scan for all fonts in the main thread. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tux Paint Segfault if unable to print
On Sun, 2005-01-23 at 03:21, Bill Kendrick wrote: On Sat, Jan 22, 2005 at 09:14:39PM -0500, Albert Cahalan wrote: So, I take it that the various other crashing problems are gone now? How are things with stamps and fonts? Sadly, no. Last I tried, I let it sit for a min. or so w/o hitting the 'Text' tool. Then, when I hit it, I got a short font-related mesg. on stdout and Tux Paint crashed immediately. Got 0 bytes with families. ... where ### was a large number (in the 10s of thousands range?) The number is bogus, because it was never received. (you got 0 bytes) After getting 0 bytes, crashing is totally expected. This should never happen; Tux Paint would already have exited if default_font were not available. You should have also seen this: printf(Sending %u bytes with %u families.\n, size, num_font_families); Did you? (it's really important to be sure about this) If you saw that, there is an IO problem. If you didn't see that, the child crashed. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tux Paint Segfault if unable to print
On Sat, 2005-01-22 at 19:20, Bill Kendrick wrote: Using the latest CVS with the new PostScript support, Tux Paint seems to be segfaulting if it can't print. I get this in the terminal where Tux Paint was run: lpr: error - no default destination available. and then the window just vanishes! I'll look into it tonight, if noone else gets the chance... (It may have been doing this before, but I only just had an issue where CUPS config got corrupted, so 'lpr' now bails with an error.) While writing the code, it appeared to me that the old code (and new code -- nothing changed) would hang if printing didn't go fast and well. I had been thinking that Tux Paint ought to do printing in a separate thread. Of course, given recent ugly experience with SDL threads, I think differently now. So, I take it that the various other crashing problems are gone now? How are things with stamps and fonts? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] noflip and nomirror
I have to wonder about the wisdom of having these. When used, they make buttons stop working. That right there is bad if it can be avoided. (Bill, you said it yourself about greyed-out items) What's the harm in letting a kid flip a house? Maybe the kid is drawing something that involves a tornado. I think nomirror should only affect --mirrorstamps, and noflip should just go away. It's not as if you can prevent a bright kid from using flip magic to bypass the restriction anyway. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.398, 1.399
On Fri, 2005-01-21 at 02:19, Bill Kendrick wrote: On Thu, Jan 20, 2005 at 11:41:13PM +, Albert Cahalan wrote: Update of /cvsroot/tuxpaint/tuxpaint/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3780/src Modified Files: tuxpaint.c Log Message: vague memory of an obscure annoyance w/ sockets leads to this guess at a solution to Tux Paint crashing for Bill Hrm, I hit the Text tool and this time it doens't crash... it just never STOPS! :^( (The little spinning bar at the bottom just keeps animating for much longer than it had ever taken in the past to load all of my fonts.) Also, it looks like Tux Paint no longer looks in ~/.tuxpaint/stamps/ for user-loaded stamps! :^( (It should also look in ~/.tuxpaint/fonts/ for fonts, ~/.tuxpaint/brushes/ for brushes, and ~/.tuxpaint/starts/ for starter images.) You can't be using the same Tux Paint as I am. Maybe CVS merged something incorrectly? Try deleting the source code and having CVS re-fetch it for you. From where I sit, Tux Paint: a. starts up in about 1.1 seconds b. loads a huge ~/.tuxpaint/stamps collection c. loads a huge (my standard) ~/.tuxpaint/fonts collection d. probably looks for user brushes, but I don't have any e. is ready for the text tool in about 10 seconds f. never crashes I did make one recent change that could slow down loading of the text tool. To make the rest of the app start even faster, I called nice() and sched_yield(). If you run some sort of cycle-eater task like SETI or distributed.net, it might now get priority. (in which case, you kind of asked for the behavior your're getting) ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] another 1 or 2 evil fonts
I tried Zapfino, with max-sized normal text (procps ProcPs). It of course went way off the screen, even in height. Then I tried the AteUpWithDumbAss font. It appeared blank, as if I had only spaces. Then I noticed that every font was this way. Well, I already knew Zapfino was evil, so maybe that's just the problem. I guess Zapfino truly needs to be blacklisted, at least with the libSDL_ttf version I'm using. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] the *.txt files
First of all, in the CVS, could we keep translations out of the *.txt files? They can be added at build time. There's no need to keep checking in redundant data, bloating up the CVS records with noise. Second of all, important comments are disappearing. I don't know if this is intentional, but it sucks. For example, stamps/auto/7spoke256.txt contained info that would be useful if someone were to want to make a bigger or slightly modified wheel. Now this information is gone. Image credits are getting wiped out too. See stamps/auto/indycar.txt for that. With a DOD media ID, credit is given and one can identify much about an image: date, service branch, a partial identity for the photographer, and a sequence number. Web searches can find the media ID, and a FOI act request could be used to make the government cough up a copy if needed. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] the *.dat files
How about merging these into the *.txt files? My primary reason is to reduce disk seeks. Because filesystems typically store data in 4 kB blocks, this will save space too. For the Windows users, a *.txt file can be edited. A *.dat file would not be associated with a text editor. Web servers often assign MIME type by filename. The *.dat files are likely to be unviewable, and at least Firefox is cruel about not letting one view a file as text if the MIME type is wrong. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.398, 1.399
On Fri, 2005-01-21 at 02:19, Bill Kendrick wrote: On Thu, Jan 20, 2005 at 11:41:13PM +, Albert Cahalan wrote: Update of /cvsroot/tuxpaint/tuxpaint/src In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3780/src Modified Files: tuxpaint.c Log Message: vague memory of an obscure annoyance w/ sockets leads to this guess at a solution to Tux Paint crashing for Bill Hrm, I hit the Text tool and this time it doens't crash... it just never STOPS! :^( (The little spinning bar at the bottom just keeps animating for much longer than it had ever taken in the past to load all of my fonts.) The above guess was very wrong, causing your new problem. Maybe the old problem is gone anyway... give it a try. For future hangs, see the strace -p option. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] it's fast now
Tux Paint now starts up in just over 1 second, 640x480, with everything enabled. Memory usage has dropped dramatically. Stamp scrolling will be a bit rough the first time through; that is fixable with a prefetch process in case it matters. There are two empty functions, flip_surface() and mirror_surface(), that need code. Very little is now kept in memory. Each stamp get a 5-word struct. Once scrolled to, sound and text may get attached to this struct. It would be good to free the sound data when not needed, but I'd have to see what SDL thinks of that. (the sound might be playing) Here is some data from the top program: PID USERVIRT RES SHR S %CPU %MEMTIME+ COMMAND 8696 root157m 137m 25m S 0.0 27.3 315:57.14 XFree86 8812 albert 128m 93m 45m S 0.0 18.6 60:29.86 firefox-bin 8838 albert 128m 93m 45m S 0.0 18.6 0:00.15 firefox-bin 8839 albert 128m 93m 45m S 0.0 18.6 0:04.73 firefox-bin 8841 albert 128m 93m 45m S 0.0 18.6 0:37.76 firefox-bin 7382 albert 128m 93m 45m S 0.0 18.6 0:00.02 firefox-bin 9536 albert 85500 73m 9264 S 0.0 14.7 0:17.64 tuxpaint.old 9537 albert 85500 73m 9264 S 0.0 14.7 0:00.00 tuxpaint.old 9538 albert 85500 73m 9264 S 0.0 14.7 0:00.00 tuxpaint.old 9539 albert 85500 73m 9264 S 0.0 14.7 0:00.00 tuxpaint.old 9540 albert 32292 21m 9268 S 0.0 4.4 0:00.69 tuxpaint 9542 albert 32292 21m 9268 S 0.0 4.4 0:00.00 tuxpaint 9543 albert 32292 21m 9268 S 0.0 4.4 0:00.00 tuxpaint 9544 albert 32292 21m 9268 S 0.0 4.4 0:00.03 tuxpaint So, what is the remaining 21 MB going to? Merging the *.dat file into the *.txt file (or PNG text) would speed things up. Disk seeks are deadly. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] font loading, threads, processes, etc.
On Wed, 2005-01-19 at 03:25, Bill Kendrick wrote:
On Tue, Jan 18, 2005 at 11:51:34PM -0500, Albert Cahalan wrote:
These new-fangled thread thingies don't work so well.
Heh. D'oh!
I think I have the code rock-solid now, or nearly so. :-)
It ought to work on MacOS X too. As for windows...
Nearly so... It starts loading the fonts when I hit the 'Text' tool,
Sort of. It transfers font data from a child process to
the main Tux Paint app, and then the child process exits.
The data goes over a socket.
but eventually segfaults. I'm having difficulty getting the recent builds
to load all of my fonts. It WAS working, and since then, I didn't install
or remove any fonts, so I think there might be a bad 'free()' that cropped
up again. ;)
I can gdb if you want... just give me the compile options incantation!
Add -ggdb to the gcc command line. You might get somewhat more
readable results if you reduce optimization, using -O1 for example.
Then run like this:
gdb ./tuxpaint
set args --640x480 --nostamps --nosound
run
bt
To print a variable named fi of type familyinfo you do:
print {familyinfo}fi
When it crashes, you should get a line number. Start again, this
time adding break 12345 or somesuch before running Tux Paint.
(replace 12345 with a line number that's before the crash)
You can have more than one breakpoint active, using the continue
command to advance from one to the next. Use next to run the
next instruction, perhaps following into a procedure. Use step
to to likewise but not going down into procedure bodies.
___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] anybody try it?
On Tue, 2005-01-18 at 04:18, Bill Kendrick wrote: On Tue, Jan 18, 2005 at 01:04:13AM -0800, Bill Kendrick wrote: 5.329(without) Oh, well, now I can see why. If I actually go in and CLICK the 'Text' tool, I see that I've only got 5 fonts available, not the tons I had before. :^) What's up? That's... odd. I get them all. If I choose the text tool very quickly, I get the progress bar and have to wait. If I do something else for 20 seconds, then I can use the text tool without waiting. Try adding -lpthread to the gcc args. For me, this seems to make Tux Paint more stable. I don't know why, but perhaps it is required to make glibc thread-safe. You might also try defining _THREAD_SAFE or _REENTRANT. I examined the libSDL_ttf source. It looks as if it's mostly thread-safe, with 1 or 2 exceptions: TTF_Init, which Tux Paint called before starting the font loader thread, is unsafe. (OK) Depending on the way libSDL is compiled, the error handling may corrupt some SDL error messages -- but this should not lead to a crash. (it might, except that libSDL_ttf expands all % sequences itself via snprintf before passing them to libSDL) ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] font loading, threads, processes, etc.
These new-fangled thread thingies don't work so well. I think I have the code rock-solid now, or nearly so. :-) It ought to work on MacOS X too. As for windows... The fix involved: fork() socketpair() fcntl() waitpid() read() write() close() Ah... so soothing. :-) I'll rip out the threaded version unless some Windows user is able to save it soon. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] threaded startup
On Fri, 2005-01-14 at 18:53, Bill Kendrick wrote: On Fri, Jan 14, 2005 at 06:29:42PM -0500, Albert Cahalan wrote: While you try to support this, the schools are busy upgrading. Heh, it's already been 2.5 years since I started Tux Paint, and many still have not. It's a pretty dire situation in some places. It cuts down on theft. Nobody wants to be stuck with a dead OS. If a school is extremely poor, they can always put Debian on their old Macs. Not always. Depends on the Mac. And no reason to make all of their computers incompatible with the software they had already purchased. For this, there is the Mac-on-Linux project. Another idea is to allow running all the code to completion, just as is done now. In that case, pthreads can be used. I guess I need to brush up on threading. :^) The font stuff is pretty simple. Stamps will be worse, but not too complicated I expect. For fonts, I simply don't touch any shared data except a volatile long. That may need some work on Alpha boxes, which have very loose memory ordering rules. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] anybody try it?
Do the threads work OK on x86, Windows, MacOS X...? For maximum effect, compare threaded and non-threaded, and use the --nostamps option. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] CHANGES.txt
On Sun, 2005-01-16 at 03:43, Bill Kendrick wrote: Please remember to update CHANGES.txt if you commit any changes to CVS! :^) Oh, but it looks so neat and pretty now, all tidied up for a release! I feel guilty spoiling CHANGES.txt with technical ramblings. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] why isn't Tux excited anymore?
Tux used to get all excited about the stamps. He'd say A great big airplane! when you picked the great big airplane. Now he just says An airplane. when you pick it. I guess he just doesn't care about stamps anymore? He needs a vacation? It's too bad Bert is trademarked for Sesame Street. (for TODO list: bowl of plain oatmeal) BTW, it's easy to change '!' to '.' in code. Going the other way is not so easy, because normally you'd want at most one '!' in a particular spot. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] threaded startup
On Fri, 2005-01-14 at 12:12, Karl Ove Hufthammer wrote: On Fri, 2005-01-14 at 10:08, Karl Ove Hufthammer wrote: And it will only get worse. (I've spotted many nice images from openclipart.org I'd like to include as stamps.) Those are all cartoonish. Yes, that's why I want to use them. They're really *perfect* for a childrens drawing program. (This is not Gimp, you know.) Cartoons go well with bright green, cyan, and magenta. :-) If you're thinking they'll match what kids can draw, no, they mostly have sharp black outlines and gradients. This may not be the Gimp, but that does not mean low quality. For example, the smudge tool does not have settings for brush, alpha, and smudge factor. It just has good values. It is done with gamma correction and floating-point state though, so that it'll look even better than the Gimp's tool. The glass, for example won't work right on all backgrounds. The glass works fine on coloured backgrounds too. Try black. Look at the shadow. (Unless you removed that; it would be a good idea. Nothing else comes with a shadow.) ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] mouse behavior
On Fri, 2005-01-14 at 16:56, Bill Kendrick wrote: On Fri, Jan 14, 2005 at 04:17:18PM -0500, Albert Cahalan wrote: How about an #ifdef WIN32 on that new feature? Windows: strongly oriented toward left button MacOS: generaly, either button will do Linux: often demands the center button In any case, it'll be harder for a 3-year-old now. I'm totally confused by your suggestion here... Can you explain? You disabled the middle and right buttons, didn't you? That's a total Microsoftism. UNIX workstations traditionally use the middle button. MacOS treats them all the same. Java apps treat them all the same too. For proper UNIXy behavior, you'd only allow the middle button. The left and right would, of course, do something dreadful. :-) Try an real xterm scroll bar. I think the old way was by far best for tiny little kids. If teach them the cold hard reality of their OS is going to be the goal though, an #ifdef WIN32 is appropriate. It's only Windows that has a clear and strong bias toward the left mouse button. Even on Windows though, left-handed users can swap buttons. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] mouse behavior
On Fri, 2005-01-14 at 18:12, Bill Kendrick wrote: On Fri, Jan 14, 2005 at 05:39:40PM -0500, Albert Cahalan wrote: You disabled the middle and right buttons, didn't you? That's a total Microsoftism. UNIX workstations traditionally use the middle button. For what? For pasting, maybe. But not for point-n-click in apps. Admittedly, I've been using only Linux since 1998, but prior to that I used X-Window a lot on SunOS and Solaris, and while I know some weird apps used middle click for certain procedures, it don't remember any paint apps using it for painting! :^/ xpaint, installed right now on my debian-unstable box PDF and Postscript viewers tend to demand the middle button for panning. (not the KDE or GNOME ones) I just fired up TouchGraph GoogleBrowser, a Java applet that runs in a browser, and left click selects and drags things. Right-click presents a pop-up context menu. Seems just like Windows, Gnome, KDE, etc. to me! :^/ It's probably a Swing vs. AWT thing. I'm going to keep it the way it is now. Sorry! :^) (If you REALLY want, you can add a --nomousebuttondistinction switch, or something, to revert it to the old way ;) ) I just want an #ifdef WIN32, not an option. I'll wait until the bug reports come in. Meanwhile, I'm going to give up on the 3-year-old. There's just no way he's going to be able to deal with this. He had enough trouble keeping any mouse button under his fingers, never mind a particular one. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] threaded startup
On Fri, 2005-01-14 at 18:16, Bill Kendrick wrote: On Thu, Jan 13, 2005 at 04:35:00PM -0500, Albert Cahalan wrote: Start-up will go faster if some of the work is put in threads. This is particularly true for disk reads. When the canvas shows, only the paint tool needs to be ready. Other stuff (stamps, fonts, magic) can continue to load in the background. I'm concerned that threading this (at least, using /real/ Unix-style threads) may cause incompatibilities with some OSes. Can some look into this before we move much further forward? Or were we talking about threads at a higher level, and not actually using OS-level stuff? (Main concern for me: getting Tux Paint to work on Mac OS Classic... far too many schools are still stuck with it, and currently cannot take advantage of Tux Paint!) SDL comes with a thread package that works everywhere except on MacOS Classic. I've stumbled across various things involving problems with SDL on MacOS Classic; I don't think is does too well. While you try to support this, the schools are busy upgrading. Nobody wants to be stuck with a dead OS. If a school is extremely poor, they can always put Debian on their old Macs. It may be reasonable to just #if out all the code. Any Mac unable to run MacOS X is unlikely to have very much RAM. Skipping text and stamps will allow running on even more Macs. Another idea is to allow running all the code to completion, just as is done now. In that case, pthreads can be used. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Scrollwheel down causes 4 extra buttons in Selector
When using Tuxpaint with a mouse wheel, you can scroll the right side items - as it should. However, if you are scrolling with the scroll wheel, you get four extra boxes (empty) at the bottom end of the scroll. When using arrows or the mouse button, this does not happen. When scrolling to the top instead of the bottom, this does not happen. I fixed this already. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Scrollwheel down causes 4 extra buttons in Selector
On Fri, 2005-01-14 at 18:57, Bill Kendrick wrote: On Fri, Jan 14, 2005 at 06:35:11PM -0500, Albert Cahalan wrote: I fixed this already. Thanks. He didn't say which version he was using. I didn't remember hearing about it (or a fix), so I assumed it wasn't known. He neglected to mention that he's running in 800x600 mode. 600 - 480 = 120 extra pixels vertically 120/48 = 2 extra rows of buttons, plus waste 2 columns * 2 rows = 4 buttons This arose because the code that calculates layout and offsets is duplicated for click, move, and scrollbutton. I redid the code for click, and then made the scrollbutton code match. The code for move (to change cursor shape) is still broken. This was part of general changes for screen size variation. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src colors.h, 1.8, 1.9
On Thu, 2005-01-13 at 04:12, Karl Ove Hufthammer wrote: On Thu, Januar 13, 2005 4:10 am, Albert Cahalan sa: 5. a darker red, more like the stop signs I didn't change the red. But we could add an extra, dark red (if we remove the 'Colours' label). Take a look at the bridge drawing in the gallery. It would look better with a darker red. Also consider blood. 3. baby blue in place of sky blue I really think this blue is much more usuable than the old one, especially for drawing cartoon skys. Try the lightening bolt stamp in a baby-blue sky. Now, doesn't that look horribly wrong? How did you come up with that anyway? The old one is the result of careful measurement of many real sky pictures. 4. washed out dark blue I've made it darker. Better? The old one was *too* dark to be usuable. For what? One more thing: The 'beige' is not really beige; it's not even close. Suggestions on what we could call it? Beige is the least offensive name. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src colors.h, 1.8, 1.9
On Thu, 2005-01-13 at 11:37, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in Take a look at the bridge drawing in the gallery. It would look better with a darker red. I'm not sure. And Bill actually *has* used a darker red in parts of the drawing. Also consider blood. I'd rather not. It's normal for kids. Just a month or two ago, my 18-month-old exposed his skull. (2mm by 10mm chunk of flesh removed) Schoolboys bleed profusely from the nose and knees. I really think this blue is much more usuable than the old one, especially for drawing cartoon skys. Try the lightening bolt stamp in a baby-blue sky. Now, doesn't that look horribly wrong? No. And I think it looks fine even with these very different shades of blue: http://www.newbreedsoftware.com/tuxpaint/gallery/billkendrick/20041212203112.png That's very cartoon-like. Real lightning bolts appear white. I made the stamp colorable for cartoon usage, but really, a lightning bolt should be white. Without any prompting from me, my kid makes them white. (no cartoons in this house) Another thing: a rainbow in a baby-blue sky looks garish. And of course using a different set of images you would get a different 'sky blue' colour. Just look at all the different colours of the sky behind the real Golden Gate: If you'd like me to recompute, I can. What do other people on this list think? I've put up two images for comparison: That's a total garish cartoon. Look, we have a Cartoon item in the magic section. Hack that to produce the color you want. There is no Uncartoon magic tool. 4. washed out dark blue I've made it darker. Better? The old one was *too* dark to be usuable. For what? Stamp tinting, for instance. See attached car, tinted with the old blue. attachment: blue.png___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] stamp tinting
On Thu, 2005-01-13 at 11:37, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in 4. washed out dark blue I've made it darker. Better? The old one was *too* dark to be usuable. For what? Stamp tinting, for instance. First, look at the car in my other email. There are two tinters. Perhaps you are using cartoon-like stamps that tint with the crummy tinter. The crummy tinter converts the image to greyscale, then maps white to the tinting color and maps black to black -- with everything else falling in between. There are two ways to fix this. One choice is to eliminate the crummy tinter. This requires that some of the stamps be reworked. The nice tinter, used on the sedan for example, preserves all greyscale values from black to white. The most saturated part of the input image is mapped to the tinting color. Other parts of the input image map to somewhere between the tinting color and gray. The dragonfly stamp is greyscale, and thus would not change at all when subjected to the nice tinter. To work, it would need to have some color added. Another choice is to change the crummy tinter. It would need to map white to white, and black to black. Other values fall along a curve (parabola? hyperbola? circle?) that passes through black, white, and the tinting color. This would work for the tint magic too, assuming the curve is calculated only once on mouse-down. So, what curve should I use? What shade of grey should map to the tinting color? (choices: median, mean, mode, 127, 192, grayscale of tinting color...) Attacking this problem from both sides (changing stamps, and changing the crummy tinter) might be best. Does anyone want to do the stamps? Search for *.dat files containing vector. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src colors.h, 1.8, 1.9
On Thu, 2005-01-13 at 14:10, Bill Kendrick wrote: Albert definitely comes from the kids want to draw blood and guts camp. That's fine, but now that we have guns, tanks and explosions in the stamps, I'm definitely seeing a need to split them up, so that parents can choose which things to install. Maybe because: My father was from a family of 4 boys. I'm from a family of 4 boys. I have 3 boys... and I think another on the way. There are no tanks in the stamps collection. The closest thing is just a Bradley. Granted, they can take out obsolete tanks with the 30mm chain gun or modern ones with a TOW missle, but they can't take big incoming HEAT or discarding-sabot rounds. Against a real modern tank, a Bradley is toast. A Bradley is really for transporting people to battle; it holds a dozen or so. The kid loves to draw bad guys standing in front of the Bradley, with flames and bullets coming out of the gun. You should see him get all excited about it. The race car always seems to catch fire, the fish get poisoned (by the lionfish) or eaten by dogs (need a cat), the sedan crashes and gives off smoke... I resisted the urge to make a WTC-jumper stamp. :-) It would be kind of neat, but maybe a bit tasteless? Though, I know I'd want to be imortalized in a stamp if I had to jump like that. I can't think of a better way to be remembered, actually. I've always planned this... no reason to include planets and currency when all the parent/teacher wants is animals and plants. No reason to include holiday and religious stuff, if all they want is planets and outer space. :^) Holiday stuff can be excluded based on date. Currency and religious stuff can be excluded based on locale. Plantets can be excluded based on canvas color. (if you use the coral reef starter, you don't need planets) Albert's definitely looks a little more gloomy/overcast, but I can see it's usefulness in both sky and water situations. (Also, blue is one of my favorite colors, so I'm a little biased :^) ) ... Stamp tinting, for instance. Yes, we do want to keep track of stamp tinting (and Tint magic tool tinting, though honestly that code's got to change), when picking colors. This is backwards. If tinting sucks, let's fix it. If the cartoon effect won't turn normal blue into cartoon blue, let's fix it. How about I do the tinter, and Karl does the cartoon effect? I proposed a fix for the tinter. Thoughts? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] threaded startup
Start-up will go faster if some of the work is put in threads. This is particularly true for disk reads. When the canvas shows, only the paint tool needs to be ready. Other stuff (stamps, fonts, magic) can continue to load in the background. Three solutions to handle fast-clicking users: a. show the yellow-and-black stripes when the user clicks on something that isn't ready (this is what the Open tool does now) b. prevent selection, with the icon grey until ready c. prevent selection, with mini-stripes on the icon until ready Threading the disk reads allows the controller to re-order requests to match physical reality on the disk platter. Threading the CPU usage is needed for hyperthreading and multi-core, which will be the norm in a few years. Threading most anything will cause an apparent performance boost, even if not a real one, because the user isn't forced to wait. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Crazy legs' text rendering
On Thu, 2005-01-13 at 13:47, Karl Ove Hufthammer wrote: Lately the text rendering in Tux Paint has reverted to a 'crazy legs' rendering, where the glyphs don't have the same baseline. I've updated several applications and libraries recently, and that may be what's causing this. I remember seeing this bug earlier, on both Linux and Windows. Anybody know where the problem lies? By elimination: Tux Paint -- no, all rendering done via libSDL_ttf libSDL_ttf -- could be FreeType -- could be font server -- no, problem shows on Windows (unless X11 used) fonts -- could be, if you install the same fonts ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
On Wed, 2005-01-12 at 11:40, Karl Ove Hufthammer wrote: Bill Kendrick [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: The Load dialog has lots of dead space. snip There are some other possibilities though: the toolbar could be active, so that the Back button becomes unneeded. I've thought of this in the past, as well. I think we should go this route. I disagree. I think Tux Paint should work like other Linux/Windows programs (only with different-*looking* controls). In those programs, the open dialogue have 'Open' and 'Cancel' buttons. Consistency is a good thing! (Back should be renamed 'Cancel', BTW.) Consider all the web browsers and web sites. The back button takes you back. A single click on a thumbnail will load an image. Clicking on the side navigation menu will leave the thumbnail page. And we *can* get rid of the 'Colours' label, and increasing the space for the colours buckets. The stamps need the space more. Grabbing the label too would be another much-needed slot. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
On Wed, 2005-01-12 at 13:21, Bill Kendrick wrote: On Wed, Jan 12, 2005 at 07:13:38PM +0100, Karl Ove Hufthammer wrote: But in Tux Paint we need the ability delete the images. Therefore double-clicking the images (or clicking 'Open') works better. (And this is the way open dialogues on Linux and Windows work.) Yeah, where to put delete? has been my issue all along. That button makes me nervous. a. mistakes b. destruction of another kid's work c. destruction of own work If anything should be hard to get at, this is it. Control-click or shift-click would do. With all modifier keys, supress comfirmation. (Alt-Ctrl-Shift-click) Perhaps there should be support for undo, at least until the open mode is left. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src magic.h, 1.11, 1.12 shapes.h, 1.3, 1.4
Learning the relations between different geometric figures is useful. I think it can be see best from similarity in the text. Old: A rectangle has four sides and L-shaped corners. New: A rectangle has four sides and four right angles. This is getting advanced. Classifying angles is a part of geometry, in the 9th or 10th year of school. AFAICS, it's part of grade 7 in the US. But surely the kids have heard the term «straight angle» before? (If not, they can learn it from Tux Paint! :) ) That's also 9th or 10th year and... it means 180 degrees! Old: A rhombus has four equal sides. New: A rhombus has four equal sides, and opposite sides are parallel. The first part is enough to define a rhombus. The second part requires geometry. No, the first part defines a quadrangle. The second part is needed. four EQUAL sides That is a rhombus. Well, there's a degenerate shape with lines crossing, but maybe that is a rhombus too. But the rhombus may as well be removed. It's just a rotated square, and Tux Paint supports rotating. No. This was the major error that convinced me to touch that file in the first place. A rhombus with angles of 30 degrees and 60 degrees is not a rotated square. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 3-year-old user
On Wed, 2005-01-12 at 16:47, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in The biggest differences are the use of color to indicate button state and the lack of filesystem access. The colour thing is really just a style issue (I'm sure there are themes for KDE and GNOME which do the same thing). But maybe real 'depressed' buttons will work better? What app did you use to draw the buttons, Bill? I think it's this: http://www.lefinnois.net/aquapl.php3 For example, I really don't like that right-clicking works the same as left-clicking in Tux Paint. Hey, it's that way for ALL of MacOS X, no matter if you're a kid with Tux Paint or an adult with a spreadsheet. This is even without the normal physical mouse limitation. Without? Are there Mac mice with more than one button? You can plug any normal USB mouse into a Mac. Unless you change an obscure config setting, all buttons will be tied together as one. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] --nosysfonts option added
On Wed, 2005-01-12 at 11:50, Karl Ove Hufthammer wrote:
Albert Cahalan [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
Several other fonts return generic box images. I have
Tux Paint discard any font that has 'a' match 'A'.
Probably I should also discard the font if 'a' matches
'z' or if 'A' matches 'Z'.
Hmm, could you add a generic *localisable* 'reject fonts that
don't contain these character' feature?
For example, for Norwegian, we would like to reject all fonts not
containing glyphs for æøå (or ÆØÅ), as these are parts of our
alphabet (and have keys on our keyboards).
OK, done.
There are two localizable strings which reject fonts,
and four localizable strings used to sort crummy fonts
toward the bottom.
English settings:
Reject if jq has matches. (if 'j' and 'q' look the same)
Reject if JQ has matches.
Sort toward end if oO has matches.
Sort toward end if @$~#{}^* has matches.
Sort toward end if O0 has matches.
Sort toward end if 1Il| has matches.
___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src colors.h, 1.8, 1.9
On Wed, 2005-01-12 at 21:55, Bill Kendrick wrote: On Thu, Jan 13, 2005 at 12:11:12AM +, Albert Cahalan wrote: kid says: this is not good; I like two greys; a missing grey; I hate it; I do not like Tux Paint; I want two greys; I need two greys; I doesn't like that; I don't like this Hah... funniest... CVS commit... ever. I agree that two greys is good, too. (OOC, why'd you change all the other colors, not mentioned in the log? Perhaps we should discuss this more before you and Karl start a commit-ware ;^) ) I figure it's best to just reverse-apply the patch. Many of the others were questionable, so yeah, it ought to be discussed. Possibly good changes: 1. lavendar (not violet, which you can't get) instead of magenta (though losing magenta is painful) 2. the recent light green 3. the recent darker brown 4. a purple that is perhaps halfway between current and the bluer one -- but I'd like to pass around a chart of color patches before touching it 5. a darker red, more like the stop signs Not good: 1. washed out yellow 2. non-pumpkin orange 3. baby blue in place of sky blue 4. washed out dark blue 5. missing grey It might be wise to investigate normal color printer gamuts. For a typical printer, the RGB secondaries (cyan,magenta,yellow) should be no problem. The RGB primaries (red,green,blue) may cause trouble, especially red. I wouldn't want red to be any more grey, but making it darker might be OK. See the stop signs. I could also go for a --manycolors option that gives a double row of colors. This would allow for 4 normal greens plus olive, more sky colors (normal, cheery, Arizona, gloomy), ocean color, medium semi-gray blue, both magenta and lavender, a few more greys, and a few more flesh tones. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
On Wed, 2005-01-12 at 17:24, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in The Gimp is more age-appropriate. It has a standard GUI (and an insane one too, but you can ignore that) The Gimp's GUI is indeed terrible (and not 'standard'!). I'm glad I'm not the only one who thinks the GUI is terrible. If you enable the menubar though, it's fairly standard. I think the problems run deeper than the surface. In any case, they have a Bugzilla. You can help them to see the light. They'll most likely brush you off, but with enough distinct bug reporters... well, one can hope. KDE has something that might be more to your liking. It's not as powerful as the Gimp, but it's way easier and has a totally standard Qt-based interface. Probably the Tux Paint documentation should point to both of these, to handle kids that are getting too old for Tux Paint. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] new direct PostScript printing code
On Mon, 2005-01-10 at 02:29, Bill Kendrick wrote: I'm curious, did you mean to kill my #ifdef DEBUG_FONTS stuff!? :^( Nope. Sorry. Was that the only thing? I expect many of those messages to be deleted before the release. The rest should probably be a run-time option, in case anyone has trouble. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Paths for fonts on Win32, Mac OS X BeOS?
On Sat, 2005-01-08 at 17:09, Martin Fuhrer wrote: Most fonts are being ignored, but a few are loading fine (primarly .ttf fonts). Here is a sampling of the errors I get from the other fonts: Bummer. Is there a newer version of FreeType that you could be using? I'm actually not sure which version of FreeType is being used. IIRC, a vanilla installation of Mac OS X does not include FreeType (font rendering is handled by OS X's Quartz and PDF libraries). There are two versions of SDL for Mac OS X - the X11 version (which requires a FreeType installation) and the native Mac version which is bundled as a framework (and does not require a Freetype installation). I'm using the native version, and have always assumed that FreeType is statically linked into the SDL library, though I may be totally wrong. You'd better look around on your disk, because there's no way the libSDL_ttf code could use anything but FreeType. It'd take a rewrite to use anything else. I can now load most Mac fonts, including *.dfont files and, new in the CVS code as of now, even those zero-length files with a resource fork. Note that the Linux and Darwin HFS drivers are compatible; append /rsrc to get the resource. Regarding individual fonts: Symbol: discarded because it has no letters VT102Font: fails for unknown reason (no Unicode map? bitmap?) Webdings: discarded because it has no letters Apple Chancery: what the heck is Chancery? ZapfDingbats.dfont: discarded because it has no letters Zapfino: fancy ligatures and swashes go unused An additional problem is that FreeType's built-in reader can only find 1 style (face) per font family. When I use fondu to extract the fonts, I get them all. Ideas? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Paths for fonts on Win32, Mac OS X BeOS?
On Sat, 2005-01-08 at 02:59, Bill Kendrick wrote:
In setup(), we have the following that Albert C. recently added:
if (!no_system_fonts)
{
#ifdef WIN32
// add Windows font dir here
#else
loadfonts(/usr/share/feh/fonts, 0);
loadfonts(/usr/share/fonts, 0);
loadfonts(/usr/X11R6/lib/X11/fonts, 0);
loadfonts(/usr/share/texmf/fonts, 0);
loadfonts(/usr/share/grace/fonts/type1, 0);
loadfonts(/usr/share/hatman/fonts, 0);
loadfonts(/usr/share/icewm/themes/jim-mac, 0);
loadfonts(/usr/share/vlc/skins2/fonts, 0);
loadfonts(/usr/share/xplanet/fonts, 0);
#endif
}
Can Win32, Mac OS X and BeOS folks let me know what paths would be good
to add for your respective OSes?
I was just digging up MacOS X, since SourceForge has a Mac
in the compile farm.
Problem: many of the fonts are without file extensions
(there may also be a temporary problem with them appearing
to be empty files, but I've seen FreeType patches to make
the fonts loadable by using %s/rsrc with the filename)
___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Paths for fonts on Win32, Mac OS X BeOS?
On Sat, 2005-01-08 at 03:28, Martin Fuhrer wrote: Can Win32, Mac OS X and BeOS folks let me know what paths would be good to add for your respective OSes? The Mac OS X font directory are: /System/Library/Fonts (standard Mac OS X fonts) /Library/Fonts (administrator-installed fonts for all users) $HOME/Library/Fonts (user installed fonts) I have this now: #elif defined(__APPLE__) loadfonts(/System/Library/Fonts, 0); loadfonts(/Library/Fonts, 0); loadfonts(/usr/share/fonts, 0); loadfonts(/usr/X11R6/lib/X11/fonts, 0); As Albert pointed out, some fonts lack extensions, and many others end in .dfont and .otf, so I'm not sure how well handled they would be by the loadfonts() function. I'm using *.otf fonts right now. As for the others, I saw a FreeType patch that would support them via normal filenames. Without that patch, there are problems. FreeType has a special interface for loading via Mac resource forks, but libSDL_ttf doesn't offer a wrapper for it. Well, I suggest you simply try the latest Tux Paint (as of a few minutes ago) with a recent FreeType and tell us how it goes. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Paths for fonts on Win32, Mac OS X BeOS?
On Sat, 2005-01-08 at 14:53, Martin Fuhrer wrote:
On 8-Jan-05, at 2:38 AM, Albert Cahalan wrote:
I have this now:
#elif defined(__APPLE__)
loadfonts(/System/Library/Fonts, 0);
loadfonts(/Library/Fonts, 0);
loadfonts(/usr/share/fonts, 0);
loadfonts(/usr/X11R6/lib/X11/fonts, 0);
I've added the path to the User's fonts directory to CVS, via a Cocoa
API call.
You can't just use getenv(HOME) for that?
Would /Network/Library/Fonts also be good? Mozilla
uses or used this one. (saw it in a prefs.js patch)
Most fonts are being ignored, but a few are loading fine (primarly .ttf
fonts). Here is a sampling of the errors I get from the other fonts:
Bummer. Is there a newer version of FreeType that you
could be using?
If that won't do, TTF_OpenFontIndexRW can take care of
the problem. Append /rsrc to the Mac name to get at
the resource fork if needed. Then, for both types of
troublesome files, parse the structure to find a normal
file file embedded inside.
This'll work with the Linux hfs filesystem driver too.
As well, the following line in tuxpaint.c is producing a compile error:
const char *restrict const suffixes[] = {ttf, otf, pfa, pfb,
dfont, ttc,};
/Users/mfuhrer/Projects/TuxPaint/tuxpaint-cvs/tuxpaint/src/tuxpaint.c:
In function `loadfonts':
/Users/mfuhrer/Projects/TuxPaint/tuxpaint-cvs/tuxpaint/src/tuxpaint.c:
14226: error: invalid use of `restrict'
/Users/mfuhrer/Projects/TuxPaint/tuxpaint-cvs/tuxpaint/src/tuxpaint.c:
14226: error: invalid use of `restrict'
I can get around it by removing restrict.
What compiler are you using? What options did you give it?
Note that src/tuxpaint.c contains the following:
#if !defined(restrict) __STDC_VERSION__ 199901
#if __GNUC__ 2 || __GNUC_MINOR__ = 92
#define restrict __restrict__
#else
#warning No restrict keyword?
#define restrict
#endif
#endif
___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] 3-year-old user
The big problems I saw were: 1. high mouse pressure 2. mouse rotation instead of sideways movement 3. accidental mouse rotation I think the documentation should strongly suggest that a smooth-sliding puck-based digitizer be used. By puck-based I mean it looks like a mouse instead of like a pen; a pen would quickly get destroyed. As a less-expensive alternative, a trackball might work OK. It will of course fill up with kid goo, and the button placement is always awful. Eliminating the scroll buttons might be good. Neither my 3-year-old nor my 5-year-old uses them by choice. (the 5-year-old knows the scroll wheel is broken in the Open dialog) The 3-year-old quickly discovered and liked the scroll wheel. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] libSDL_ttf is bug-infested
Version 2.0.7 came out Oct 30. Debian-unstable still only has version 2.0.6. Among the many terrible bugs that were fixed: 2.0.7 * Fixed memory corruption problems with some italic fonts * Fixed crash when opening a font file that doesn't exist 2.0.6 * Fixed memory corruption problem with small point sizes Yow! Should all italic fonts be blocked? Also, the library provides no access to the character map. The only way to tell if a character is junk is to compare it it pixel-by-pixel against one that surely is junk. Also, the library appears to randomly return NULL when rendering something. This is horribly painful. Currently, the Tux Paint code relys on a font to work if it worked before. All fonts are tested at startup; if they work at that time then they ought to continue working. BTW, I did fix two other problems. Things may work better. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] bug right here
This'll crash Tux Paint:
error = Find_Glyph(font, c, CACHED_METRICS|CACHED_PIXMAP);
if( error ) {
SDL_FreeSurface( textbuf );
return NULL;
}
With some fonts, you'll get a box. With others, not. While all
fonts should provide such a box, the library can surely draw
one if the font doesn't provide it.
___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
On Fri, 2005-01-07 at 13:36, Bill Kendrick wrote: On Fri, Jan 07, 2005 at 09:56:38AM -0500, Albert Cahalan wrote: You mean the segfault, or just the noise about rejecting a few crummy fonts? I still get a segfault, myself, after tons of fonts are rejected due to 'A' and 'a' looking the same. Then the same short report about FreeSans and then the crash. :^/ Well, how about now? Hopefully you can at least start up and do normal stuff. I do have a way to crash Tux Paint using a library bug: 1. choose text tool 2. click on screen 3. type pH 4. set bold, italic, and the largest size 5. try every font you have It took me about 30 to 60 tries before I hit a bad one. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
On Sat, 2005-01-08 at 01:39, Bill Kendrick wrote: On Sat, Jan 08, 2005 at 01:14:50AM -0500, Albert Cahalan wrote: I do have a way to crash Tux Paint using a library bug: 1. choose text tool 2. click on screen 3. type pH 4. set bold, italic, and the largest size 5. try every font you have It took me about 30 to 60 tries before I hit a bad one. Trying now. (I've got a LOT of fonts :^) ) This one will do the job: http://luneelfique.free.fr/elvishring.otf See it as small non-bold non-italic first, and you'll know why it causes trouble. BTW, it looks like Tux Paint is reloading the font and/or re-rendering the text when the selector is scrolled. I'll see if I can stop that, as it just slows things down. No. Be careful! It'll reload whenever it needs a font it hasn't used before. So it'll be slow scrolling down, and then fast scrolling up. It'll stay fast until you touch the text controls. The reload is required AFAIK, since the SDL_ttf library won't allow a size change without reloading. The alternative is insane I think. The number of fonts that would need to be kept open would be: families * 4 * number_of_sizes ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
I found a second font that'll cause the crash, out of 116 families I tried. Here they both are: http://luneelfique.free.fr/elvishring.otf http://www.webpagepublicity.com/free-fonts/v/Varicelle.ttf Same procedure: set bold (maybe not needed) set italic set the largest font size use pH (no quotes) as text Supposedly the very latest library will survive this, but that version hasn't even made it into Debian-unstable yet. BTW, I'm linking with the Electric Fence library. This puts a guard page after every memory allocation. Use -lefence to link it in. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
On Thu, 2005-01-06 at 08:32, Karl Ove Hufthammer wrote: Bill Kendrick [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Tux Paint in CVS (as of Jan 3, 23:30 UTC) is segfaulting on startup, right as (or after) it's loading the fonts: For me too: Bad font, 'a' and 'A' match: d05l.pfb, Dingbats, Regular Bad font, 'a' and 'A' match: s05l.pfb, Standard Symbols L, Regular Bad font, 'a' and 'A' match: d05l.pfb, Dingbats, Regular Bad font, 'a' and 'A' match: s05l.pfb, Standard Symbols L, Regular free(): invalid pointer 0x821ce08! free(): invalid pointer 0x81a2fd8! Segmentation fault Perhaps on x86, SDL_FreeSurface and free are different. I just checked in a change that uses SDL_FreeSurface for two surfaces. Maybe that'll do the job. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] --nosysfonts option added
On Tue, 2005-01-04 at 02:20, Bill Kendrick wrote: I've added a --nosysfonts option to Tux Paint (and corresponding control in Tux Paint Config) which disables any attempts to load fonts from 'outside' Tux Paint. This allows _me_ to keep running the app, until we can figure out what the problem is with the font grouping code in the latest CVS. ;^) Try now, without that option. Tux Paint now tries to render both 'A' and 'a' for each font. It then compares them to see if they are the same or not. I commented out the blacklist for now. The X11 Cursor font won't render. This seems to be a serious undocumented bug in the library. In fact, no error return is even documented. I had to guess that a NULL might be returned. The library should be supplying an image of a box to represent the failure, as it does with other bad fonts, or it should have a documented error code. Several other fonts return generic box images. I have Tux Paint discard any font that has 'a' match 'A'. Probably I should also discard the font if 'a' matches 'z' or if 'A' matches 'Z'. So, what is your bad font? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] event handling
Much to my horror, I discovered that Tux Paint has distinct near-duplicated code for handling various mouse-related options. This leads to lots of trouble. For example, when the variable-size erasers were added, somebody forgot to update the code that changes the mouse cursor. This means that the cursor does not respond to the difference between active buttons (valid erasers) and inactive ones. Another example: I fixed scrolling of tool options when using the purple buttons. The display does not scroll too far anymore. I missed the existance of separate mouse wheel code, so that didn't get fixed. I see a lot of code duplication there. So, what should the fix be? Here's one idea: do all the mouse cursor updates via an SDL_Surface where each pixel is abused for the storage of a mouse cursor index. When drawing buttons or whatever, also draw to this surface. When the mouse moves, simply examine the color of this surface to determine the proper mouse pointer. For the scrolling, have a global function pointer that gets called. Both the scroll wheel and the purple buttons call the same code. The function pointer can change as needed to allow scrolling of other things. Here's another idea: create a real widget set, like a sort of cut-down GTK. Widgets get passed events, and may pass events on to child widgets, etc. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Segfault at startup
On Mon, 2005-01-03 at 18:30, Bill Kendrick wrote: Tux Paint in CVS (as of Jan 3, 23:30 UTC) is segfaulting on startup, I tried to crash Tux Paint using Electric Fence with a variety of environment variable settings. No luck. right as (or after) it's loading the fonts: $ tuxpaint ... ::: 5 FreeSans Medium Oblique BoldOblique Bold Medium duplicates, discarding: FreeSans, Medium b 0, spot 0 occupancy 0x82d4f20 0x844cb50 0x82df000 0x8308e28 Segmentation fault $ What you see there is that Tux Paint found two files in the same directory that both mapped to non-bold, non-italic. It's the default_font.ttf symlink. One of the files must be discarded. Hopefully you never see this for any other font. BTW, if the symlink were elsewhere, it would not be merged with the others. It would be considered a distinct family. It would then get silently discarded based on a scoring system that prefers font families with more styles. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: I think the buttons TuxPaint uses for controlling the size and other properties of stamps (or in this case, text) take too much screen space, letting the user with only a few stamps/fonts visible. Here's another. attachment: tp-large3.jpg___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: I think the buttons TuxPaint uses for controlling the size and other properties of stamps (or in this case, text) take too much screen space, letting the user with only a few stamps/fonts visible. Here's #5. attachment: tp-20col.jpg___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: I think the buttons TuxPaint uses for controlling the size and other properties of stamps (or in this case, text) take too much screen space, letting the user with only a few stamps/fonts visible. Another! One more coming. attachment: tp-32x40.jpg___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] more font/stamp room
On Sat, 2005-01-01 at 10:59, Gabriel Gazzán wrote: I think the buttons TuxPaint uses for controlling the size and other properties of stamps (or in this case, text) take too much screen space, letting the user with only a few stamps/fonts visible. Things line up better with Tux being 48 high. attachment: tp-all48.jpg___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] different layouts
When considering the layout, remember to think about where excess vertical space should go. Currently, the canvas height is the largest multiple of 48 that fits. Any leftover space (up to 47 rows) goes to the Tux area. Some of the proposed layouts work naturally with this. Some will require that buttons grow to fill ugly gaps, and this may cause alignment problems or non-square control buttons. It's nice if the layout still looks good with the tool option area (right button bar) consumed by a dialog. Imagine the Open dialog being a bit wider, extending to the right by 96 additional columns. Well anyway... what do people like? (usable, pretty at all sizes, easy to code...) ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] text tool
On Fri, 2004-12-31 at 03:49, Bill Kendrick wrote: I like! (We need better icons for the italic/bold controls, obviously... :^) ) In the mockup, I used 36-pt Ariel Black for the bold button. Seems happy under Debian Linux (Testing branch) using xserver-xfree86 4.3.0.dfsg.1-8. That's nearly what I tested with. I also poked around on a Red Hat box at Sourceforge, to see where Red Hat likes to store fonts. I have a ton of fonts installed on my system, and Tux Paint picked them up! Most look pretty good. Any that fail horribly? Now... I have a suggestion. Can we allow for even bigger text? Maybe. It detracts from the WYSIWYG interface, unless the buttons grow to fit the example text. BTW, I chose ag because those two letters vary a lot. There are two types of a and two types of g. For 36-pt without --upercase I'd like to use that. With --uppercase, I'd like to use FJ or L7. These letters kern closely together. AV is nice too, but it doesn't have any curves. (BTW, if --uppercase is going to stay, it needs to quiet down before the release) In large sizes, switching to just a would be useful. This would allow going up to around 96-pt without needing to break the WYSIWYG interface. In smaller sizes, another letter would fit. I thought of adding F, but maybe the Brittish would be bothered? (Fag is slang for a cigarette) Perhaps 12-pt should be added. (or 13-pt, but...) I notice you added these: 56, 64, 96, 112, 128, 160. Oddly, you left out 72 and 144. Maybe it doesn't matter these days, with the FreeType engine and modern fonts, but traditionally it's safer to pick simple ratios of 72. Other sizes, at least historically, tend to look bad. Perhaps this is only the case for tiny sizes, when a patent-licenced rendering engine uses the hinting code embedded in the font files. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] new btn_off.png
Here are two proposed btn_off.png replacements. (imagine that the Colors label matches) Copy to /usr/share/tuxpaint/images/ui/btn_off.png and see what you think. Which one more clearly indicates disabled? Note: they go with the latest CVS tuxpaint, which puts the text and icon in grey for disabled tools. attachment: btn_off_outline.pngattachment: btn_off_light.png___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] text tool
The text tool now has controls. I'd like to leave a few printf() lines in until everybody (Red Hat, Mac, SuSE, Windows, BSD...) gets a chance to run the code. Sorting through fonts is quite an error-prone mess, thanks to font foundries that use irregular style naming and sometimes don't supply a full set. I now have 34 user-visible choices. I might cut that down a tiny bit via a list of common clones. For example, Courier is nicer than Courier New and Courier 10 Pitch. Purposely failing to match up italic and non-italic font styles might be of use. In that case, the FreeType italic emulation will always be used. This allows for double-italic, which often looks nice. In general, italic emulation looks good and bold emulation looks gross. BTW, don't let me forget to free the style array. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] fonts
On Wed, 2004-12-29 at 04:44, Bill Kendrick wrote: The default UI font was changed a while back, so it seems we're now using one that includes some of these glyphs. I was thinking that the fonts have been growing. Because the fonts certainly could grow, I think it best to continue on in the locale when loading the locale font fails, instead of reverting to English or exiting. Little boxes might be no more unreadable than English. The code would be simpler that way I think, and one can always specify --lang=english if desired. It's annoying that TTF_RenderUTF8_Blended does not return an error for missing characters. Perhaps the output of a test image could be examined, like this: // translate this as a string of characters that you // fear may be unavailable in common fonts char *s = gettext(troublesome); BTW, half-serious even... Given the shear number of things that Hebrew users want mirrored, it might be easier to just mirror all of tuxpaint. a. load and save with mirroring b. mirror the mouse movement c. mirror when updating the display d. mirror all stamps e. mirror the fonts This gets Tux on the right side, facing the desired direction. It gets the toolbars on the correct sides. It gets the load and save icons flipped correctly. It gets the colors flipped. It gets dialog box buttons on the correct side. It gets wordwrap at least as correct as it is now. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] locale stuff
I've tried to neaten up the locale stuff, moving it all to one part of the tuxpaint.c file. There are some things I find strange about the code. First of all, why so many setlocale() calls? It seems like all except the ones right before a call to set_current_language() are useless. Second, why set environment variables? Normally, one sets environment variables before calling exec(). Within a program, data is usually passed around via normal C variables. Third of all, what is with the LANG usage for Polish and Lithuanian? It looks like a bug. Fourth, why doesn't Hungarian set LC_ALL like the others? This too looks like a bug. Current call graph: main setlocale(LC_ALL, ) setup parse_options (system conf file) set_langstr parse_options (user conf file) set_langstr set_langstr\ either do_locale_option / order LANG=foo setlocale(LC_ALL,) setup_language if polish or lithuanian, set_langstr() (WTF???) LANGUAGE=foo LC_ALL=foo setlocale(LC_ALL, ); set_current_language *** setlocale(LC_MESSAGES, NULL) and lots of monkey business *** load_locale_font LANG=C OUTPUT_CHARSET=C setlocale(LC_ALL, C) set_current_language() *** setlocale(LC_MESSAGES, NULL) and lots of monkey business *** ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] fonts
Japanese didn't work until I commented out the line that makes it require a non-standard font. Now it appears to work perfectly. (well, it looks kind of asian you know...) I don't know if this includes the Han (Kanji) characters, or just the Katakana and Hirigana, but it appears to cover enough for Tux Paint. Greek also works fine w/o a funny font. It looks much better in fact, with the text correctly sized. Even Hebrew works without a funny font, except that the stamps are untranslated and the English runs the wrong way. So, if these locales are going to be listed, the font loading code needs to NOT give up on the locale when a locale-specific font can't be found. It might be best to load fonts on demand, as missing characters are needed. It would be nice if gettext() had a hook for this or would only translate when the characters are in the loaded fonts. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] dead space and New dialog
I think that New should have a dialog. It would be like the Load dialog, containing the starters and a blank canvas. This gets the starters out of the Load dialog, reducing confusion. It also makes for easy selection of a background color. (if the starters don't get moved, then instead the New button should be eliminated in favor of an all-white starter) The Load dialog has lots of dead space. The obvious solution is to enlarge the dialog to cover the tools, tool options, and color selector. There are some other possibilities though: the toolbar could be active, so that the Back button becomes unneeded. The buttons could go in the tool option area on the right, or even in the far right side of the Tux area. Better yet, the buttons could be eliminated (one click to load a file) if the highly-dangerous delete feature were moved elsewhere. BTW, the green labels can simply be removed. Especially the Colors one is useless, but I don't think the other two are particularly useful either. Little kids simply click on them instead of reading them, thus receiving no benefit and a loss of screen space. Thoughts? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] How's the grass?
I just made a tool for drawing grass. The grass is tintable. Sometimes the color selector doesn't show though, so you might need to temporarily choose some other tool for changing the colors. It's best to work from back to front, laying grass down on some nice dirt. I like light grey tinted grass for sunny spots, and black tinted grass for the shadows. Use red for grass that needs water. During development, I noticed a _huge_ slowdown when I switched to going pixel by pixel. I needed to do this to support tinting, both user-selected and random. (random tinting is needed to keep the grass from turning into a featureless blob) Something should be done about this. Maybe have separate functions, indexed by SDL_Surface type, for getting and setting the R,G,B,A data? If the functions were simplified, perhaps by eliminating all non-32-bit surfaces, inlining them would be OK. BTW, the bucket mechanism used for the grass can produce a very smooth random layout. Perhaps the sparkle magic could use this. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Current CVS and MS VisualC 6.0 SP4
On Sat, 2004-12-18 at 09:20, John Popplewell wrote: On Sat, Dec 18, 2004 at 02:08:38AM -0500, Albert Cahalan wrote: Doesn't Intel offer a free compiler that you can use? I think it even drops right into Visual Studio, in case you like that environment. I don't think it's free. There is mention of $399. That's if you want suport, or want to do a for-pay project. There's an eveluation and education version that you are allowed to use for stuff like Tux Paint. (last I checked) Intel supports some of the special gcc features too. There's also gcc for Windows. I'm going to have a go at using the VC built libraries, and build Tux Paint with the MinGW/MSYS tools. I've had limited success in the past though, successfully building SDL and a few other libraries but horrible auto* problems or no support at all for the other dependencies I had enough trouble on an AMD64 system once. I think I'll have a look at the Microsoft Visual C++ Toolkit 2003 that they are giving away as well. Ah yes, I forgot that one. You can get the command-line compiler for free, right? It should plug right into your existing Visual Studio. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Current CVS and MS VisualC 6.0 SP4
On Sat, 2004-12-18 at 16:31, John Popplewell wrote: On Sat, Dec 18, 2004 at 11:58:24AM -0500, Albert Cahalan wrote: On Sat, 2004-12-18 at 11:37, John Popplewell wrote: but I can't get it to _link_. From reading around, to build Windows applications, it seems to need some bits from the platform SDK which is 320M or the .NET SDK which I seem to remember swearing never to touch. Actually, I managed to get it to link in release mode by suppressing calls to _ftol which were generating link errors. Sadly, the code didn't work correctly anymore :-( Something to do with the FIST instruction and FPU rounding modes when truncating. A well documented can of worms. Go ahead and set the FPU rounding mode to either toward infinity or toward zero as desired. This will help with float-to-integer conversions, while not causing serious errors for other math. The error would be well under 1 ppm for regular float math. Then, if the compiler can be set to directly use the right instructions, you're all set. Otherwise, you need to make a _ftol() function with some assembly. (either inline, or in a *.asm file) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] color selector
On Sat, 2004-12-18 at 18:32, Karl Ove Hufthammer wrote: Albert Cahalan [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Aside from the *.jpg compression damage, how's this? Well, quite ugly, in my honest opinion. I think the current colour buttons would be fine if the 3D effect just were reduced somewhat. Nope. The colors are getting horribly mangled. Here's the core of the problem: if (nc1 200) nc1 = 200; Removing that would give the less-serious problem of white not having highlights. I'd much rather see fully unmolested colors though. WYSIWYG, hmmm? Any 3D effect on the color itself is a WYSIWYG violation. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] color selector, w/ 3D look
How's this? attachment: col3d.jpg___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Current CVS and MS VisualC 6.0 SP4
Doesn't Intel offer a free compiler that you can use? I think it even drops right into Visual Studio, in case you like that environment. There's also gcc for Windows. Oh, and let's not forget Watcom, which is Free Software now and seeing some development. Probably the Intel compiler is the way to go. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src tuxpaint.c, 1.211, 1.212
On Sun, 2004-12-12 at 23:24, Bill Kendrick wrote:
On Sun, Dec 12, 2004 at 08:53:55PM -0500, Albert Cahalan wrote:
1. The usage of mixed tabs as spaces prevents me from
using a block indent command. (^K-,) Either spaces
or tabs would be fine, but not mixed.
I blame VIM! Damned thing!!! I used to use only emacs, but have
been finding VI varients load a LOT quicker, plus take the least effort
to get syntax highlighting going. Beyond that, though, it's actually quite
a pain in the butt to use.
That explains the use of default emacs style with errors.
Maybe we should throw the code through prettyprint or something?
These are pretty standard:
indent -kr -ncs -i8 (Linux kernel style)
indent -kr -ncs -nut -i4(what many people like to read)
indent -kr -ncs -nut -i2(close to my usual style)
2. The indentation of '}' breaks autoindent. My editor
does not contain a whole figgin LISP interpreter and
a LISP compiler and LISP libraries and a kitchen sink.
BTW, this also causes the human to make many errors.
Can you explain this one? Do you mean the Emacs style of this:
if (blah)
..{
stuff();
..}
If so, then yeah... it's a pain when PARTS of the code is indented
like that, and others are indented in the more standard way:
if (blah)
{
..stuff();
}
Yes. While I'd much rather have the '{' on the line above,
it's the indented '}' that kills me. Things just don't line
up right, so it's hard to tell if I'm editing correctly.
Also, way down at the end of the to-do-list in my brain is a note to
break tuxpaint.c up into sane pieces. It wasn't a big deal when the code
was only ~2000 lines long, but now that it's reaching 15,000 it's getting
a little insane. (I can still navigate the code with relative ease... it
just takes far longer to compile than it should.)
That crossed my mind too. Then I thought, hey, having it in
one big blob might make it run a tiny bit faster. I can search.
(the compiler can cheat on the ABI for intra-file calls)
You can save 1325 lines by moving the '{' up to the
previous line. :-) That's an over 9% reduction.
A bigger concern for me is the cascaded if...else stuff.
Combined with the odd indentation, I often get very lost.
The performance won't scale, though it's hard to tell how
much of a problem this is.
I'd use structs containing function pointers. So the active
tool is defined by a pointer to a struct with methods for
handling a mouse click, mouse move, mouse release, selection
of the tool (for initialization), selection of some other tool
(for freeing memory), and so on. Then the tools can be more
self-contained, not having scraps of code all over.
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Crashing when placing tintable stamps
On Sun, 2004-12-12 at 05:07, Bill Kendrick wrote: On Fri, Dec 10, 2004 at 07:33:12AM -0500, Albert Cahalan wrote: It's not crashing here. Type of crash? (SIGKILL, SIGFPE, SIGSEGV, SIGBUS...) Sigsegv. I think my gcc didn't like while (i--) or something? (or maybe there was a double free()... i wasn't debugging it very professionally ;^) ) anyway, seems fixed and works fine now! What compiler do you use? I hope it's 3.3 at least. Random code tweaks are unreliable and unsafe. BTW, some of the stuff you found odd: Declaring variables right before use is less error-prone. If you declare them at the top of the function and then share them, the compiler is less able to correctly warn about uninitialized variables. (the variables might be initialized for one use, but not for later uses) Considering these: work = malloc(sizeof *work * width * height); work = malloc(sizeof(multichan) * width * height); In general, the sizeof *work one is safer. If the data type is ever changed, the sizeof(multichan) one breaks. I didn't check free() because: 1. Linux generally won't return an error anyway; the kernel will send SIGKILL if it can not provide the memory. (this is configurable, to satisfy financial institutions) 2. There is no reasonable way to handle the error. Calling exit() is really just a crash. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] alpha generation program
I added a new mode especially for pure light sources,
such as fire against a black background. I added a
new mode for compositing a test image with your choice
of foreground, background, and alpha. I improved the
handling of tiny values, reducing the crazy colors.
There's a new -T option that sets a cut-off for what
is considered tiny; I used 29 for the palm tree.
Basic usage remains the same: make your best attempt
at editing away the foreground, do the same for the
background (weird, I know), and then feed *.ppm images
into the program. You'll get alpha as a *.pgm image.
Edit that, feed it back into the program, and you'll
get an improved foreground image. Repeat as desired.
For the final *.png file, use pnmtopng:
pnmtopng -force -alpha a.pgm f.ppm stamp.ppm
Anybody using this tool?
/
//
///
#include ctype.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include string.h
#include math.h
#include float.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include sys/mman.h
/
static void usage(const char *s, int code, int err){
if(s){
if(err){
perror(s);
}else{
fprintf(stderr, Error: %s\n, s);
}
}
fprintf(stderr, Usage:\n
./a.out -b background.ppm -o original.ppm -f foreground.ppm
alpha.pgm\n
./a.out -b background.ppm -o original.ppm -a editedalpha.pgm -f
foreground.ppm newforeground.ppm\n
./a.out -b background.ppm -o original.ppm -a editedalpha.pgm
newforeground.ppm\n
./a.out -b background.ppm -f newforeground.ppm -a editedalpha.pgm
likeoriginal.ppm\n
./a.out -b background.ppm -o fire-like-original.ppm foreground.ppm\n
);
exit(code);
}
/
static unsigned width, height;
#define TYPE_PGM '5'
#define TYPE_PPM '6'
//
// quick hack reader for binary P*M files
static unsigned char *readpnm(const char *name, int desired){
int fd = open(name, O_RDONLY);
if(fd3) usage(fd open failure,80,1);
char *cp;
int type;
struct stat sbuf;
fstat(fd, sbuf);
cp = mmap(0, sbuf.st_size, PROT_READ, MAP_SHARED, fd, 0);
if(cp==MAP_FAILED) usage(mmap failure,81,1);
close(fd);
if(cp[0] != 'P') exit(7);
type = cp[1];
if(type != TYPE_PGM type != TYPE_PPM) exit(56);
cp += 2;
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
width = strtoul(cp, cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
height = strtoul(cp, cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
if(strtoul(cp, cp, 10)!=255) exit(33);
cp++;
if(type==desired)
return cp;
if(type==TYPE_PPM desired==TYPE_PGM){
// let'd pick the red channel
unsigned i = width*height;
unsigned char *data = mmap(0, i, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
data[i] = cp[i*3];
}
return data;
}
if(type==TYPE_PGM desired==TYPE_PPM){
unsigned i = width*height;
unsigned char *data = mmap(0, i*3, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
unsigned char tmp = cp[i];
data[i*3+0] = tmp;
data[i*3+1] = tmp;
data[i*3+2] = tmp;
}
return data;
}
exit(93);
}
// This goes from 8-bit sRGB (range 0 to 255) to linear (range 0 to 1).
// The math to produce a table entry:
//tmp = oldvalue / 255.0;
//result = (tmp=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
static const float sRGB_to_linear_table[256] = {
0.00, 0.000304, 0.000607, 0.000911, 0.001214, 0.001518, 0.001821,
0.002125, 0.002428, 0.002732, 0.003035, 0.003347, 0.003677, 0.004025,
0.004391, 0.004777, 0.005182, 0.005605, 0.006049, 0.006512, 0.006995,
0.007499, 0.008023, 0.008568, 0.009134, 0.009721, 0.010330, 0.010960,
0.011612, 0.012286, 0.012983, 0.013702, 0.01, 0.015209, 0.015996,
0.016807, 0.017642, 0.018500, 0.019382, 0.020289, 0.021219, 0.022174,
0.023153, 0.024158, 0.025187, 0.026241, 0.027321, 0.028426, 0.029557,
0.030713, 0.031896, 0.033105, 0.034340, 0.035601, 0.036889, 0.038204,
0.039546, 0.040915, 0.042311, 0.043735, 0.045186, 0.046665, 0.048172,
0.049707, 0.051269, 0.052861, 0.054480, 0.056128, 0.057805, 0.059511,
0.061246, 0.063010, 0.064803, 0.066626, 0.068478, 0.070360, 0.072272,
0.074214, 0.076185, 0.078187, 0.080220, 0.082283, 0.084376, 0.086500,
0.088656, 0.090842, 0.093059, 0.095307, 0.097587, 0.099899, 0.102242,
0.104616, 0.107023, 0.109462, 0.111932, 0.114435, 0.116971, 0.119538,
0.122139, 0.124772, 0.127438, 0.130136,
Re: [Tuxpaint-dev] [fwd] Re: Tux Paint in Gnome? [panel crashing bug]
On Mon, 2004-12-13 at 00:03, Bill Kendrick wrote: I was unable to reproduce the Gnome-panel-crashing bug with Tux Paint 0.9.15 from CVS. Can someone out here with a Gnome setup test this? (Esp. if you're able to crash with 0.9.14 :^) ) I had that happen just today. I assumed that the kernel chose to kill the panel to get more memory. The system was swapping like crazy when it happened. Fortunately, Tux Paint died and GNOME restarted the panel. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] New Magic tools
On Sat, 2004-12-11 at 08:29, Bill Kendrick wrote: I've created three new Magic tools tonight: Darken - Opposite of Fade It seems to me that darken should be the opposite of lighten, and fade should change only saturation. Cartoon - (Still needs work) Makes the image look like a cartoon (vs. real) That's a weird one. I was thinking of doing this as a whole-image operation. It's kind of pointlessly destructive as a concept though. In any case, my idea for an algorithm: 1. do an edge detect (in color) 2. threshold that, to just black and white 3. trace the lines with a black brush (now it looks like the chicken and jet starters) 4. flood-fill each white area with the right color The color for each flood-fill is determined from the original image. It is the average (linear RGB) color, or a gradient determined by a best-fit slope. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] glass of water
I spotted glass of water in the stamps TODO list. Glass is hard to deal with. There's no way I can do this one, but here are two ideas for it: 1. PovRay 2. Careful photography I can produce the stamp if someone can do the photography. You'll need a tripod, a remote shutter trigger button, a device (blocks of wood?) for reproducably positioning the glass of water, some very black and very white material for the background, and the glass of water. Take two photos. The glass goes in the exact same place. (positioning is critical, including rotation) The camera can not be touched, so a timer will not do. You place black material both under and behind the glass, take a photo, and then repeat with the white material. You'll have to stay far away for the photo, so that your shadows and reflections are not anywhere near the glass. Don't bump the light or the table. It's best if you can use a light source that isn't yellow tinted; second best would be a filter on the lens. Be sure that the black material is the same thickness as the white material to avoid changing the glass position. Make the photos large, without JPEG artifacts. While set up, might as well also do: milk, beer, orange juice, Mountain Dew, tomato juice, wine... ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Thu, 2004-12-09 at 23:21, Martin Fuhrer wrote: On 9-Dec-04, at 7:13 PM, Albert Cahalan wrote: On Thu, 2004-12-09 at 20:48, Bill Kendrick wrote: Albert put this into CVS just now: Modified Files: tuxpaint.c Log Message: narrowed down the massive starter bug to load_starter, maybe involving SDL_CreateRGBSurface or SDL_SetAlpha Martin, can you pull the latest from CVS and see if this helps fix the starter bug? That won't, but 1 or 2 commits later should do the job. I'll keep my eye out on this thread and recompile once the commits are in. Keep me posted! I meant commits that were done. So, at the time of that email, the problem of starters being totally broken should be gone. There were two problems. First, a /usr/local path was in the code. This was no good if you installed elsewhere. Second, when working with a large screen, the foreground alpha channel got lost. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Crashing when placing tintable stamps
On Fri, 2004-12-10 at 04:03, Bill Kendrick wrote: I'm using Tux Paint from today's CVS (Dec. 9th), and it seems to be crashing whenever I go to place a tintable stamp (e.g., one of the cars, the butterfly, etc.) I don't have time to debug it just yet. Albert, can you take a looksee? I'm using Debian Testing and X/SDL/etc. that comes with it. My display is 16bpp, if it matters. ;) It's not crashing here. Type of crash? (SIGKILL, SIGFPE, SIGSEGV, SIGBUS...) Going into 16bpp is not easy for me, as it's a kernel setting that requires /etc/yaboot.conf (like lilo.conf or grub.conf) changes and a reboot. I also have: big-endian default unsigned char a sane FPU ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Fri, 2004-12-10 at 13:52, Martin Fuhrer wrote: I meant commits that were done. So, at the time of that email, the problem of starters being totally broken should be gone. Thanks Albert, the problem is fixed under Mac OS X. There is still a bit of a glitch in 800x600 mode, however: http://pages.cpsc.ucalgary.ca/~fuhrer/tuxpaint/tuxpaint800x600.jpg Note that the left and right edges of the picture are smudged. This does not happen in 640x480 mode. That's somewhat intentional. It makes more sense for typical kid drawings. Probably there should be a flag to choose an alternate way of handling things. The 800x600 display has a different-shaped canvas. Rather than filling with white or screwing up the aspect ratio, I smeared the edges. Again, it makes more sense with typical kid drawings. Consider a drawing with green grass, a blue sky, and a house. I first scale the image to be as large as possible without messing up the aspect ratio or being too big. That usually leaves space on the sides, but could leave space at the top and bottom. Then I smear to fill. The sky gets wider, the grass gets wider, and the house grows proportionally. There are fancier ways to do this, involving one or more of: a. wavelets b. vectors (like hq4x scaling, but to extrapolate outward) c. markov modeling Some of these can properly extend a lawn with dandilions! In the reef example, new coral would be generated. If you have trouble believing this, try the resynthesize plug-in for the gimp. If you know the math and can make it run in no more than a few seconds, go right ahead. :-) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Fri, 2004-12-10 at 15:52, Ben Armstrong wrote: On Fri, 2004-12-10 at 14:57 -0500, Albert Cahalan wrote: The 800x600 display has a different-shaped canvas. Rather than filling with white or screwing up the aspect ratio, I smeared the edges. Maybe the simpler solution is to change the layout of 800x600 mode so that the canvas isn't a different shape? I'd agree if monitor shapes weren't changing. I have fixed-resolution 1600x1024. For development, I like to use a 640x768 window. None of the new Macs come with the old 4:3 ratio. The standard canvas shape would look very silly on my screen. There would be lots of dead space, or a very different layout for the buttons. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 'Starters' bug tracked down? (Fwd from tuxpaint-commits)
On Thu, 2004-12-09 at 20:48, Bill Kendrick wrote: Albert put this into CVS just now: Modified Files: tuxpaint.c Log Message: narrowed down the massive starter bug to load_starter, maybe involving SDL_CreateRGBSurface or SDL_SetAlpha Martin, can you pull the latest from CVS and see if this helps fix the starter bug? That won't, but 1 or 2 commits later should do the job. SDL_BlitSurface does not copy alpha. This caused the alpha to get lost when adjusting starters for a different screen size. There is simply nothing in SDL that will do the job. I wrote NondefectiveBlit as a correct, but horribly slow, replacement for SDL_BlitSurface. I really dislike starters through and through. Besides making the code slower and harder to understand, they complicate the user interface. Starters appear as saved files in the dialog for loading an image, but they are not saved images in any way. As they presumably increase in number, they will crowd the image load dialog. The interactions with magic are gross too, with the tools being unable to distinguish the starter from the user's work. Try a flood-fill on the San Francisco skyline, w! Also note the funny effects when drawing around the edge of that palm tree. I think it could be confusing when parts of the image are not drawable. So... how about scraping at least some of this? The foreground part is the worst. I can imagine backgrounds, perhaps even tilable ones, being almost worth the trouble if they appeared in a dialog for new images instead of in the dialog for loading files. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] sound needed
The new smudge tool needs a suitable sound. It also needs an image. (using the blur one now) The tool is lots of fun. It gives the feel of fingerpainting with the image. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] memory usage
On Thu, 2004-12-02 at 20:49, Bill Kendrick wrote: I think it's fine to keep 'everything' in memory, but to continue with my original plan on managing just WHAT 'everything' is. In other words... split up the stamps into collections of 10-20 each, rather than load all 200 up at once. There's still no UI for that AFAIK, and I'm not sure that one will be found without abandoning the target audience. Navigating a tree structure, even a 2-level one, is much more complex than simply using the scroll wheel. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] color selector
On Thu, 2004-12-02 at 20:54, Bill Kendrick wrote: On Thu, Dec 02, 2004 at 07:59:13PM -0500, Albert Cahalan wrote: Aside from the *.jpg compression damage, how's this? That's not too bad. I think I'd prefer the palette colors to still be shaped more similar to the other buttons, though. And it'd be nice if we could have SOME slight 3D or glass effect on the colors. Hrmm.. How about _around_ the colors instead? That could make the colors look sunken in, like watercolor paint wells. Also, related to this last one, a recent article I read on GUI usability mentioned that greyed out items are bad, esp. nowadays when there are so many items in pulldown menus in huge applications like MS Office. Yes, but the alternatives are far worse. :-) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] memory usage
I don't know where it's all going, but --nostamps reduces memory usage by 75%. I'm at about 60 MB. Plan? Things that I think should be kept in memory: a. sounds for all stamps visible in the selector b. image data for the active stamp c. icons for all stamps visible in the selector d. icons for next-to-visible stamps So when you scroll down, Tux Paint should load: a. sounds for the two stamps just made visible b. icons for the two stamps beyond that The load_arbitrary function is lots of trouble. It kind of enforces everything to be kept in memory. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] color selector
Aside from the *.jpg compression damage, how's this? attachment: tp2.jpg___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] stamp production tool
Here's a little tool I just made for creating alpha channels.
It should be useful whenever you have a simple background.
1. save the original as a binary *.ppm file
2. save another copy, with the foreground painted away
3. save another copy, with the background painted away
4. run the tool to create an alpha image
Now you have a rough alpha image. Edit it as needed to
make the opaque parts fully white and the transparent
parts fully black. To avoid background color fringes on
the finished stamp, use the tool again. Feed it all 4
images you have, and you'll get back a new foreground
image that doesn't have any background mixed with it.
Note: the crazy colors are somewhat OK; they come from
the effectively limited bit depth of foreground objects
in semi-transparent areas being expanded to a full 8 bits.
Things should work out OK when the image is used.
A possible enhancement might be to blur the images in
proportion to transparency. This would reduce noise.
BTW, the alpha image is not a true *.pgm file. It's linear.
The *.ppm files all use the sRGB color space.
/
#include ctype.h
#include stdio.h
#include stdlib.h
#include unistd.h
#include string.h
#include math.h
#include float.h
#include sys/types.h
#include sys/stat.h
#include fcntl.h
#include sys/mman.h
static unsigned width, height;
#define TYPE_PGM '5'
#define TYPE_PPM '6'
//
// quick hack reader for binary P*M files
static unsigned char *readpnm(const char *name, int desired){
int fd = open(name, O_RDONLY);
char *cp;
int type;
struct stat sbuf;
fstat(fd, sbuf);
cp = mmap(0, sbuf.st_size, PROT_READ, MAP_SHARED, fd, 0);
close(fd);
if(cp[0] != 'P') exit(7);
type = cp[1];
if(type != TYPE_PGM type != TYPE_PPM) exit(56);
cp += 2;
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
width = strtoul(cp, cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
height = strtoul(cp, cp, 10);
while(*cp=='#' || isspace(*cp)){
if(*cp=='#') cp = strchr(cp, '\n');
else cp++;
}
if(strtoul(cp, cp, 10)!=255) exit(33);
cp++;
if(type==desired)
return cp;
if(type==TYPE_PGM){
// desired must have been 6 (color), but we want 5
// let'd pick the red channel
unsigned i = width*height;
unsigned char *data = mmap(0, i, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
data[i] = cp[i*3];
}
return data;
}
if(type==TYPE_PPM){
// desired must have been 5 (greyscale), but we want 6
unsigned i = width*height;
unsigned char *data = mmap(0, i, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_ANONYMOUS, 0, 0);
while(i--){
unsigned char tmp = cp[i];
data[i*3+0] = tmp;
data[i*3+1] = tmp;
data[i*3+2] = tmp;
}
return data;
}
exit(93);
}
// project 1st vector onto 2nd vector, then divide by 2nd magnitude
static double vdist(double x, double y, double z, double x2, double y2, double
z2){
double dot= x *x2 + y *y2 + z *z2; // the dot product
double magsquared = x2*x2 + y2*y2 + z2*z2; // the magnitude, squared
return dot / magsquared;
}
///
// passed original, foreground, and background images, return an alpha channel
static unsigned char *mkalpha(const unsigned char *o, const unsigned char *f,
const unsigned char *b){
unsigned char *ret = malloc(width*height);
unsigned i = width*height;
while(i--){
unsigned char or = o[i*3+0];
unsigned char og = o[i*3+1];
unsigned char ob = o[i*3+2];
unsigned char fr = f[i*3+0];
unsigned char fg = f[i*3+1];
unsigned char fb = f[i*3+2];
unsigned char br = b[i*3+0];
unsigned char bg = b[i*3+1];
unsigned char bb = b[i*3+2];
if(fr==br fg==bg fb==bb){
// foreground and background are same color... uh oh
ret[i] = 128; // a random value :-(
continue;
}
if(or==br og==bg ob==bb){
// original and background are same color: alpha is 0
ret[i] = 0;
continue;
}
if(fr==or fg==og fb==ob){
// foreground and original are same color: alpha is 1.0 or 255
ret[i] = 255;
continue;
}
double tmp;
// convert from sRGB to linear (gamma==1.0) RGB
tmp = or / 255.0; double oR = (tmp=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = og / 255.0; double oG = (tmp=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = ob / 255.0; double oB = (tmp=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = fr / 255.0; double fR = (tmp=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = fg / 255.0; double fG = (tmp=0.03928) ? tmp/12.92 :
pow((tmp+0.055)/1.055,2.4);
tmp = fb / 255.0; double fB
[Tuxpaint-dev] need to document stamp creation workflow
I can't find good step-by-step documentation for creating the right kind of images. Presumably the gimp is a part of this, for lack of a decent tool. Well, here's a start, gripes included. Some things I've stumbled across while suffering: You need to start with a good image. You want it big, generally a side view, and free to use. Don't worry about minor obstructions like wires; they can be removed with the clone tool and smudge tool. One might as well start with this. The clone tool is useless until you do control-click to start it. This would also be a good time to remove color casts with the curves tool. Use the jpegtran program if you will be making a greyscale stamp from a color JPEG, since it preserves data better than the GIMP. Ideally, one would do rotation last. This does not work well though, because a gimp bug will destory parts of an RGBA image. (learned the painful way) Gimp has three notions of what we might call alpha. 1. the selection, which is a hidden 8-bit channel (not a binary channel). 2. the layer mask 3. the alpha channel No reason is given for why the layer mask and alpha channel both exist. You can have both. You can, very awkwardly, convert one into the other. Many operations will only work on one. You can also convert either of these to or from the selection. Then there's quickmask mode, enabled by a button on the lower left of an image. It lets you paint the selection as a red haze over the image. Woe to you if your image looks like a red haze. Since the selection can be (awkwardly) converted to an alpha channel or layer mask, quickmask mode can be used to rough out the needed alpha channel. The basic problem when dealing with alpha is that you can't see it. The GIMP does not provide a good way to handle this problem. Ideally, one could drag-and-drop arbitrary channels and layers and images all over into each other, and could have many differently composited views all with mouse pointers and simultaneous updates. One can toggle layer visibility to flip between a layer with the image and one with the future alpha channel. With an actual alpha channel, you can't do anything. With the data as a layer mask, you can use an awkward and error-prone feature to choose what you see and what you draw on: use control-click and shift-click on the layer mask and/or layer (two side-by-side icons in the layers dialog) to muck with this. You can thus draw on the image while seeing the alpha channel, or draw on the alpha channel while seeing the image. Most likely you will, unintentionally and repeatedly. Away from your stamp object, you have some dead space on the drawing canvas. Fill this with a solid color to get better compression. Near the edge of your stamp object you will need to do some tedious pixel-by-pixel painting. Most image sources have JPEG artifacts that mess up the border. You'll need to color over these. Use the color picker and pencil, or use the clone tool. Extend the border of the image outward by many pixels to ensure that undesired colors don't leak into the image later as it is scaled, rotated, and so on. Be careful to ensure that the solid colors of your alpha channel (layer mask, whatever) and background are really solid colors. To do this, first select the region by color. Then, invert the selection. Now zoom in at least 4x and look for the moving selection ants. Color over them with the pencil tool set to full opacity. Redo the selection to check if you are done. When saving the image, be sure that you do not have a floating layer. (a cut-and-paste result for example) A gimp bug will mess up the output file if you forget. Avoid rotation entirely if you can. The GIMP operates without concern for gamma. Images can become noticably darker near light-dark transitions, including any areas with high noise. Thin features like antennas need special treatment. Paint over them with a broad brush, using what you imagine to be the oringinal color. (the original color is almost entirely lost to JPEG compression) The original image can sometimes be used as the alpha channel; use of the curves tool on a selection will be required to get the right contrast. For thin features that are nearly horizontal or vertical, complete replacement is required to avoid aliasing. (It's best to locate vertical antennas at locations p*n+x where p is a power of two, n is a per-antenna value, and x is a value shared by all antennas. This ensures that the antennas are all equally blurry or sharp when the image is scaled to common sizes.) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] UK govt copyright?
Do UK government works fall into the public domain or what? Copyright to the queen or something? In other words, are they free to use? (any other non-US info?) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] code simplification
Now that Tux Paint is in 24-bit mode, I wonder what happens if you have a 16-bit display and you remove these lines from getpixel() and putpixel(). else if (bpp == 2) *(Uint16 *)p = pixel; else if (bpp == 2)/* 16-bit display */ pixel = *(Uint16 *)p; I also wonder what happens if SDL_MapRGB becomes a macro that ignores bit depth. Does it work OK? BTW, it would be nice if getpixel() would simply grab the nearest pixel when the dimensions are out of bounds. This would be great for a smudge tool. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] reentrancy, thread-safety, etc.
On Fri, 2004-11-26 at 17:31, Bill Kendrick wrote: On Fri, Nov 26, 2004 at 11:24:37AM -0500, Albert Cahalan wrote: I'd like to have the stamp controls set up a bitmap for the stamp outline renderer. I need to know if I must use an SDL surface with locking, or if I can use something simpler and faster. If what you do interrupts the event loop (as most things do, like saving, loading, etc.), then if I understand things right (which I admittedly may not ;^) ), you can probably do it your 'faster' way. Though I'm curious, what would that be? Also, you don't happen to be considering alpha-blended stamps under the mouse before placement...? :) I didn't think of that. It has a bit of a downside though. The outline might be easier to see. I did think of filling in the outline though. I was just preparing to cache the stamp outline. When the stamp changes (new choice, flip, mirror, or scaling), the outline needs to be recomputed. There's no need to be computing it every time the mouse moves a tiny bit. The code in CVS is prepared for this now. Notice that update_stamp_xor has been split out of stamp_xor. Now there are two reasonable options: a. check for stamp changes in update_stamp_xor, and return early (without computation) if no changes b. move the update_stamp_xor call from stamp_xor to the code (flip button, etc.) that causes the stamp outline to need replacement If this works out well, maybe the low-quality stamp outline code will be pointless to keep. BTW, there's a bit of a problem with flicker. I suppose the solution might involve a canvas-sized bitmap for the outline. Then there would never be a need to clear the old outline prior to painting the new one; the clearing and painting would take place in one operation. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] reentrancy, thread-safety, etc.
On Fri, 2004-11-26 at 18:52, Bill Kendrick wrote: On Fri, Nov 26, 2004 at 06:30:21PM -0500, Albert Cahalan wrote: I was just preparing to cache the stamp outline. When the stamp changes (new choice, flip, mirror, or scaling), the outline needs to be recomputed. There's no need to be computing it every time the mouse moves a tiny bit. Yes, I've noticed that. :^) On my 450MHz Celeron, the recomputation takes up QUITE a bit of time. So much so that if I move the mouse quickly enough, the event handler seems to loose the last few positions. We may be having a contest for slowest computer. I have a 450 MHz Mac with PC100 memory. Unlike your computer, mine is pushing 32-bit video to a 1600x1024 display, uphill both ways. :-) I have nothing fancier than a bit of basic 2-D acceleration. This causes the outline to stay where it was, while the + mouse pointer has moved a few inches away. If I click to place the stamp, of course (part of) the old outline remains. :^( This is a serious bug. Stamp outline performance improvements will not fix the root cause of this bug; they'll just make the bug harder to reproduce. The code in CVS is prepared for this now. Notice that update_stamp_xor has been split out of stamp_xor. Now there are two reasonable options: I tried simply moving the 'update_stamp_xor()' call to whenever the stamp shape changes (mousewheel rolls or user specifically clicks a stamp button on the right). Mousewheel? That doesn't change the stamp AFAIK. Changes would be: 1. startup (very important!) 2. click on new stamp 3. mirror 4. flip 5. scale up 6. scale down Tinting changes the stamp too, but it won't matter for this. If this works out well, maybe the low-quality stamp outline code will be pointless to keep. I notice that's gone all of a sudden. ;^) What, I didn't do it, and nobody saw me. ? BTW, there's a bit of a problem with flicker. I suppose the solution might involve a canvas-sized bitmap for the outline. Then there would never be a need to clear the old outline prior to painting the new one; the clearing and painting would take place in one operation. What's flickering, exactly? flickering == flashing, going on and off, producing an annoying sensation of variable brightness... You don't see it? As a stamp is moved before placement, the outline refresh is visible. I see the outline go and then come back in the new location. This is not good. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
This may have something to do with the performance: gcc-3.4 (GCC) 3.4.2 (Debian 3.4.2-3) This compiler does alias analysis and whole-file optimization. If that does the job for you, then don't worry. Most users will be getting binaries compiled with gcc 3.4 or later. For the Windows build, ensure that the fast math options are enabled. (using the x86 transcedental math instructions) If alias analysis is an option, enable that too. There are plenty of opportunities for hand-optimizing the code if compiler adjustments don't do the job. I didn't bother, because a bone-headed implementation was easier to develop and plenty fast on my system. Some ideas are: a. reduce the size of the multichan struct b. re-use original sRGB data for unmodified pixels c. use a look-up table for sRGB to L,u,v d. [painful and inaccurate] interpolate for L,u,v to sRGB It would be great if you could run a line-by-line profiler on the code to see where the time is going. Try using oprofile and kcachegrind to find where cache misses happen. (this is where the --playback option would be great) Windows profiler output might be helpful too. Surely there are some suitable tools... maybe Intel provides some? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tinting in CVS
On Fri, 2004-11-26 at 21:23, Mark K. Kim wrote: On Fri, 26 Nov 2004, Albert Cahalan wrote: One thing that may need to change for a PC is the place where a double is compared against zero. Instead of this: if(dst.sat0) You might be better off with: if(dst.sat0.0001) How does that offer performance increase??? Generally, it doesn't. It's a matter of accuracy in being able to determine if the destination color is greyscale. This is just a possible bug that popped into my head while thinking about the code, nothing more. (a Mac handles this well, but a PC has a variable number of fraction bits because of the truncation that occurs when an 80-bit float is spilled to a 64-bit stack location) There could be a place where something like the above would send the code around for a loop though. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] new tinter
On Thu, 2004-11-25 at 00:49, Albert Cahalan wrote: To show off the new tinter, the enclosed patch restores the original purple. Yellow is much, much, nicer with this new tinter. So... anybody try it? Any objections? Good? Bad? ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] high-resolution stamps work now
On Thu, 2004-11-25 at 14:59, Karl Ove Hufthammer wrote: The outlines shown when placing a stamp doesn't work as well as before (both for unscaled and scaled stamps). I've noticed. Rather than fixing it, I think the outline code should be redone. As noted by a #define option, the current code is slow. It also screws up on rectangles with certain (odd? even?) sizes, leaving off one edge. So the new problem is just one more reason to redo this code. And one of the higher scale factors doesn't give very smooth edges. You can see it on both the new tyre stamp and the updated grapes stamp. The tyre looks round and smooth with one scale factor, not with the next, but *with* the one after that one. I of course know that doubling and quadrupling the size will get better result than arbitrary scaling, but my image program does seem to be able to handle the intermediate steps well, while Tux Paint does not. Something wrong with SDL's rescaling algorithm? SDL isn't used for this. The thumbnail generator was modified to do general stamp resizing. The algorithm is really, really, simple. It simply grabs a square of pixels from the source, averages them, and then fills in a square of pixels for the destination. If linking against libfftw2 is OK, really nice arbitrary scaling would be easy. (take FFT, truncate or zero-pad, inverse FFT) Otherwise, maybe something like lanczos3. My notes on this: --- accurate and slow: FFT/Chirp-z http://www.worldserver.com/turk/computergraphics/ResamplingFilters.pdf google for: fft image interpolation http://www.mplayerhq.hu/DOCS/tech/swscaler_methods.txt http://www.path.unimelb.edu.au/~dersch/interpolator/interpolator.html lanczos3 --- ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] new tinter
On Thu, 2004-11-25 at 14:50, Karl Ove Hufthammer wrote:
Albert Cahalan [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
On Thu, 2004-11-25 at 00:49, Albert Cahalan wrote:
To show off the new tinter, the enclosed patch restores
the original purple. Yellow is much, much, nicer with this
new tinter.
So... anybody try it? Any objections? Good? Bad?
I got an error message while trying to apply it for tuxpaint.c.
Could you try resending it, now as a an attachment (line-breaking
in e-mail programs easily mangles patches) and diffed against
latest CVS version?
Don't cut-and-paste. Save the email, then run the whole
thing through patch. If you still get an error, check to
be sure that some lame helpful mail gateway hasn't
decided to prevent damage by using printed-quotable
MIME encoding. Never use such evil mail gateways.
Remember:
cd root-of-tuxpaint-source
patch -s -E -p1 path-to-this-email
Use the --dry-run option if you want to check first.
But I have one comment. As far as I can see, you have completely
removed the notintgray feature. We do really *not* want to try to
be clever and (by default) only render parts of a stamp which has
the same hue. This has lead to problems in the past.
(But if a stamp require not tinting 'grey' parts, the 'notintgray'
option should still be available.)
If there are problems, I'll deal with them.
I don't special-case grey. Tinting grey is a no-op.
I can change the hue, but that means nothing. Here's
what happens to it:
double u = sat * sin(mc-hue);
double v = sat * cos(mc-hue);
double L = mc-L;
As you may guess, sat is the saturation, which will be 0.0
for grey. So the hue doesn't matter. Both u and v become 0.0.
I'll try again with a patch in the body. This needs to work.
Attachments are hard to quote in email responses. Speaking
of which, this mailing list makes my reply and group reply
buttons to the same thing, limiting my communication choices.
-- the patch -
diff -Naurd t2/src/colors.h tx/src/colors.h
--- t2/src/colors.h 2004-11-22 20:28:45.0 -0500
+++ tx/src/colors.h 2004-11-25 00:18:52.0 -0500
@@ -52,7 +52,7 @@
{ 33, 148, 33}, /* Green */
{138, 168, 205}, /* Sky blue */
{ 0, 0, 255}, /* Blue */
- { 96, 0, 128}, /* Purple */
+ {128, 0, 128}, /* Purple */
{255, 0, 255}, /* Magenta */
{128, 96, 0}, /* Brown */
{226, 189, 166}, /* Tan */
diff -Naurd t2/src/tuxpaint.c tx/src/tuxpaint.c
--- t2/src/tuxpaint.c 2004-11-24 18:35:15.0 -0500
+++ tx/src/tuxpaint.c 2004-11-25 00:31:35.0 -0500
@@ -3009,58 +3009,266 @@
}
+//
+// stamp tinter
+
typedef struct multichan {
double r,g,b; // linear
double L,u,v; // L,a,b would be better -- 2-way formula unknown
double hue,sat;
- unsigned char or,og,ob,oa; // old 8-bit sRGB values
- unsigned char nr,ng,nb,na; // new 8-bit sRGB values
+ unsigned char or,og,ob; // old 8-bit sRGB values
+ unsigned char nr,ng,nb; // new 8-bit sRGB values
+ unsigned char alpha;// 8-bit alpha value
} multichan;
+#define X0 ((double)0.9505)
+#define Y0 ((double)1.)
+#define Z0 ((double)1.0890)
+#define u0_prime ( (4.0 * X0) / (X0 + 15.0*Y0 + 3.0*Z0) )
+#define v0_prime ( (9.0 * Y0) / (X0 + 15.0*Y0 + 3.0*Z0) )
+
+static void fill_multichan(multichan *mc)
+{
+ double tmp,X,Y,Z;
+ double u_prime, v_prime; /* temp, part of official formula */
+ double Y_norm, fract; /* severely temp */
+
+ // from 8-bit sRGB to linear RGB
+ tmp = mc-or / 255.0;
+ mc-r = (tmp=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+ tmp = mc-og / 255.0;
+ mc-g = (tmp=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+ tmp = mc-ob / 255.0;
+ mc-b = (tmp=0.03928) ? tmp/12.92 : pow((tmp+0.055)/1.055,2.4);
+
+ // coordinate change, RGB -- XYZ
+ X = 0.4124*mc-r + 0.3576*mc-g + 0.1805*mc-b;
+ Y = 0.2126*mc-r + 0.7152*mc-g + 0.0722*mc-b;
+ Z = 0.0193*mc-r + 0.1192*mc-g + 0.9505*mc-b;
+
+ // XYZ -- Luv
+ Y_norm = Y/Y0;
+ fract = 1.0 / (X + 15.0*Y + 3.0*Z);
+ u_prime = 4.0*X*fract;
+ v_prime = 9.0*Y*fract;
+ mc-L = (Y_norm0.008856) ? 116.0*pow(Y_norm,1.0/3.0)-16.0 : 903.3*Y_norm;
+ mc-u = 13.0*mc-L*(u_prime - u0_prime);
+ mc-v = 13.0*mc-L*(v_prime - v0_prime);
+
+ mc-sat = sqrt(mc-u*mc-u + mc-v*mc-v);
+ mc-hue = atan2(mc-u,mc-v);
+}
+
static void tint_surface(SDL_Surface * tmp_surf, SDL_Surface * surf_ptr)
{
+ unsigned i;
+ int xx, yy;
- float col_hue, col_sat, col_val,
-stamp_hue, stamp_sat, stamp_val;
+ unsigned width = surf_ptr-w;
+ unsigned height = surf_ptr-h;
- Uint8 r, g, b, a;
-int xx, yy;
+ multichan *work = malloc(sizeof *work * width * height);
- rgbtohsv(color_hexes[cur_color][0],
- color_hexes[cur_color][1],
- color_hexes[cur_color][2],
- col_hue, col_sat, col_val);
-
+ // put pixels into a more tolerable form
+ SDL_LockSurface(surf_ptr
Re: [Tuxpaint-dev] Tux Paint 0.9.14 in LockerGnome
On Thu, 2004-11-25 at 15:58, Bill Kendrick wrote: Cool, check it out! ;) They claim Tux Paint requires Win98/2k/XP. They only provide a link to a Microsoft Windows installer. They don't even mention the Mac port, much less the Linux port or anything weird. This is not helping. :-( ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tux Paint 0.9.14 in LockerGnome
On Thu, 2004-11-25 at 16:08, Bill Kendrick wrote: On Thu, Nov 25, 2004 at 03:52:27PM -0500, Albert Cahalan wrote: On Thu, 2004-11-25 at 15:58, Bill Kendrick wrote: Cool, check it out! ;) They claim Tux Paint requires Win98/2k/XP. They only provide a link to a Microsoft Windows installer. They don't even mention the Mac port, much less the Linux port or anything weird. Well, admittedly, it /was/ in their Windows section. It also came via a Windows freeware/shareware site that I submitted to. This is nothing compared to the utter frustration that TUCOWS has been. An ancient version of Tux Paint for Linux is listed in their Linux section. No version is in their Mac section. No version is in their Windows section. I submitted 0.9.14 to their BeOS section and it was up within a few days. I can't tell if it does, but the Windows installer could mention that Tux Paint is available for less-infested OSes. Computer labs without porno pop-up windows are possible. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
