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] 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
[Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src colors.h, 1.8, 1.9
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 ;^) ) -bill! [EMAIL PROTECTED] April shower bring Kompressor power! http://newbreedsoftware.com/ ___ 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 magic.h, 1.11, 1.12 shapes.h, 1.3, 1.4
On Wed, Jan 12, 2005 at 11:37:21PM +0100, Karl Ove Hufthammer wrote: > Looks like I didn't try the tool. You can indeed change the > angles. But having a star would be more fun ... :) A star tool would be great. I forget, is that in the Features Wishlist? If not, can someone add it over at SourceForge? :) > Something else that has bothered me with the shape tools: They are > extremely difficult to use (for me!). If I want to draw a chimney > at the top of a roof, it takes several tries to get the correct > size *and* position (because the 'click' defined the centre and > not one of the corners, unlike other drawing programs). <:^( Yeah... we need modes, somehow. Oy! -bill! ___ 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
On Wed, Jan 12, 2005 at 10:42:16PM +0100, Karl Ove Hufthammer wrote: > But the rhombus may as well be removed. It's just a rotated > square, and Tux Paint supports rotating. Perhaps it can be > replaced by a star or something? The thing with the rhombus/diamond is that you can squish it to non-90-degree angles BEFORE rotating it. You cannot do that with the square. (I also don't want to turn Tux Paint into a geometry teaching lab. There are no doubt better programs for that, for the appropriate age range(s)) (Like KGeo or something... I dunno, honestly.) :) -bill! ___ 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, Jan 12, 2005 at 11:07:50PM +0100, Karl Ove Hufthammer wrote: > Bill Kendrick <[EMAIL PROTECTED]> wrote in > news:[EMAIL PROTECTED]: > > > Also, while I had to duplicate others' work (those who make Oops ... s/had/hate/ > > operating systems like Linux and Windows), we might want to > > support 'user sessions' /within/ Tux Paint. > > Sounds complicated. Complication I'd like to avoid. ;^) > >> Preferably the images should be moved to the trashcan in the > >> users system (KDE, GNOME, Windows, Mac), and not deleted. > >> (But we don't need a UI for getting it back.) > > > > Not a bad idea! > > But non-trivial to implement. We must first check if the user is > running either KDE or GNOME (or something else), and then check > where the trashcan is placed (not, it's *not* always in > Desktop/Trashcan). For Windows I guess the location is stored some > obscure place in the registry. I was afraid someone'd mention that. ;) -bill! ___ 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, Jan 12, 2005 at 11:24:03PM +0100, Karl Ove Hufthammer wrote: > The Gimp's GUI is indeed terrible (and not 'standard'!). I'll say this: it's better than Blender. ;) -bill! ___ 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, Jan 12, 2005 at 06:06:34PM -0400, Ben Armstrong wrote: > In the end, I think there's a place both for "personal stuff" and > sharing when it comes to Tux Paint. I'd like to see Tux Paint operate > equally well in both environments. The --nodelete idea is a great way > to do this, because every child can have their own stuff & not have it > wrecked, and yet all pictures on the shared account are available for > others to view, admire, and copy without deleting the original. Sounds great, esp. when combined with "--saveovernew" mode. :) -bill! ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 3-year-old user
On Wed, Jan 12, 2005 at 04:44:42PM -0500, Albert Cahalan wrote: > I think it's this: > http://www.lefinnois.net/aquapl.php3 Same guy, slightly different looking buttons. Perhaps I used an ancestor of what he has up now... :) > 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. Calvin from Tux4Kids just shipped me an old, recycled iMac running Mac OS X. I didn't have any USB devices except for a combo keyboard/trackball that my wife used to use on her desktop. Worked fine, so far as I can tell! -bill! ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 3-year-old user
On Wed, Jan 12, 2005 at 10:47:48PM +0100, Karl Ove Hufthammer wrote: > 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? Quoting doc/AUTHORS.txt: * UI buttons - Created using "AquaPro" button script in The GIMP Copyright (C) 2001 Denis Bodor <[EMAIL PROTECTED]> > Without? Are there Mac mice with more than one button? Yes. In fact, the new mini iMac (the "$500 special") specifically says on their website "your 2-button and scrollwheel mice will work, just plug them in" (paraphrased). In fact, way back before Mac OS X, when I was using Mac IIs and, nd Mac Centrises in college, many of them had 3-button mice for use with the X Window server software. (Run X11 apps on the Solaris box, display them on the slow, tiny Macs in the labs.) -bill! ___ 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
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> Learning the relations between different geometric figures is >> useful. > > I think it can be see best from similarity in the text. And explicit mention is always useful. >> 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! Sorry. I mean 'right angle', of course! :) >>> 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. Yes, I see it now. >> 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. Looks like I didn't try the tool. You can indeed change the angles. But having a star would be more fun ... :) Something else that has bothered me with the shape tools: They are extremely difficult to use (for me!). If I want to draw a chimney at the top of a roof, it takes several tries to get the correct size *and* position (because the 'click' defined the centre and not one of the corners, unlike other drawing programs). -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
Ben Armstrong <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Because of the cognitive skills and time factors I mentioned > in my last post, I think this is not always a bad idea. Do we > have an emerging pattern of various settings that, taken as a > group, make good defaults for a group environment? If so, > should we ship a docs/examples/tuxpaint.group.conf with > "typical" settings for such use? saveover=new? (This should also automatically be implied by --nodelete.) Perhaps uppercase=yes for young children? (Though many of strings used do not fit when rended as all uppercase.) And I believe there is a bug report of a slideshow feature that would be useful in a group context. -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >>> 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. >> >> No, don't make it more difficult to use. It pops up a warning >> dialogue, so (a) and (c) should ~never happen. > > I think it's time you and your kids migrated to the Gimp. > Your changes are nice for high school kids, but terrible > for normal 5-year-old kids. Hmm? My changes? I have advocated having *no* changes here. It's you that that wanted to change the delete button we currently have to some obscure 'Alt-Ctrl-Shift-click' combination. > 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'!). -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
Bill Kendrick <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Also, while I had to duplicate others' work (those who make > operating systems like Linux and Windows), we might want to > support 'user sessions' /within/ Tux Paint. Sounds complicated. >> Preferably the images should be moved to the trashcan in the >> users system (KDE, GNOME, Windows, Mac), and not deleted. >> (But we don't need a UI for getting it back.) > > Not a bad idea! But non-trivial to implement. We must first check if the user is running either KDE or GNOME (or something else), and then check where the trashcan is placed (not, it's *not* always in Desktop/Trashcan). For Windows I guess the location is stored some obscure place in the registry. -- Karl Ove Hufthammer http://blogg.huftis.org/ ___ 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:46 -0400, Ben Armstrong wrote: > I can imagine in a lab/classroom setting that gives children > the freedom to do so, such sharing could be commonplace, or the computer > might be set up without accounts altogether. This would be a good > thing, and I think is something the design of Tux Paint should > accomodate for. I just wanted to say a couple of more words about this, because I really feel strongly about it: Consider the social factors: Just like sharing of personal toys, sharing of personal accounts demonstrates the child has learned social behaviour. All of my children, except the three year old, understand "ownership" of each of their accounts, and all of the things that entails: privacy, organizing it the way they want it, and not wanting to have it wrecked. They also understand that when they use another person's account, they should respect that person's privacy, arrangement of their account the way they want it, and not wanting to have it wrecked. Now, consider the social implications of a classroom or lab where there are no personal accounts at all. Does it lead to deliberate vandalism of each others drawings? If so, are there consequences? What can a child whose drawing has been deliberately vandalised do about it? Social context is everything, of course. This could be either a great learning experience in the right context, or an absolutely horrible, unmanageable mess ni the wrong context. But that's up to those setting up the lab, isn't it? I prefer to see the positive potential. How about sharing of ideas? Increased ease of collaboration, or learning from each others' styles? Here is the computer, a wonderful medium on which drawings can be made, copied and modified over and over again, all from the same original. Having all children use one computer and one account means an opportunity for this kind of creative sharing that wouldn't be there if each user had their own account. In the end, I think there's a place both for "personal stuff" and sharing when it comes to Tux Paint. I'd like to see Tux Paint operate equally well in both environments. The --nodelete idea is a great way to do this, because every child can have their own stuff & not have it wrecked, and yet all pictures on the shared account are available for others to view, admire, and copy without deleting the original. Ben ___ 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] fonts
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Sure about that? > > Think about why all the car stamps show the cars > pointing to the right. For consistency? Take a look at your favourite clipart collection. You'll see cards pointing both ways. (The first result page of Google's image search have 9 cars point to the *left*, and 3 pointing to the right.) > All throughout the stamps, > this left-to-right orientation shows itself. No. Some stamps point to the right, but quite a few point to left. And take a look at the splash screen! ;) > The buttons sure do need to be mirrored. In the > tool choices, why is the paintbrush tool on the > side that it's on? Why not the other side? Because all apps have it that way. And the reason may be that we hold the paintbrush that way when writing. And they hold it the same way when writing Hebrew too, I believe. (Though I'm not sure. We could always ask the translator about what needs mirroring.) > Why do the dialog boxes have buttons to the left of text? > Why does Tux sit on the left of his text? All this needs to be changed for Hebrew. > Why is it that, when a tool has an odd number of options, > a blank spot appears on the lower right? (not left) I don't know if this should be changed for Hebrew. Probably? > Why is the "Colors" label on the left? This should also be changed for Hebrew. But haven't we almost agreed to remove it. > Why does the "Open" dialog have the normal action button on the > left side? The 'Open' dialogue have these buttons on the *right* in both GNOME, KDE and Windows. -- Karl Ove Hufthammer ___ 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] dead space and New dialog
On Wed, 2005-01-12 at 13:24 -0800, Bill Kendrick wrote: > You'd be surprised how many schools just use the same single account > for ALL users in a class... or worse yet, in an entire school! :^( Because of the cognitive skills and time factors I mentioned in my last post, I think this is not always a bad idea. Do we have an emerging pattern of various settings that, taken as a group, make good defaults for a group environment? If so, should we ship a docs/examples/tuxpaint.group.conf with "typical" settings for such use? Maybe also a docs/examples/tuxpaint.ltsp.conf? What other "typical" usage scenarios can we think of? Ben ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 3-year-old user
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > I agree with this, but I don't see Tux Paint as being > severely different for other programs. No, it isn't. > 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? >> 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? -- Karl Ove Hufthammer ___ 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 22:05 +0100, 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. > > b. destruction of another kid's work > (b) is a more general problem, solved by kids having their own > account (usually the case for schools, and in Linux?). But we > could add a 'nodelete' option (if it doesn't exist already -- I > can't be bothered to check). For very small kids (ages 2 to 4,) having to log in may not be worth the effort to support it. Also, where computers are a limited resource, kids are numerous, and total time available to play is short, login time per child can be quite brief. In such an environment, having to log out and log in again takes away from the total time available to play. I have observed this pattern among my children at home (all five of whom have their own accounts, by the way, and range from ages 3 to 14,) when time is short, and another child wants to play on the computer: a child will voluntarily help a (usually younger) child out by sharing her account. I can imagine in a lab/classroom setting that gives children the freedom to do so, such sharing could be commonplace, or the computer might be set up without accounts altogether. This would be a good thing, and I think is something the design of Tux Paint should accomodate for. Let's not rule out certain kinds of use just because they don't fit our preconceptions. I think we should expect a certain amount of sharing of sessions, either informally between kids with their own accounts, or because the system is set up to be always logged in for all kids to use. Ben ___ 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
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> When doing these changes, can you double-check that the >> documentation gets updated? (Or, at least, put a TODO item >> somewhere :^) ) > > I'm not so sure the definitions are more correct. > They are certainly aimed at older people. > > Old: "A square has four equal sides and L-shaped corners." > New: "A square is a rectangle with four equal sides." > > Now one shape depends on another. I can always change change it to something like this: A square has four equal sides and four right angles. Every square is a rectangle. Learning the relations between different geometric figures is useful. > 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! :) ) > Old: "Oval" > New: "An ellipse is a stretched circle." > > Is it an ellipse? Yes. > (and, should it be?) All non-trivial > ellipses are oval, but not all ovals are ellipses. Yes, I know. (Though sometimes oval is used synonymous with ellipse.) > As for it being a stretched circle, hmmm, that's not a > definition I'm comfy with. > > 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. But the rhombus may as well be removed. It's just a rotated square, and Tux Paint supports rotating. Perhaps it can be replaced by a star or something? -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] libSDL_ttf is bug-infested
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/ > > > > I still see no sane way to determine if a character is valid. > > What do I get? (trucation, boxes, NULL, missing spots...) > > It wouldn't be a problem anymore, as Pango automatically picks the > missing glyph from a different font on your system. That's seriously defective. It means "Webdings" will look suprisingly like another font. It means a French kid, after selecting the nice RiceCake font, will discover that accented characters look hideously wrong. Plus, I want to sort by character availability. How would the fonts be found? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] libSDL_ttf is bug-infested
Karl Ove Hufthammer <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> I still see no sane way to determine if a character is valid. >> What do I get? (trucation, boxes, NULL, missing spots...) > > It wouldn't be a problem anymore, as Pango automatically picks > the missing glyph from a different font on your system. Sorry, I wasn't thinking. That obviously won't be of any use here. Well, the reference manual is at: http://developer.gnome.org/doc/API/2.0/pango/ I'm sure there must be something useful in it. ;/ -- Karl Ove Hufthammer ___ 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 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. > > > > 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. > > No, don't make it more difficult to use. It pops up a warning > dialogue, so (a) and (c) should ~never happen. I think it's time you and your kids migrated to the Gimp. Your changes are nice for high school kids, but terrible for normal 5-year-old kids. The Gimp is more age-appropriate. It has a standard GUI (and an insane one too, but you can ignore that) and it offers all the power you want. You can even teach scripting. ___ 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, Jan 12, 2005 at 10:05:26PM +0100, Karl Ove Hufthammer wrote: > (b) is a more general problem, solved by kids having their own > account (usually the case for schools, and in Linux?). But we > could add a 'nodelete' option (if it doesn't exist already -- I > can't be bothered to check). Not a bad idea. Also, while I had to duplicate others' work (those who make operating systems like Linux and Windows), we might want to support 'user sessions' /within/ Tux Paint. This can be handled, partially, with the "--savedir" option, at the moment. You'd be surprised how many schools just use the same single account for ALL users in a class... or worse yet, in an entire school! :^( > Preferably the images should be moved to the trashcan in the users > system (KDE, GNOME, Windows, Mac), and not deleted. (But we don't > need a UI for getting it back.) Not a bad idea! -bill! ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] libSDL_ttf is bug-infested
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> SDL_Pango: >> http://sdlpango.sourceforge.net/ >> http://sourceforge.net/projects/sdlpango/ > > I still see no sane way to determine if a character is valid. > What do I get? (trucation, boxes, NULL, missing spots...) It wouldn't be a problem anymore, as Pango automatically picks the missing glyph from a different font on your system. -- Karl Ove Hufthammer ___ 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
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 :^) ) I'm not so sure the definitions are more correct. They are certainly aimed at older people. Old: "A square has four equal sides and L-shaped corners." New: "A square is a rectangle with four equal sides." Now one shape depends on another. I thought of, and had to reject, "rectangular rhombus". If you're going to make one shape depend on another, the "four" should go. I still like the old way better. 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. If it's otherwise in your part of the world, you can translate it as needed. Old: "Oval" New: "An ellipse is a stretched circle." Is it an ellipse? (and, should it be?) All non-trivial ellipses are oval, but not all ovals are ellipses. The side view of an egg is oval, and a rectangle with two semi-circles fitted to the sides is also oval. As for it being a stretched circle, hmmm, that's not a definition I'm comfy with. 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. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 3-year-old user
Bill Kendrick <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> This 'feature' is really doing kids a disservice. > > Never thought of it that way! So how about just ignore > everything but left-click? Yes. Please. :) >> Unfortunately not. Trackballs are generally much to large for >> kids' hands. Most mice are too (though there do exist >> computer mice for kids, sometimes used in schools). > > My wife has an itty-bitty optical USB mouse with a retractable > cord that she carries in her laptop case. Yes, laptop are sometimes smaller. Hmm, I wonder if children would find it easier or more difficult to use touch pads on laptops. BTW, I found a Website selling 'fun' mice and trackballs for children: http://www.askergoworks.com/shopdisplayproducts.asp?id=11&subcat=6 6&cat=Kids+Mice+%26+Trackball -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
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. > > 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. No, don't make it more difficult to use. It pops up a warning dialogue, so (a) and (c) should ~never happen. (b) is a more general problem, solved by kids having their own account (usually the case for schools, and in Linux?). But we could add a 'nodelete' option (if it doesn't exist already -- I can't be bothered to check). > 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. Preferably the images should be moved to the trashcan in the users system (KDE, GNOME, Windows, Mac), and not deleted. (But we don't need a UI for getting it back.) -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] Re: [Tuxpaint-commits] tuxpaint/src magic.h, 1.11, 1.12 shapes.h, 1.3, 1.4
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 :^) ) Thx! -bill! ___ 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] fonts
On Wed, Jan 12, 2005 at 12:55:13PM -0500, Albert Cahalan wrote: > Think about why all the car stamps show the cars > pointing to the right. All throughout the stamps, > this left-to-right orientation shows itself. And there's an option "--mirrorstamps" to mirror all of them. :^) > The buttons sure do need to be mirrored. In the > tool choices, why is the paintbrush tool on the > side that it's on? Why not the other side? Why do > the dialog boxes have buttons to the left of text? In Hebrew (currently the only RtL language Tux Paint 'supports' so far), I believe they're on the right side. > Why does Tux sit on the left of his text? Why is > it that, when a tool has an odd number of options, > a blank spot appears on the lower right? (not left) > Why is the "Colors" label on the left? Why does the > "Open" dialog have the normal action button on the > left side? And yeah, all this stuff needs to be flipped to the other side -bill! ___ 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, 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. -bill! ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 3-year-old user
On Wed, Jan 12, 2005 at 06:18:44PM +0100, Karl Ove Hufthammer wrote: > For example, I really don't like that right-clicking works the > same as left-clicking in Tux Paint. This may lead kids to get > used to right-clicking, and get very frustrated when right- > clicking doesn't work that way in other programs (or games). Then > they'll have to unlearn to right-click and learn to left-click. > This 'feature' is really doing kids a disservice. Never thought of it that way! So how about just ignore everything but left-click? > BTW, I've seen this problem (concerning Tux Paint) in real life, > so it's a very real issue, not just some hypothesis. Sorry! :^) > > As a less-expensive alternative, a trackball might > > work OK. > > Unfortunately not. Trackballs are generally much to large for > kids' hands. Most mice are too (though there do exist computer > mice for kids, sometimes used in schools). My wife has an itty-bitty optical USB mouse with a retractable cord that she carries in her laptop case. > (Personally, I've been using trackballs for years, and wouldn't > dream of going back to using a mouse!) I only like big trackballs, and only for Centipede and Missile Command. ;) -bill! [EMAIL PROTECTED] April shower bring Kompressor power! http://newbreedsoftware.com/ ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] fonts
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. > > No. The people don't see the world mirrored! > The stamps and the buttons should not be mirrored; > the toolboxes should only be moved from the left > side of the screen to the right. Sure about that? Think about why all the car stamps show the cars pointing to the right. All throughout the stamps, this left-to-right orientation shows itself. The buttons sure do need to be mirrored. In the tool choices, why is the paintbrush tool on the side that it's on? Why not the other side? Why do the dialog boxes have buttons to the left of text? Why does Tux sit on the left of his text? Why is it that, when a tool has an odd number of options, a blank spot appears on the lower right? (not left) Why is the "Colors" label on the left? Why does the "Open" dialog have the normal action button on the left side? ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] libSDL_ttf is bug-infested
On Wed, Jan 12, 2005 at 12:31:28PM -0500, Albert Cahalan wrote: > > Everybody needs Tux Paint, even terrorists! :-) That's not really very funny. >:^P > IMHO, they'd be better off learning English. Well, that's your view, but that's not necessarily the view of their parents, teachers (or even many of us developers :^) ), so I obviously don't want to force English on them. (Its a tuff language. ;^) ) > It's easier, superbly well supported, and needed > for correctly understanding much of our world. My dad once suggested Tux Paint could be used for teaching a second language. (i.e., show two languages at once.) -bill! ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> 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. Why? Why not consider all other user applications with open dialogues? This is a better object for comparison. > The back button takes you back. > A single click on a thumbnail will load an image. 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.) >> And we *can* get rid of the 'Colours' label, and increasing >> the space for the colours buckets. > > The stamps need the space more. Fine by me. > Grabbing the label too would be another much-needed slot. Well, I don't like this idea as much. :) -- Karl Ove Hufthammer ___ 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 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 agree with this, but I don't see Tux Paint as being severely different for other programs. The biggest differences are the use of color to indicate button state and the lack of filesystem access. > 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. > This may lead kids to get > used to right-clicking, and get very frustrated when right- > clicking doesn't work that way in other programs (or games). Then > they'll have to unlearn to right-click and learn to left-click. > This 'feature' is really doing kids a disservice. It's an Apple conspiracy. > > As a less-expensive alternative, a trackball might > > work OK. > > Unfortunately not. Trackballs are generally much to large for > kids' hands. Even a 4-inch ball should work. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] libSDL_ttf is bug-infested
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 by Pango). Everybody needs Tux Paint, even terrorists! :-) IMHO, they'd be better off learning English. It's easier, superbly well supported, and needed for correctly understanding much of our world. > SDL_Pango: > http://sdlpango.sourceforge.net/ > http://sourceforge.net/projects/sdlpango/ I still see no sane way to determine if a character is valid. What do I get? (trucation, boxes, NULL, missing spots...) There is only one way to control things. It's insane. You have to generate an undocumented pseudo-HTML code. While the library seems to take care of some aspects of handling fonts, it provides no way to see what is available. You'll just have to guess that a particular font might be available. ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] fonts
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. No. The people don't see the world mirrored! The stamps and the buttons should not be mirrored; the toolboxes should only be moved from the left side of the screen to the right. -- Karl Ove Hufthammer ___ 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. > > > >> 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] rainbow tools
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > I think it would be good to have a tool, or tools, > for drawing rainbows. Yes, it would be nice. The existing rainbow tool is really not adequate for this. > 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. Why must it be within the diameter of 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. Yes, fading sounds fine. > 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. I would prefer rainbow with a smooth gradient, but they don't need to be excessively realistic (we're not trying to create a 'photo drawing' application here). A nice gradient through the whole colour spectrum would suffice. -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] new direct PostScript printing code
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > I keep an eye on the web archive, which updates quickly enough. > I also run "cvs update"... but my editor doesn't notice. > Then I save again, and the "cvs update" gets clobbered. CVS will > assume this was intentional. Then I recommend that you change your editor. Doesn't almost all editors nowadays warn you when a file has been changed from outside the editor? -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Tux Paint 'group' in RPM spec?
Bill Kendrick <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > Right now, Tux Paint's RPM spec lists: > > Group: Amusements/Games > > Is there something more suitable? (Tux Paint's not a 'game', > per se :) ) Using the freedesktop menu spec, how about: Categories=Graphics;RasterGraphics;2DGraphics;KidsGame;Game (It *must* be in KidsGame, and then it should be in Game too.) -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 3-year-old user
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > The big problems I saw were: > > 1. high mouse pressure > 2. mouse rotation instead of sideways movement > 3. accidental mouse rotation I've seen this problem, but have observed that kids *do* very quickly learn to use the mouse properly. 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. For example, I really don't like that right-clicking works the same as left-clicking in Tux Paint. This may lead kids to get used to right-clicking, and get very frustrated when right- clicking doesn't work that way in other programs (or games). Then they'll have to unlearn to right-click and learn to left-click. This 'feature' is really doing kids a disservice. BTW, I've seen this problem (concerning Tux Paint) in real life, so it's a very real issue, not just some hypothesis. > As a less-expensive alternative, a trackball might > work OK. Unfortunately not. Trackballs are generally much to large for kids' hands. Most mice are too (though there do exist computer mice for kids, sometimes used in schools). (Personally, I've been using trackballs for years, and wouldn't dream of going back to using a mouse!) -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: TuxPaint Feature Request (tux4kids) [Re: [Esc] key to exit]
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 BIOS setup screen on some > computers ... ROTFL! Oh my, I remember using that. Windows might block it, and Linux surely will, but still... I was thinking the choice was overly difficult to type. Idea: plain Esc, but only when the mouse pointer is over the quit button ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] 3-year-old user
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > 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. Not all mice have scroll wheels, so we can't remove the scroll buttons. But we might perhaps change them to look (and work) like a real scrollbar, placed to the right of the stamps. This would also (partially) solve the problem with to many stamps, since you can quickly just drag the scrollbar slider to the stamps you're interested in. We will get a bit more vertical space, and a bit less horizontal space, which might be just enough to squeeze in an extra row of (resized, slightly smaller) stamp buttons. -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] libSDL_ttf is bug-infested
Albert Cahalan <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: > 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. 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 by Pango). Pango: http://www.pango.org/ SDL_Pango: http://sdlpango.sourceforge.net/ http://sourceforge.net/projects/sdlpango/ -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: TuxPaint Feature Request (tux4kids) [Re: [Esc] key to exit]
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 BIOS setup screen on some computers ... -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] Re: TuxPaint Bug Report (tux4kids)
Bill Kendrick <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> The X client is tuxpaint (on CentOS 3.1 ...or RHEL 3AS if you >> like) and the X Server is Apple's adaptation of X11 for Mac >> OS X. I'm running X11 beta 3, based on XFree86 4.2.1, and >> Mac OS X 10.2.8 (Jaguar). > > Thanks for the details. I see you've sent a few other > messages, I'll respond to them separately. Thanks! Regarding bug reports, could you set up a mailing list for all (new and updated) SF bug reports, Bill? (There not much bug traffic, so we could also just them be sent to tuxpaint-dev.) -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] --nosysfonts option added
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). -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
Re: [Tuxpaint-dev] dead space and New dialog
Bill Kendrick <[EMAIL PROTECTED]> wrote in news:[EMAIL PROTECTED]: >> I think that "New" should have a dialog. It would be like >> the "Load" dialog, containing the starters and a blank >> canvas. > > This is not a bad idea. I agree. >> The "Load" dialog has lots of dead space. > >> 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.) >> 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. > > What do other folks think about this? I'm not sure it's a bad > idea, but I'm also not totally sold on it. :^) Me neither. While I agree they aren't *needed*, they still add some colour to the UI. But perhaps they should be changed to not look so much like buttons? And we *can* get rid of the 'Colours' label, and increasing the space for the colours buckets. -- Karl Ove Hufthammer ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
[Tuxpaint-dev] 100 pictures in the gallery!
There are now 100 pictures in the Tux Paint gallery! I admit, I cheated... it was at 98, so I drew two more (one based on a painted still-life, the other based on a photo of one of my favorite subjects to draw!) Enjoy! http://www.newbreedsoftware.com/tuxpaint/gallery/ -bill! [EMAIL PROTECTED] April shower bring Kompressor power! http://newbreedsoftware.com/ ___ Tuxpaint-dev mailing list Tuxpaint-dev@tux4kids.net http://tux4kids.net/mailman/listinfo/tuxpaint-dev
