On Sat, 2005-02-19 at 21:04 -0800, Bill Kendrick wrote:
> On Sun, Feb 20, 2005 at 12:38:59AM +0100, Karl Ove Hufthammer wrote:
> > Latest CVS version:
> > Flipping and mirroring stamps doesn't work anymore.
>
> I just noticed that the other day, but haven't had time to look into it.
Ah, yes, ther
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 editi
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
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?
On Sun, 2005-01-23 at 19:01 -0800, Bill Kendrick wrote:
> On Sun, Jan 23, 2005 at 11:51:44AM -0500, Albert Cahalan wrote:
> > You should have also seen this:
> > printf("Sending %u bytes with %u families.\n", size, num_font_families);
> >
> > Did you? (it
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. Las
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.
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 ju
On Fri, 2005-01-21 at 02:19, Bill Kendrick wrote:
> On Thu, Jan 20, 2005 at 11:41:13PM +0000, Albert Cahalan wrote:
> > Update of /cvsroot/tuxpaint/tuxpaint/src
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3780/src
> >
> > Modified 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 ofte
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
Oh, if you do this, a semi-managable way might be:
country_en_CA.png
country_fr_CA.png
neighborhood_en_CA.png (adds USA and Greenland)
neighborhood_fr_CA.png
region_en_CA.png (about 1/6 of Earth's surface)
region_fr_CA.png
world_en_CA.png (seriously warped, as usual)
world_fr_CA.png
_
On Fri, 2005-01-21 at 16:20, Bill Kendrick wrote:
> Does anyone here have pointers to freely-distributable maps that we can
> alter and included in Tux Paint? (Or, in the end, as a separate download.)
It'd have to be a separate download unless you want
to get Tux Paint banned in several countrie
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 tha
On Fri, 2005-01-21 at 02:19, Bill Kendrick wrote:
> On Thu, Jan 20, 2005 at 11:41:13PM +0000, Albert Cahalan wrote:
> > Update of /cvsroot/tuxpaint/tuxpaint/src
> > In directory sc8-pr-cvs1.sourceforge.net:/tmp/cvs-serv3780/src
> >
> > Modified Files:
> >
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_su
On Thu, 2005-01-20 at 03:39, Bill Kendrick wrote:
> On Wed, Jan 19, 2005 at 11:32:40AM -0500, Albert Cahalan wrote:
> > Just how many fonts do you have anyway?
>
> Good question. :^)
>
> Just counting TTFs, ("locate .ttf | wc -l"), I apparently have 1300 !?!?
Als
Just how many fonts do you have anyway?
I allowed for 64k, which would take an hour or two
to load and could likely occupy a gigabyte of RAM
once the user scrolls to the last font... that is,
if the user can do so before death by old age.
I just checked in something to print the number of
font fa
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. :-)
&g
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 vers
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. :^)
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 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 n
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 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.
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 assu
> 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
> scr
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
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 t
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
&
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.
___
Tuxpaint-dev mailing list
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
On Fri, 2005-01-14 at 10:08, Karl Ove Hufthammer wrote:
> Albert Cahalan <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > Start-up will go faster if some of the work is put
> > in threads. This is particularly true for disk reads.
>
> Indeed. Tux
On Fri, 2005-01-14 at 03:59, Bill Kendrick wrote:
> On Sat, Jan 08, 2005 at 01:33:50AM -0500, Albert Cahalan wrote:
> >
> > This one will do the job:
> > http://luneelfique.free.fr/elvishring.otf
> >
>
> FYI, without loading any other fonts (except the ones in
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 remem
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 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
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 w
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 dark
The (new) darker blue works nicely for that phony look
that some people seem to like:
<>___
Tuxpaint-dev mailing list
Tuxpaint-dev@tux4kids.net
http://tux4kids.net/mailman/listinfo/tuxpaint-dev
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).
Tak
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
On Wed, 2005-01-12 at 21:55, Bill Kendrick wrote:
> On Thu, Jan 13, 2005 at 12:11:12AM +0000, 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
&g
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'.
&g
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 (
> 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
On Wed, 2005-01-12 at 16:24, Karl Ove Hufthammer wrote:
> Albert Cahalan <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> >> SDL_Pango:
> >> http://sdlpango.sourceforge.net/
> >> http://sourceforge.net/projects/sdlpango/
> >
> >
On Wed, 2005-01-12 at 16:05, Karl Ove Hufthammer wrote:
> Albert Cahalan <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> >> Yeah, "where to put delete?" has been my issue all along.
> >
> > That button makes me nervous.
> >
> >
On Wed, 2005-01-12 at 15:29, Bill Kendrick wrote:
> On Wed, Jan 12, 2005 at 08:27:54PM +, Karl Ove Hufthammer wrote:
>
> > Made shape definitions more correct.
>
> When doing these changes, can you double-check that the documentation
> gets updated? (Or, at least, put a TODO item somewhere :
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
On Wed, 2005-01-12 at 12:41, Karl Ove Hufthammer wrote:
> Albert Cahalan <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > Given the shear number of things that Hebrew users
> > want mirrored, it might be easier to just mirror
> > all of tuxpaint.
On Wed, 2005-01-12 at 12:18, Karl Ove Hufthammer wrote:
> Albert Cahalan <[EMAIL PROTECTED]> wrote in
> Making changes (inconsistent with other programs) to the way
> programs work to make them 'easier for kids to use' will
> mostly only be counter-productive.
I agre
On Wed, 2005-01-12 at 11:59, Karl Ove Hufthammer wrote:
> Sometime in the future Tux Paint will *need* to move to using
> Pango for text rendering. This is needed to support many
> non-western scripts and languages (whose rendering is *extremely*
> complex, but is automatically handled correctly b
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.
> >
> >> There are some other
> >> possibilities though: the toolbar could be active, so that
> >> the "Back" button become
On Wed, 2005-01-12 at 11:53, Karl Ove Hufthammer wrote:
> Bill Kendrick <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> > Perhaps when the "noquit" option is set, we can use
> > Ctrl-Alt-Esc or some other harder-to-hit combination for
> > exiting...?
>
> Ctrl + Alt + Esc brings up the
I've attached a zone plate image. Put it in your stamps
directory. (should this go in tuxpaint or tuxpaint-stamps?)
First, try it plain. If you see dark vertical bars, you
need to get a new monitor. If you see more circles than
the central one (and hints of off-image ones), you have
a gamma proble
On Tue, 2005-01-11 at 03:23, Bill Kendrick wrote:
> BUT... it was fun to write! And hopefully not too messy of an implementation.
> :)
You might use a macro, either this:
#define getpixel(s,x,y) \
(getpixel_fns[(s)->format->BytesPerPixel]((s),(x),(y)))
Or this:
#define DECL_PUTPIXEL(s) \
On Mon, 2005-01-10 at 16:09, Bill Kendrick wrote:
> On Mon, Jan 10, 2005 at 03:17:13PM -0500, Albert Cahalan wrote:
> > Ensure that FreeType is compiled with -fno-strict-aliasing
> > or, slower, with -O0. FreeType violates the C standard,
> > which now damn-near prohibits
On Mon, 2005-01-10 at 14:11, Karl Ove Hufthammer wrote:
> OK. I've now run GDB on Tux Paint. Here's the result.
It looks like a crash in FreeType, though the stack
is too messed up to be sure. Some random ideas:
Ensure that FreeType is compiled with -fno-strict-aliasing
or, slower, with -O0. Free
On Mon, 2005-01-10 at 13:24, Bill Kendrick wrote:
> On Mon, Jan 10, 2005 at 09:14:11AM -0500, Albert Cahalan wrote:
> > On Mon, 2005-01-10 at 02:29, Bill Kendrick wrote:
> > > I'm curious, did you mean to kill my "#ifdef DEBUG_FONTS" stuff!? :^(
> >
&
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 troub
That arrow is sometimes grey. SDL is kind of odd
about the way it treats alpha and about the image
operations it supports, so I ended up blitting an
image of grey or black over the arrow. This leaves
the alpha intact; filling a rectangle would destroy
the alpha.
The arrow isn't right anyway. It ha
Gee, that was easy. :-) Making it sane:
1. use PostScript 2, allowing RGB instead of CYMK
2. use binary data
3. don't use RLE or deflate compression
There is a bit more to be done, so that the image
is scaled and rotated right. At least if you know
the page size, this is just some simple math.
I
On Sun, 2005-01-09 at 14:52, Karl Ove Hufthammer wrote:
> Bill Kendrick <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> >> Well, how about now? Hopefully you can at least start up
> >> and do normal stuff.
> >
> > Yep! Works now, thanks! :^) :^) Yay!!!
>
> Not for me:
Do like so:
r
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
On Sun, 2005-01-09 at 08:23, Bill Kendrick wrote:
> On Sat, Jan 08, 2005 at 05:56:46PM -0500, Albert Cahalan wrote:
> > The big problems I saw were:
> >
> > 1. high mouse pressure
> > 2. mouse rotation instead of sideways movement
> > 3. accidental mouse rotation
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 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("/Libra
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-i
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);
>
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 quote
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 b
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 r
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 a
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 po
On Fri, 2005-01-07 at 05:02, Karl Ove Hufthammer wrote:
> Albert Cahalan <[EMAIL PROTECTED]> wrote in
> news:[EMAIL PROTECTED]:
>
> >> Bad font, 'a' and 'A' match: d05l.pfb, Dingbats, Regular
> >> Bad font, 'a' and 'A' m
On Thu, 2005-01-06 at 15:24, Bill Kendrick wrote:
> cat IMAGE.PNG | pngtopnm | pnmtops | lpr
That seems like a funny way to do things, since generating
a PPM is so dead simple. Going direcct to PostScript can't
be all that bad (being inocent perhaps).
Is there some reason you'd want the PN
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' matc
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
> t
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
> t
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,
> right as (or after) it's loading the fonts:
I had this problem until a made a blacklist. Perhaps you
have a font that needs to be on the blacklist. I suspect
that the font lib
On Mon, 2005-01-03 at 18:10, Bill Kendrick wrote:
> On Mon, Jan 03, 2005 at 12:44:30PM +0900, TOYAMA Shin-ichi wrote:
> > I think "tp-all48.jpg" is good.
>
> I think tp-all48.jpg is good, as well. However, tp-32x40.jpg might be
> better, as it leaves a little more room for text under the colors.
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
> ..
These all need to be assigned a meaning.
(boldness level, italic, don't-care, or reject-this-evil-font)
I'd like to know the full family and style
names, along with your idea of what the font
looks like. If you can share the fonts, do so.
I'll take some example guesses:
Font style parser stumped b
On Mon, 2005-01-03 at 18:11, Bill Kendrick wrote:
> On Mon, Jan 03, 2005 at 11:53:19AM -0500, Albert Cahalan wrote:
> > Much to my horror, I discovered that Tux Paint has
> > distinct near-duplicated code for handling various
> > mouse-related options. This lea
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 Sat, 2005-01-01 at 22:45, Ben Armstrong wrote:
> On the other hand, now that I look at it again, won't kids miss when
> pressing the black or grey color chooser buttons, and accidentally hit
> print or quit instead?
I think that's more of a problem when painting near the
edge of the canvas.
I
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 b
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 hig
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.
<>_
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.
<>
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.
<>___
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.
I have 3 ideas for this. I'll send them in
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.
I have 3 ideas for this. I'll send them in
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.
I have 3 ideas for this. I'll send them in s
Just to let people know what I'm thinking of...
flat green labels
scroll wheel doesn't go too far
scroll wheel works for Open dialog
wider Open dialog
add New dialog
grey outlines for all disabled stuff
"Colors" label should be grey too, not black or missing
free font style memory
#if out bulk
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 dis
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 ne
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 f
How about text controls? See attached image.
Without text controls:
4 sizes * 2 boldness * 2 italicness == 16
Also, double-wide buttons would be nice. This
would allow for more-useful example text like
this: ag4ytIl10O
<>___
Tuxpaint-dev mailing lis
1 - 100 of 175 matches
Mail list logo
