On Wed, 2004-11-10 at 12:56, Bill Kendrick wrote:
On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote:
Also, this isn't posted to this list because you've
blocked non-subscribers. I wish you wouldn't do that.
The [EMAIL PROTECTED] way is the right way.
Well, if you want 95
On Wed, 2004-11-10 at 14:57, Bill Kendrick wrote:
On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote:
Quoting various people:
1. 'Starters' are broken,
...
This is not only a MacOS problem. I get it too.
Tuxpaint: from CVS yesterday
OS: Debian-unstable
On Wed, 2004-11-10 at 14:57, Bill Kendrick wrote:
On Tue, Nov 09, 2004 at 09:40:18PM -0500, Albert Cahalan wrote:
BTW, the sound is messed up too. I just get static.
Unfortunately, this is /not/ an issue on the latest Mac OS X build.
Can you try altering the buffer size being set when
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
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
On Mon, 2004-11-22 at 16:27, Ben Armstrong wrote:
On Mon, 2004-11-22 at 16:02 -0500, Albert Cahalan wrote:
Are these terms acceptable for Tux Paint?
http://gallery.hd.org/terms.html
No. Redistribution is not allowed.
Oh, duh. Somehow I missed that. I suppose I could ask
for an exception
Why is it that this language alone does not
set both LANGUAGE and LC_ALL in tuxpaint.c?
Would it be harmful to set them both?
___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Here are two problems which might be the same bug.
You may need a slow computer or large display to
hit them. BTW, I have sound off right now.
When placing a stamp, marks can get left on the screen.
This is especially so if the mouse is moved quickly just
prior to placing the stamp.
When drawing
On Wed, 2004-11-24 at 06:13, Karl Ove Hufthammer wrote:
Albert Cahalan [EMAIL PROTECTED] wrote in
+#define VIDEO_BPP 15 // saves memory
This causes severe dithering artifacts. It's particularly visible
on the colour buckets, which look look *really* bad now.
Odd. Is your display actually
On Wed, 2004-11-24 at 06:29, Karl Ove Hufthammer wrote:
Albert Cahalan [EMAIL PROTECTED] wrote in
news:[EMAIL PROTECTED]:
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
On Wed, 2004-11-24 at 20:12, Bill Kendrick wrote:
On Wed, Nov 24, 2004 at 05:11:03PM -0500, Albert Cahalan wrote:
Unless someone objects, I'll add a feature request for this to the
SF tracker.
It seems complicated. :-(
On the contrary. I like the idea of a slider over the Grow
To show off the new tinter, the enclosed patch restores
the original purple. Yellow is much, much, nicer with
this new tinter.
The one trouble is that pickup truck. It isn't anywhere
near constant hue. It varies from blue to green so much
that going plus-or-minus 25 degrees from the primary hue
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
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
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
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. :-(
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
On Thu, 2004-11-25 at 15:46, Albert Cahalan wrote:
On Thu, 2004-11-25 at 14:50, Karl Ove Hufthammer wrote:
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
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
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
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
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
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
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,
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]
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
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
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
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.
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
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]
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
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
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
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:
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
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
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
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 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
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
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
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
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
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
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
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
How's this?
attachment: col3d.jpg___
Tuxpaint-dev mailing list
[EMAIL PROTECTED]
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
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
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
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
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
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
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
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
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:
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:
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:
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.
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
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
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
...
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
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:
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
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
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
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
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
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);
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
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
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;
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
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
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
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
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. :^)
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
1 - 100 of 113 matches
Mail list logo
