[Tuxpaint-dev] Bugs moved to SourceForge.net
We've now finished moving all open bugs to SourceForge.net: http://sourceforge.net/tracker/?group_id=66938 We currently have a total of 47 bugs and 24 feature requests. Anybody's welcome to work on fixing them. One bug I personally would like to see fixed, is bug #1057332: http://sourceforge.net/tracker/index.php?func=detailaid=1057332group_id=66938atid=516295 Support different default size for stamps than the stamp images size. Explanation: For example, the actual image of an apple could be 500x400 pixels, but selecting the apple would display a scaled down 50x40 (or 70x56 or whatever) image. Resized (especially scaled up) versions of the stamp would then look much better, without any of the very ugly pixelation and jagged edges that currently occurs. This would make it much easier to properly use the many high- quality, high-resolution cliparts from OpenClipart.org. -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src/po nb.po, 1.8, 1.9
Bill Kendrick [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: Fixed to Norwegian Bokmål translation, from Klaus Ade Johnstad snip Karl, if you haven't, can you add Klaus to the AUTHORS.txt and CONTRIBUTORS.txt files in the packages? (I've added him to the Developers page on the website.) Done! -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tux Paint Bug Feature Trackers created
Bill Kendrick [EMAIL PROTECTED] wrote in news:[EMAIL PROTECTED]: https://www.sf.net/projects/tuxpaint/ I'm happy to accept help (Technicians and/or Admins), as well as suggestions for categories/etc. for the trackers. I would instead suggest removing all of the categories. Categories make sense for large projects, with many developers, each responsible for their own category. For small projects like this, they make no sense at all, and just make bug reporting slower and more difficult. (Bug reporting is something which should be as easy as possible!) I have been ignoring the categories entirely when submitting bugs. And Bill, could you add a mailing list for the bug report system, so we can choose to get an e-mail for each new and updated report. (There's not heavy bug report traffic, so perhaps we even can use this mailing list?) -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
I kind of like this idea of submitting the patch to the list. 'Cuz we can
discuss it =)
On Sun, 21 Nov 2004, Albert Cahalan wrote:
[snip]
-CFLAGS=-O2 -Wall
+CFLAGS=-O2 -Wall -fno-common -ffast-math \
+ -W -Wall -Wcast-align -Wredundant-decls \
+-Wbad-function-cast -Wwrite-strings -Waggregate-return \
+ -Wstrict-prototypes -Wmissing-prototypes
+
[snip]
Turning on extra error messages sounds good.
-ffast-math should be okay, but it also turns on
-funsafe-math-otpimizations which I'm kind of weary of... Any experts on
this option?
-Wall is defined twice... =P
enum {
COLOR_BLACK,
+ COLOR_GREY,
+ COLOR_SILVER,
COLOR_WHITE,
COLOR_RED,
COLOR_PINK,
COLOR_ORANGE,
COLOR_YELLOW,
- COLOR_LIME,
+ COLOR_NEON,
COLOR_GREEN,
- COLOR_CYAN,
+ COLOR_SKYBLUE,
COLOR_BLUE,
COLOR_PURPLE,
- COLOR_FUCHSIA, /* ... */
+ COLOR_MAGENTA,
COLOR_BROWN,
- COLOR_GREY,
- COLOR_SILVER, /* ... */
+ COLOR_TAN,
+ COLOR_BEIGE,
NUM_COLORS
};
[snip]
I like these color names better than the previously defined ones, but if
we're going to change the names of the colors, let's use the canonical
names, perhaps adopting the color names in /etc/X11/rgb.txt file. We may
also have to retranslate the color names.
BTW, does changing the names of the color and ordering affect file
saving/loading? Will reordering the palette inconvenience the users, and
if so, should we reorder them, and does the reordering make more intuitive
sense? (I haven't checked the new orders.)
[snip]
-#define MAX_STAMPS 256
+#define MAX_STAMPS 512
[snip]
If we're gonna increase the stamps, is 512 enough? What's our stamps
collection size?
[snip]
#ifndef WIN32
- if (Mix_OpenAudio(44100, AUDIO_S16, 2, 1024) 0)
+ if (Mix_OpenAudio(44100, AUDIO_S16SYS, 2, 1024) 0)
#else
if (Mix_OpenAudio(44100, AUDIO_S16, 2, 2048) 0)
#endif
This change is for Mac, right? Does this change negatively affect Linux
and/or BeOS (or Sun, etc.)?
-Mark
--
Mark K. Kim
AIM: markus kimius
Homepage: http://www.cbreak.org/
Xanga: http://www.xanga.com/vindaci
Friendster: http://www.friendster.com/user.php?uid=13046
PGP key fingerprint: 7324 BACA 53AD E504 A76E 5167 6822 94F0 F298 5DCE
PGP key available on the homepage
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
I'm applying this in pieces... On Sun, Nov 21, 2004 at 06:54:21PM -0500, Albert Cahalan wrote: 1. add some warning flags to the Makefile Done. I see I have some code clean-up to do! I want there to be no warnings whatsoever! 2. adjusts the colors (fixing bug #1053065) Applied. -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
RE: [Tuxpaint-dev] [PATCH] misc fixes
I didn't have any luck installing the application in terminal services install mode. The app still freezes when you exit. Does anyone have any ideas? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bill Kendrick Sent: Sunday, November 21, 2004 8:42 PM To: Developmental mailing list for Tux Paint, a drawing program for young children. Subject: Re: [Tuxpaint-dev] [PATCH] misc fixes I'm applying this in pieces... On Sun, Nov 21, 2004 at 06:54:21PM -0500, Albert Cahalan wrote: 1. add some warning flags to the Makefile Done. I see I have some code clean-up to do! I want there to be no warnings whatsoever! 2. adjusts the colors (fixing bug #1053065) Applied. -bill! ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] [PATCH] misc fixes
On Sun, 2004-11-21 at 20:25, Mark K. Kim wrote: Turning on extra error messages sounds good. That's all you can turn on without... a. being gcc version-specific b. getting warnings for standard include files c. going insane :-) Regarding the last, there are a couple warnings that may look impossible to eliminate at first glance, but are not bad once you get what the concise message is all about. Adding static in places (default for C++, but not for C) will be helpful. -ffast-math should be okay, but it also turns on -funsafe-math-otpimizations which I'm kind of weary of... Any experts on this option? It's not really unsafe. :-) Normally, math is seriously slowed down by requirements related to the following: a. must set errno for sqrt(-5.2) and other bad math b. must not do algebraic optimization c. must cause SIGFLT signal in the right places Some people like to trap division by zero so that they can substitute in a correct value. Some people like to trap overflow so that they can fudge the exponent for greater range. There's no way Tux Paint will be doing this kind of thing. - COLOR_LIME, + COLOR_NEON, COLOR_GREEN, - COLOR_CYAN, + COLOR_SKYBLUE, COLOR_BLUE, COLOR_PURPLE, - COLOR_FUCHSIA, /* ... */ + COLOR_MAGENTA, COLOR_BROWN, - COLOR_GREY, - COLOR_SILVER, /* ... */ + COLOR_TAN, + COLOR_BEIGE, NUM_COLORS }; [snip] I like these color names better than the previously defined ones, but if we're going to change the names of the colors, let's use the canonical names, perhaps adopting the color names in /etc/X11/rgb.txt file. We may also have to retranslate the color names. I went for kid-friendly. I struggle to spell fuchsia. I asked my wife for an opinion, and she reports that a kid's toy and/or TV show (both I guess) uses magenta. A kid trying to pronounce fuchsia could get offensive. :-) The Sky blue is actually that now, computed as the average value of the sky in numerous images of the sky. (if you try this, remember to allow for gamma) Likewise, tan and beige were computed from many images. I don't care for silver, since it doesn't sparkle or gleam, but I figured light grey might be to difficult to read. BTW, both grey and gray are considered correct spellings. -#define MAX_STAMPS 256 +#define MAX_STAMPS 512 [snip] If we're gonna increase the stamps, is 512 enough? What's our stamps collection size? It'll do as an emergency fix. I hit the limit with about three dozen local stamps. [snip] #ifndef WIN32 - if (Mix_OpenAudio(44100, AUDIO_S16, 2, 1024) 0) + if (Mix_OpenAudio(44100, AUDIO_S16SYS, 2, 1024) 0) #else if (Mix_OpenAudio(44100, AUDIO_S16, 2, 2048) 0) #endif This change is for Mac, right? Does this change negatively affect Linux and/or BeOS (or Sun, etc.)? It should help more machines than it hurts. CPU soundcard notes LE LECommon PC. Unchanged. LE BEBroken before, and broken now. (rare) BE LEBroken now, but expected to be rare. BE BEMac. Now works, even if the drivers won't byteswap. It's rare to have a soundcard that only works with a byte order that is opposite to the CPU. I believe that the MacOS port will handle both; we'll see. ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] rainbow tools
I think it would be good to have a tool, or tools, for drawing rainbows. For the primary rainbow, the inside angle is 80 degrees total (40+40) and the outside angle is 84 degrees. If we assume that a tuxpaint canvas has a 70-degree vertical field of view, same as used for popular FPS games, the rainbow size in pixels is determined. One might wish to draw a partial rainbow, and one might wish to place the horizon anywhere. So, trouble... The interface that comes to mind is that the user does a click-and-drag with rubber band effect to see where the rainbow will go. Constrain the second point to be within the diameter of the rainbow and not directly above or below the first point. Then there are exactly two circles passing through the two points, each divided into two arcs by the points. Eliminate the arcs that have an upside-down portion. This leaves one arc to be rendered as the rainbow. The next problem is endpoint treatment. They can be cut horizontally, but that is no good near the edges of the screen. Fading out is an option. Fading out is especially useful for realistic (as opposed to cartoon-like) rainbows. Cartoon-like rainbows have nicely distinct colors. In some ways though, they propagate a lie about how rainbows look. Realistic rainbows are beautiful and educational, but can be trouble. Going from inside to outside, you get: a. a bright area b. blue to red (40 to 42 degrees) bright primary bow c. a dark area d. red to blue (50 to 53 degrees) dim secondary bow e. slightly bright area When the Sun is low, you only see the yellow-red part. When the raindrops are big, the top is missing. (the drops are no longer spherical) When the drops are small, you get green and magenta bands just inside the primary bow. (caused by interference effects) I have the data I need to produce this. The problem of course is that the whole screen must be updated in order to get the light areas (a and e) right. This pretty much means that usage must be: 1. draw the background (sky,clouds,airplanes...) 2. add the rainbow 3. draw the foreground Thoughts? BTW, something involving spline paths also comes to mind. See the Inkscape write your name example in the tutorial, and imagine a rainbow rendered along the path. It wouldn't have the correct shape and size, but might be useful for art. (it's messy and near-useless for teaching about rainbows) ___ Tuxpaint-dev mailing list [EMAIL PROTECTED] http://tux4kids.net/mailman/listinfo/tuxpaint-dev
