tuxpaint-devel — General discussion list for Tux Paint developers

[Tuxpaint-devel] startup/shutdown sounds

[Albert C. <aca...@gm...>]

Sometimes people start Tux Paint by mistake, and sometimes
adults need to shut it down after the kid is in bed. I hope it's OK
to quiet down some of these sounds.

That "na na naaaaa" sound is particularly loud and annoying.
It's also kind of like baby-talk, and kind of taunting, neither of
which I'd want a kid to copy.

I cringe at the thought of a teacher having to shut down a whole
room full of Tux Paint programs.

I suggest a small not-so-loud sound of a motor or car stopping,
or just nothing. The normal clicking sounds are fine.

Re: [Tuxpaint-devel] Major Mac OS X printing problems

[Albert C. <aca...@gm...>]

On 2/14/06, Bill Kendrick <nb...@so...> wrote:
>
> There are two major problems when printing in Tux Paint on Mac OS X:

Perhaps you should use the UNIX code. It ought to run
fine on MacOS X.

Re: [Tuxpaint-devel] Text-tool fonts

[Albert C. <aca...@gm...>]

On 2/14/06, John Popplewell <jo...@jo...> wrote:
> Hi all,
>
> I've been looking at the causes of this problem:
> http://www.johnnypops.demon.co.uk/tp-russian.png
> where the font buttons on the right display garbage.

The translator forgot to translate "Aa".

Actually, "Aa" is a poor choice. It is best to choose
characters that vary greatly between fonts. English
users would be best served by "ag".

> All but the first 3 buttons are the 'locale' fonts in e.g.
> '/usr/local/share/tuxpaint/fonts/locale/' ones like 'el.ttf' and
> 'he.ttf' etc.
>
> The font loading code tries to filter out 'broken' fonts in the
> function charset_works() but this doesn't actually check that 'Aa'
> renders correctly when the locale is set.

I don't think that "Aa" should need to work.

> I've made up a simple patch that starts the font scanner (by calling
> run_font_scanner()) *after* the command-line parameters have been
> handled and the locale set, and includes and extra test for 'Aa'.
>
> This also stops the font scanner running when and all you did was
> 'tuxpaint --help'.

This hurts. The font scanner should start as early as possible
to give it lots of time. It really should start immediately. If it
starts late, then the user is more likely to try to use the text
tool before the font scanner is done.

> Fonts that can't display 'Aa' when --lang is, say, Russian, no longer
> appear but unfortunately it doesn't stop fonts showing up that can't
> display characters that the user might type in.
>
> Eg if I set lang to Spanish, then all 10 font buttons appear with 'Aa'
> on them, but when I type in n-tilde and c-cedilla and then try each of
> them, some of them display garbage or the wrong characters :-(

The intent is that such fonts would be ranked poorly, and thus
be placed at the bottom of the list. Spanish-capable fonts would
go near the top.

I've seen plenty of neat fonts that don't cover all of ASCII, but
they are still fun to use. A few of these fonts are kind of an
abuse of the font system, providing stuff like astrological
symbols for "A" to "Z".

The important thing is that a user with scroll buttons disabled
will get only the best fonts for his language. If scroll buttons
work OK, then stuff like that astrological font ought to show up
at the bottom of the list.

> Excluding these 'locale' fonts from the font enumeration (unless they
> match the current locale) would help in this particular case, but in the
> general case of user and system fonts, this will come back to haunt us.

Put the lame fonts at the bottom instead of excluding them.
Only exclude a font if it will crash SDL_ttf or if it won't render
distinct characters.

> Any ideas? Do we need to dump SDL_ttf and use freetype2 itself?

If we want platforms without fork() to do background font
scanning, yes. SDL_ttf is not thread-safe. (grrrr...)

BTW, please make a unified diff next time you send a patch.
If you are generating diffs via CVS, try adding the following to
your ~/.cvsrc file:

diff -uN
rdiff -u

[Tuxpaint-devel] Text-tool fonts

[John P. <jo...@jo...>]

Hi all,

I've been looking at the causes of this problem:
http://www.johnnypops.demon.co.uk/tp-russian.png
where the font buttons on the right display garbage.

All but the first 3 buttons are the 'locale' fonts in e.g.
'/usr/local/share/tuxpaint/fonts/locale/' ones like 'el.ttf' and
'he.ttf' etc.

The font loading code tries to filter out 'broken' fonts in the
function charset_works() but this doesn't actually check that 'Aa'
renders correctly when the locale is set.

I've made up a simple patch that starts the font scanner (by calling
run_font_scanner()) *after* the command-line parameters have been
handled and the locale set, and includes and extra test for 'Aa'.

This also stops the font scanner running when and all you did was
'tuxpaint --help'.

Fonts that can't display 'Aa' when --lang is, say, Russian, no longer
appear but unfortunately it doesn't stop fonts showing up that can't
display characters that the user might type in.

Eg if I set lang to Spanish, then all 10 font buttons appear with 'Aa'
on them, but when I type in n-tilde and c-cedilla and then try each of
them, some of them display garbage or the wrong characters :-(

Excluding these 'locale' fonts from the font enumeration (unless they
match the current locale) would help in this particular case, but in the
general case of user and system fonts, this will come back to haunt us.

Any ideas? Do we need to dump SDL_ttf and use freetype2 itself?

cheers,
John.
PS I didn't commit it to cvs as I'm not confident about fiddling with
this fork() business :-) Seems to work OK on Windows and Linux, though.

Re: [Tuxpaint-devel] Sparkles - in color!

[Bill K. <nb...@so...>]

On Mon, Feb 13, 2006 at 12:02:11PM -0500, Albert Cahalan wrote:
> On 2/13/06, Bill Kendrick <nb...@so...> wrote:
> >
> > Sparkles are now drawn using the current color.  (It acts like an animated
> > brush, really.)  Comments?
> 
> You had me worried with that subject line!
> 
> Using the current color is good.

I'm still considering getting rid of Sparkles and Rainbow magic tools...


... and replacing them with animated brushes (to cover sparkles) and
a 'rainbow' color in the palette (so that any brush can paint like the
current rainbow magic).


It's pretty low-priority, though.

-bill!

Re: [Tuxpaint-devel] Sparkles - in color!

[Albert C. <aca...@gm...>]

On 2/13/06, Bill Kendrick <nb...@so...> wrote:
>
> Sparkles are now drawn using the current color.  (It acts like an animate=
d
> brush, really.)  Comments?

You had me worried with that subject line!

Using the current color is good.

Re: [Tuxpaint-devel] [Fwd: Bug#352556: tuxpaint: Segmentation Fault when clicking on the right of the rightmost color]

[Bill K. <nb...@so...>]

On Sun, Feb 12, 2006 at 02:59:19PM -0800, Bill Kendrick wrote:
> On Sun, Feb 12, 2006 at 06:54:31PM -0400, Ben Armstrong wrote:
> > > The bug is easy to reproduce. Just click between the right screen border
> > > and the last color on the right (color selection must be active. It is
> > > the default after startup). I then get:
> > >   Fatal signal: Segmentation Fault (SDL Parachute Deployed)
> 
> D'oh!  Confirmed!  Thanks! :)

And fixed in CVS! :)  (Was testing for "which < NUM_COLORS", but apparently
"which" would be -1 for invalid spots!  So now testing for "which >= 0", too.)

-bill!

Re: [Tuxpaint-devel] [Fwd: Bug#352556: tuxpaint: Segmentation Fault when clicking on the right of the rightmost color]

[Bill K. <nb...@so...>]

On Sun, Feb 12, 2006 at 06:54:31PM -0400, Ben Armstrong wrote:
> > The bug is easy to reproduce. Just click between the right screen border
> > and the last color on the right (color selection must be active. It is
> > the default after startup). I then get:
> >   Fatal signal: Segmentation Fault (SDL Parachute Deployed)

D'oh!  Confirmed!  Thanks! :)

-bill!

[Tuxpaint-devel] [Fwd: Bug#352556: tuxpaint: Segmentation Fault when clicking on the right of the rightmost color]

[Ben A. <sy...@sa...>]

-------- Forwarded Message --------
> From: Ludovic Rousseau <rou...@de...>
> Reply-To: Ludovic Rousseau <rou...@de...>,
> 35...@bu...
> To: Debian Bug Tracking System <su...@bu...>
> Subject: Bug#352556: tuxpaint: Segmentation Fault when clicking on the
> right of the rightmost color
> Date: Sun, 12 Feb 2006 17:59:31 +0100
> 
> Package: tuxpaint
> Version: 1:0.9.15b-2
> Severity: normal
> 
> The bug is easy to reproduce. Just click between the right screen border
> and the last color on the right (color selection must be active. It is
> the default after startup). I then get:
>   Fatal signal: Segmentation Fault (SDL Parachute Deployed)
> 
> I tried using gdb but can't get anything interesting:
>   [...]
>   Program received signal SIGSEGV, Segmentation fault.
>   [Switching to Thread -1214245184 (LWP 23974)]
>   0x08054063 in ?? ()
>   (gdb) bt
>   #0  0x08054063 in ?? ()
>   #1  0x00000000 in ?? ()
>   (gdb)
> 
> Bye,
> 
> -- System Information:
> Debian Release: testing/unstable
>   APT prefers testing
>   APT policy: (500, 'testing'), (90, 'unstable'), (1, 'experimental')
> Architecture: i386 (i686)
> Shell:  /bin/sh linked to /bin/bash
> Kernel: Linux 2.6.15-1-686
> Locale: LANG=fr_FR, LC_CTYPE=fr_FR (charmap=ISO-8859-1)
> 
> Versions of packages tuxpaint depends on:
> ii  libc6                       2.3.5-13     GNU C Library: Shared libraries an
> ii  libpng12-0                  1.2.8rel-5   PNG library - runtime
> ii  libsdl-image1.2             1.2.4-1      image loading library for Simple D
> ii  libsdl-mixer1.2             1.2.6-1.1+b1 mixer library for Simple DirectMed
> ii  libsdl-ttf2.0-0             2.0.7-1      ttf library for Simple DirectMedia
> ii  libsdl1.2debian             1.2.9-0.1    Simple DirectMedia Layer
> ii  libvorbis0a                 1.1.2-1      The Vorbis General Audio Compressi
> ii  libvorbisfile3              1.1.2-1      The Vorbis General Audio Compressi
> ii  netpbm                      2:10.0-10.1  Graphics conversion tools
> ii  tuxpaint-data               1:0.9.15b-2  Data files for Tux Paint, a paint 
> 
> Versions of packages tuxpaint recommends:
> ii  tuxpaint-config               0.0.6-1    Configuration tool for Tux Paint
> 
> -- no debconf information
> 

Re: [Tuxpaint-devel] Selection tools proposal - feedback wanted!

[Albert C. <aca...@gm...>]

On 2/8/06, Bill Kendrick <nb...@so...> wrote:
> On Wed, Feb 08, 2006 at 09:11:23PM -0500, Albert Cahalan wrote:

> > I was thinking that the "currently unused stamps cells" ought to just
> > go away, with the file selector area growing to use the extra space.
> > I was getting ready to do that when I changed jobs, moved, and then
> > was sick for a couple months.
>
> I was just about to ask what "currently unused stamp cells" referred to,
> and then finally figured it out -- the 'selector' toolbar on the right! :=
^)
>
> Yes, it should probably go away.  The toolbar on the left can go away, to=
o.
> Unless we decide that Tux Paint becomes kind of 'modal', like VI. :^)
> (In which case, clicking the paintbrush, eraser, etc. tools on the left
> would be a way of 'dismissing' the Open screen thumbnail browser.)

I really like the idea of letting the user dismiss the Open screen
by clicking on the left. Then, instead of disabling those buttons,
we could get rid of the cancel button. I'd love to see that dialog
lose _all_ of the oddball buttons.

> > I think it is best to reduce confusion in the "Open" and related dialog=
s.
> > The existing delete button is kind of misplaced. Adding more awkward
> > UI stuff just digs a deeper hole to get out of.
>
> Yeah, I want "Open" to be as simple as possible.  I'd like to move
> "Starters" to the "New" dialog, for example.

That would be wonderful. Start the list off with the current drawing
color, then maybe black and white.

> > Perhaps user-defined stamps should get their own left-side button.
> > That makes a clear distinction, yet gives the same stamp interface.
>
> The eventual idea will be to have a big "change which stamps set I'm
> looking at" bottom on the right, which would bring up a screen _similar_
> to the open dialog (but more likely it would look like a pop-up dialog,
> like you get when you click 'Quit').
>
> You would have all of the different 'major categories' (animals, vehicles=
,
> outerspace, etc.) which would load subsets of the ~250 we have now.
> (And _hopefully_ growing at some point! :^/ )  Along with the stamps we
> provide, a "My Stamps" option would be there, too.
>
> Sound reasonable?

No way. :-) It might be the only solution though. I'm not seeing
any solution that could rightly be called "reasonable", either for
the kids (using it) or for the parents (producing icons).

> > It also avoids making the stamp listing grow larger. All saved images
> > could show up as stamps. I only see two problems with this:
> >
> > 1. not much space on the left side for that button
>
> Left side is getting crowded, without resorting to a set of scroll button=
s
> like we get on the right.  At this point, on 800x600 mode, we've got room
> for four more buttons.

Dropping support for 640x480 mode?

I wouldn't waste a button on "fill" alone. I'd rather see the magic
stuff split in two: large area effects, and programmed brushes

Fill and flip are large area effects.

Smudge, grass, and lighten are programmed brushes.

Splitting allows some stuff to reasonably appear both ways.
For example, "lighten" could work either way.

> > 2. the user may still get confused by choosing an unintended
> >    option, giving them the wrong set of stamps to choose from
>
> I feel there should only be _one_ "Stamps" tool button on the left.
> And, as described above, a way to 'swtich' between collections.

Psychologically, user-defined stamps are rather special.

> > One question left is: when does the stamp extraction happen?
> >
> > a. on file save, and stored to disk
> > b. on file save and on Tux Paint start-up (not stored to disk)
> > c. on selection of the user-defined stamps menu (discard when done)
> > d. on 1st selection of menu, and kept up to date on file save
>
> I'm not sure I'm keen on mixing what the "Save" button on the left does.
> I'm also not sure about so loosely mixing 'picture' vs. 'stamp.'
>
> I prefer the idea of creating a stamp being a process:

I see this as adding an unnessesary step that kids will have
to struggle with. The unnessesary distinction adds a whole
new set of requirements that the UI has to handle. There has
to be a way to delete the stamp. (the other way, it would not
be jarring to have the stamp be deleted along with the image)

I really don't like mixing selections into this. That would
exclude all the younger kids. If someone wants selections,
they are probably ready to graduate from Tux Paint.

> I admit, though, this does not really cover what one would do with
> regards to later 'editing' a stamp (changing it and re-saving it as
> the same stamp) or deleting unwanted stamps that were generated by the
> "Make a New Stamp" Selection Action button.

Depending on UI details, I expect that editing attempts will cause either:

a. numerous redundant copies of the stamp
b. quality loss via repeated scaling

> > Perhaps the current image should ALWAYS be a stamp, kept
> > continuously up to date. (in the first slot?) One could do some
> > neat hall-of-mirrors effects that way, or magnify a too-small
> > image to fill the screen better.
>
> Oh man, crazy.  :^)

I have some even crazier ideas for users with powerful CPUs.

Imagine seeing 4 copies of the image in a 2x2 layout.
Your brush appears as 4 brushes all at once, drawing
on all 4 copies of the image. It's seamless, so you can
go from one side of the screen to the other without
noticing a boundry. This lets you draw perfect tilable
background images. Where supported (GNOME, KDE,
MacOS, Windows), offer a "set desktop background"
button. Offer the tilable background when creating a new
image, with the normal scaling that stamps have. Maybe
even offer arbitrary rotation. Let the user use the tilable
image as a brush, again with scaling and rotation.

Imagine a make-more-room button. The existing image
shrinks, perhaps by a factor of two in each direction.
Then, extrapolate from the small image to create new
data to fill around it. For example, suppose I have a
drawing of a house on a hill with grass and dandilions.
There is a sky with fluffy clouds and a driveway that
goes to the bottom of the screen. The result should have
a smaller house. The driveway should still reach the
bottom of the screen. The dandilions should be smaller,
but there should be many more. The placement of the
dandilions should be natural, seamless with the ones
that were already there. The grass and sky should go to
the edge of the screen, just as before, with the horizon
being extended in a reasonable manner. (not flat) Like
the dandilions, the clouds should be smaller and more
numerous.

BTW, there is a 3rd-party gimp plug-in that very nearly
is able to perform the make-more-room task!!! It's called
something like recompose or regenerate. It seems to do
a sort of fractal operation on the drawing. On my computer
(450 MHz Mac G4 w/ PC100 RAM on Maxbus) the code
takes dozens of minutes to process a Tux Paint image.
I got really close with the test image. The driveway often
came out nearly perfect. The house would be untouched.
(the shrinking was done manually, prior to starting) The
grass and sky would partially work; it was possible to get
the grass climbing up around the edges of the image.

> PS - Hope you're feeling well, Albert!

Pretty good, though much busier than I used to be. I have a
new job, and the oldest of my 5 kids is 6 years old.

Re: [Tuxpaint-devel] Selection tools proposal - feedback wanted!

[Albert C. <aca...@gm...>]

On 2/8/06, Ben Armstrong <sy...@sa...> wrote:

> What if in the Open dialog we also used the currently unused stamps
> cells to hold all system-wide stamps along with user-created pictures
> marked as stamps?  Then provide a "Stamp" button next to the open button
> that moves pictures to and from the stamp bar.  The "Stamp" button would
> be disabled for system stamps.  (If a user wants to edit a copy of a
> system stamp, just open a new picture and use the stamp to create a
> copy.)
>
> Clicking on the stamp bar would allow a stamp to be selected, just as
> pictures can be selected.  "Open" would be available for all stamps,
> while "Erase" would be available for user-created stamps, but be
> disabled for system stamps.

I was thinking that the "currently unused stamps cells" ought to just
go away, with the file selector area growing to use the extra space.
I was getting ready to do that when I changed jobs, moved, and then
was sick for a couple months.

I think it is best to reduce confusion in the "Open" and related dialogs.
The existing delete button is kind of misplaced. Adding more awkward
UI stuff just digs a deeper hole to get out of.

Perhaps user-defined stamps should get their own left-side button.
That makes a clear distinction, yet gives the same stamp interface.
It also avoids making the stamp listing grow larger. All saved images
could show up as stamps. I only see two problems with this:

1. not much space on the left side for that button

2. the user may still get confused by choosing an unintended
   option, giving them the wrong set of stamps to choose from

Well, I think this may beat the alternatives.

One question left is: when does the stamp extraction happen?

a. on file save, and stored to disk
b. on file save and on Tux Paint start-up (not stored to disk)
c. on selection of the user-defined stamps menu (discard when done)
d. on 1st selection of menu, and kept up to date on file save

Perhaps the current image should ALWAYS be a stamp, kept
continuously up to date. (in the first slot?) One could do some
neat hall-of-mirrors effects that way, or magnify a too-small
image to fill the screen better.

Re: [Tuxpaint-devel] Selection tools proposal - feedback wanted!

[Ben A. <sy...@sa...>]

On Tue, 2006-02-07 at 23:32 -0500, Albert Cahalan wrote:
> Draw something. Save it like normal. It's a stamp!
> 
> The alpha channel should be 100% automatic, using the predominant
> edge color as a color key. Sizing should be 100% automatic, using
> the smallest rectangle that will hold the image. If you delete the image,
> it disappears as a stamp. If you edit the image, the stamp changes too.

I like this!  I puzzled for some time on the bus to work this morning
how alpha would work with our saved stamps.

> Maybe there could be a checkbox to let the user exclude some
> drawings from becoming stamps, but this may be needless
> complexity. It's OK to make all saved images become stamps.
> It would be reasonable to filter out images that appear to be
> unsuitable, such as lacking an obvious color key or being based
> on a starter image.

What if in the Open dialog we also used the currently unused stamps
cells to hold all system-wide stamps along with user-created pictures
marked as stamps?  Then provide a "Stamp" button next to the open button
that moves pictures to and from the stamp bar.  The "Stamp" button would
be disabled for system stamps.  (If a user wants to edit a copy of a
system stamp, just open a new picture and use the stamp to create a
copy.)

Clicking on the stamp bar would allow a stamp to be selected, just as
pictures can be selected.  "Open" would be available for all stamps,
while "Erase" would be available for user-created stamps, but be
disabled for system stamps.

Ben

Re: [Tuxpaint-devel] Selection tools proposal - feedback wanted!

[Albert C. <aca...@gm...>]

On 2/7/06, Bill Kendrick <nb...@so...> wrote:
> On Tue, Feb 07, 2006 at 09:24:49PM -0400, Ben Armstrong wrote:
> > On Tue, 2006-02-07 at 14:49 -0800, Bill Kendrick wrote:
> > > As for deletion.  D'oh... I hadn't thought of that!
> > >
> > > It's going to get crowded, but perhaps when one of 'My' stamps are se=
lected,
> > > a "Trash" icon could appear at the bottom of the right selector...?
> > > (Near the mirror/flip/scaler.)
> > >
> > > Of course, disabling the ability to delete created stamps could be a
> > > simplification option in Tux Paint Config...
> >
> > Well, how about just making it part of the "Load" dialog?  To load a
> > stamp gives you a chance to edit it and save it (either as new or over
> > the old one).  Of course, once you're editing it again, to be
> > consistent, you'd need to select it all over again before saving it ...
>
> The problem here (IMO) is that if the user doesn't do the "selection"
> and then "save as stamp" part, they'll just end up re-saving the stamp,
> but now as a mostly-white image in their Save/Open folder.

It shouldn't be so complicated. This is better:

Draw something. Save it like normal. It's a stamp!

The alpha channel should be 100% automatic, using the predominant
edge color as a color key. Sizing should be 100% automatic, using
the smallest rectangle that will hold the image. If you delete the image,
it disappears as a stamp. If you edit the image, the stamp changes too.

Maybe there could be a checkbox to let the user exclude some
drawings from becoming stamps, but this may be needless
complexity. It's OK to make all saved images become stamps.
It would be reasonable to filter out images that appear to be
unsuitable, such as lacking an obvious color key or being based
on a starter image.

Re: [Tuxpaint-devel] Details on Stamp selection idea (Re: Selection tools proposal - feedback wanted!) [tuxpaint-devel only]

[Albert C. <aca...@gm...>]

On 2/7/06, Bill Kendrick <nb...@so...> wrote:

> > Numerous people have requested 'selection' tools in Tux Paint.
> > This is one of a few major things Tux Paint lacks, compared to more
> > professional (or at least 'typical') graphics tools.

I have strong doubts that this feature will be usable, but
assuming that it would be...

> * When the NEXT stamp is placed into the drawing, the entire unseend
>   canvas is 'lightened' by one notch.  (#000000 becomes #010101)
>   The new stamp's 'blob' is then placed in the canvas, again as
>   all-black (#000000).

A much cheaper way to implement this is to just change what
is being written. Then you don't need to lighten the mask.
The first blob is 0x00 (not #000000, because greyscale), the
second is 0x01, and so on. It wraps around of course.

I have often thought a save-as-stamp option might work OK.
Choose the predominant edge color as see-through, then trim
away the excess and let the result show up as a stamp.

Re: [Tuxpaint-devel] Selection tools proposal - feedback wanted!

[Ben A. <sy...@sa...>]

On Tue, 2006-02-07 at 17:40 -0800, Bill Kendrick wrote:
> The problem here (IMO) is that if the user doesn't do the "selection" 
> and then "save as stamp" part, they'll just end up re-saving the stamp,
> but now as a mostly-white image in their Save/Open folder.

How about saving the selection region as metadata in the image file?
Then when you re-load the stamp, you reload the selection region too.
Unless you completely undo the selection region while you are editing,
there is no need to re-select.  If you remember that the file you're
editing was a stamp to begin with, you can modify "Save" to act as "Save
as stamp" and as a final sanity check, you can refuse to "Save" (a
previously saved and reloaded stamp) or "Save as stamp" unless there is
a selection region active, prompting the user to select the stamp region
first.

Ben

Re: [Tuxpaint-devel] Selection tools proposal - feedback wanted!

[Ben A. <sy...@sa...>]

On Tue, 2006-02-07 at 14:49 -0800, Bill Kendrick wrote:
> As for deletion.  D'oh... I hadn't thought of that!
> 
> It's going to get crowded, but perhaps when one of 'My' stamps are selected,
> a "Trash" icon could appear at the bottom of the right selector...?
> (Near the mirror/flip/scaler.)
> 
> Of course, disabling the ability to delete created stamps could be a
> simplification option in Tux Paint Config...

Well, how about just making it part of the "Load" dialog?  To load a
stamp gives you a chance to edit it and save it (either as new or over
the old one).  Of course, once you're editing it again, to be
consistent, you'd need to select it all over again before saving it ...

Is there any way to do this in a reasonable & consistent fashion without
creating a whole new stamp editing mode?

Ben

Re: [Tuxpaint-devel] Selection tools proposal - feedback wanted!

[Bill K. <nb...@so...>]

On Tue, Feb 07, 2006 at 05:09:49PM -0500, mon...@co... wrote:
> Definetly start with rectangle and lasso tools. I'd say oval and
> magic only if the UI can still be kept simple.

Well, again, my idea was to have a collection of selection tools
over on the right side, which were available by clicking the "Selection"
scissors icon on the left side.

(BTW, due to popular demand, I'm planning on moving "Fill" out of the Magic
tools and into the main toolbar on the left.)


> The idea of creating custom stamps is really neat. Should the new
> stamps be saved to disk for later use ? It would of course mean that
> there would need to be a mechanism of deleting unwanted custom
> stamps. And to do that, the custom stamps would need to be visually
> seperated from the regular stamps.

Defintiely save them, to a private Stamps collection.  (Separate from
the system-wide ones.)


As for deletion.  D'oh... I hadn't thought of that!

It's going to get crowded, but perhaps when one of 'My' stamps are selected,
a "Trash" icon could appear at the bottom of the right selector...?
(Near the mirror/flip/scaler.)

Of course, disabling the ability to delete created stamps could be a
simplification option in Tux Paint Config...

-bill!

[Tuxpaint-devel] Re: [Tuxpaint-users] Selection tools proposal - feedback wanted!

[Bill K. <nb...@so...>]

On Tue, Feb 07, 2006 at 11:36:20AM -0800, Bill Kendrick wrote:
> The selection tools themselves would be some of the typical ones we're
> used to from other drawing programs:
> 
>   * Rectangular selection
>   * Oval selection
>   * Freehand ("lasso") selection
>   * Fuzzy ("magic wand") selection (select-by-color)  [this one is a 'maybe']
>   * Stamp selection [*]

Additionally, it occurs to me that we'd probably want a big "Plus" and
"Minus" button, for adding-to and removing-from the current selection.

So in the end, we'd have buttons like this on the right
(when the 'scissors' icon on the left was clicked):


  Rectangle            Dashed

  Lasso                Fuzzy (magic wand)

  Stamp

  Plus                 Minus      <-- these toggle
                                      (both off, plus on or minus on)

  Cut                  Copy       <-- these do the action immediately,
                                      then go back to the previous mode

  Paste                           <-- switches to pasting mode, similar to
                                      Stamps tool

and at the bottom, these become active when in pasting mode:

  Scale slider .................
  Mirror               Flip


-bill!

[Tuxpaint-devel] Details on Stamp selection idea (Re: Selection tools proposal - feedback wanted!) [tuxpaint-devel only]

[Bill K. <nb...@so...>]

As promised, here are more details on my 'stamp selection' tool idea.
(Only posting to tuxpaint-devel, because I'm covering the technical details
of my proposal.)

On Tue, Feb 07, 2006 at 11:36:20AM -0800, Bill Kendrick wrote:
> 
> Numerous people have requested 'selection' tools in Tux Paint.
> This is one of a few major things Tux Paint lacks, compared to more
> professional (or at least 'typical') graphics tools.
<snip>
>   * Stamp selection [*]
<snip>


So my idea is this...


* A separate greyscale canvas is created for each picture.
  (It could just be a big 8-bit matrix.)

* This canvas is never seen by the user, but is touched whenever a stamp
  is placed into a drawing, and examined when the "Stamp selection" tool
  is used.

* It would need to be saved, so that it could be reloaded when the main
  image is loaded.  It could simply be saved as an 8-bit greyscale PNG,
  along with the original image.  (e.g, "20060207121435-mask.png")

* This unseen canvas begins as all-white (in RGB: #FFFFFF).

* When a stamp is first placed into the drawing, an all-black 'blob' is
  placed in the same place within the unseen canvas, representing the
  shape of the stamp.  (It acts as a bitmask.)

* When the NEXT stamp is placed into the drawing, the entire unseend
  canvas is 'lightened' by one notch.  (#000000 becomes #010101)
  The new stamp's 'blob' is then placed in the canvas, again as
  all-black (#000000).

* ... and so on.  This allows the last 255 stamps' positions to be
  'remembered'.  (#000000 pixels represent where the most recent
  stamp is...  the lightest non-white (#FFFFFF) pixels (e.g., up to #FEFEFE)
  represent where the oldest stamp we can 'remember' was placed.)

* Of course, drawing over stamps (rainbow, sparkles, paintbrush) or
  otherwise affecting that part of the canvas (blur, blocks, smudge)
  do not affect that stamp's selection shape... but obviously the
  chunk of altered canvas will be what we cut/copy/paste.

* There's no way to remember what was 'behind' the stamp
  (e.g., if we drew a line, then placed a stamp over part of it, and later
  went to select and move or remove the stamp, that part of the line will
  have been lost.

* When stamps overlap, selecting the 'older' stamp will only select what's
  currently visible (since those pixels in the unseen canvas will have been
  lightened by one notch, and then overwritten by black (#000000) pixels.)

* The stamp selector would act like the relatively-recently-added
  "select-by-color" tool in The GIMP (and not like the "fuzzy selection"
  magic wand tool).  Of course, it would be acting on the unseen canvas
  (so the colors/shades/etc. of the stamps themselves are not considered.)

  This allows all of a non-contiguous stamp to be selected at once.
  (Note that a stamp may _become_ non-contiguous due to another stamp being
  placed over it more recently...)



This may be a spark of genious, or it might be utter garbage.
What do other people here think of the idea?

(Since Tux Paint is not inherently object-based and does not contain
true layers, this is my concept for providing an arbitrarily large (255)
method for selecting stamps 'after the fact', which has been occasionally
requested by teachers/parents.)

Thanks!!!

-bill!

Re: [Tuxpaint-devel] [Fwd: Bug#308194: #308194: tuxpaint: cannot type in russian]

[Morten S. <mo...@si...>]

Hi Ben,

Is the patched versions avaliable somewhere? We have some lacking letters i=
n=20
Norwegian as well, so if I could test it I could see if it solves our=20
problems (and for danes, swedes, germans and a few other West-European=20
languages as well)


My kids would hate me if I kill TP on our main PC, but I can test it (or=20
libraries) out elsewhere.

Morten
=2D-=20
Morten Sickel
http://sickel.net/
Dr=F8bak, Norway

Re: [Tuxpaint-devel] [Fwd: Bug#308194: #308194: tuxpaint: cannot type in russian]

[John P. <jo...@jo...>]

On Sat, Feb 04, 2006 at 02:18:32PM +0000, John Popplewell wrote:
> On Sat, Feb 04, 2006 at 09:13:03AM -0400, Ben Armstrong wrote:
> > -------- Forwarded Message --------
> > > From: Alexandra N. Kossovsky <sa...@sa...>
> > > Reply-To: Alexandra N. Kossovsky <sa...@sa...>,
> > > 30...@bu...
> > > To: Ben Armstrong <sy...@sa...>
> > > Cc: 30...@bu..., deb...@li...
> > > Subject: Bug#308194: #308194: tuxpaint: cannot type in russian
> > > Date: Sat, 4 Feb 2006 08:15:05 +0300
> > > 
> > > On Fri, Feb 03, 2006 at 11:39:19PM -0400, Ben Armstrong wrote:
> > > >         Here is a picture of Tux Paint in Russian on X, with the
> > > >         above patch (although this should mostly work with the
> > > >         SDL 1.2.9 Release version):
I just tried this with my test Debian system. After updating to what was
supposed to be SDL-1.2.9, and building Tux Paint from CVS, it didn't
work for me either. With a Russian keymapping, I just got one of two
uppercase characters )-:

So I grabbed SDL12 from CVS and, after installing some tools
(automake1.9, nasm etc.), I built a replacement libSDL which worked fine.

I can't provide any instructions on how to do this properly (I guess you
build your own Debian package and then install that) because I know very
little about binary package systems like Debian (after horrible beginner
experiences with non-Debian systems long ago) - I use Gentoo, and get to
curse everytime something that *used* to work gets broken :-)

> > Yes, it these are very nice Russian letters. The only problem I see is
> > squares in the right manu, in place of some Aa.
> I noticed that to. I guess that's some sort of font problem,
Does the same on Windows - I'll take a look at it,

cheers,
John.

Re: [Tuxpaint-devel] [Fwd: Bug#308194: #308194: tuxpaint: cannot type in russian]

[John P. <jo...@jo...>]

On Sat, Feb 04, 2006 at 09:13:03AM -0400, Ben Armstrong wrote:
> -------- Forwarded Message --------
> > From: Alexandra N. Kossovsky <sa...@sa...>
> > Reply-To: Alexandra N. Kossovsky <sa...@sa...>,
> > 30...@bu...
> > To: Ben Armstrong <sy...@sa...>
> > Cc: 30...@bu..., deb...@li...
> > Subject: Bug#308194: #308194: tuxpaint: cannot type in russian
> > Date: Sat, 4 Feb 2006 08:15:05 +0300
> > 
> > On Fri, Feb 03, 2006 at 11:39:19PM -0400, Ben Armstrong wrote:
> > >         Here is a picture of Tux Paint in Russian on X, with the above
> > >         patch
> > >         (although this should mostly work with the SDL 1.2.9 Release
> > >         version):
> > >         http://www.johnnypops.demon.co.uk/tp-russian.png
> > >
> > >         Does this look more like what we are after?
> > 
> Yes, it these are very nice Russian letters. The only problem I see is
> squares in the right manu, in place of some Aa.
I noticed that to. I guess that's some sort of font problem,

cheers,
John.

[Tuxpaint-devel] [Fwd: Bug#308194: #308194: tuxpaint: cannot type in russian]

[Ben A. <sy...@sa...>]

-------- Forwarded Message --------
> From: Alexandra N. Kossovsky <sa...@sa...>
> Reply-To: Alexandra N. Kossovsky <sa...@sa...>,
> 30...@bu...
> To: Ben Armstrong <sy...@sa...>
> Cc: 30...@bu..., deb...@li...
> Subject: Bug#308194: #308194: tuxpaint: cannot type in russian
> Date: Sat, 4 Feb 2006 08:15:05 +0300
> 
> On Fri, Feb 03, 2006 at 11:39:19PM -0400, Ben Armstrong wrote:
> >         Here is a picture of Tux Paint in Russian on X, with the above
> >         patch
> >         (although this should mostly work with the SDL 1.2.9 Release
> >         version):
> >         http://www.johnnypops.demon.co.uk/tp-russian.png
> >
> >         Does this look more like what we are after?
> 
> Yes, it these are very nice Russian letters. The only problem I see is
> squares in the right manu, in place of some Aa.
> 
> 

Re: [Tuxpaint-devel] [Fwd: Re: Bug#308194: #308194: tuxpaint: cannot type in russian]

[John P. <jo...@jo...>]

On Fri, Feb 03, 2006 at 06:44:13PM -0400, Ben Armstrong wrote:
> -------- Forwarded Message --------
> > From: Alexandra N. Kossovsky <sa...@sa...>
> > To: Ben Armstrong <sy...@sa...>,
> > 30...@bu...
> > Cc: deb...@li...
> > Subject: Re: Bug#308194: #308194: tuxpaint: cannot type in russian
> > Date: Sat, 4 Feb 2006 00:17:05 +0300
> > 
> > On Fri, Feb 03, 2006 at 02:55:23PM -0400, Ben Armstrong wrote:
> > > On Sat, 2006-01-21 at 18:15 +0300, Alexandra N. Kossovsky wrote:
> > > > Tuxpaint does not support Unicode at all. Some Americans think that
> > > > supporting unicode is supporting Latin-1 mapping to unicode. Such "unicode
> > > > support" does not work for Russians, Greeks and many other people. :-(
> > > 
> > > I am told that this is fixed in CVS.  However, I am puzzled by John's
> > > response:
> > > 
> > > http://sourceforge.net/mailarchive/forum.php?thread_id=9527943&forum_id=44504
> > > 
> > > John appears to be saying that his version of SDL is required.  If that
> > > is so, I can't package it for Debian.  However, if a Russian user would
> > > like to try tuxpaint from CVS (see http://sf.net/projects/tuxpaint) to
> > > see if it is any better with the latest SDL in Debian, I would
> > > appreciate the help.
> > 
> > I've just tried CVS tuxpaint on the Sarge and Etch systems. I see the
> > behaviour changed. Every time I type a Russian letter, I see a new letter
> > on the screen, but it is not the Russian letter. It is ISO-8859-1 letter
> > corresponding to the first byte of the unicode value.
> > 
> > I guess CVS tuxpaint should break ISO-8859-1 (non-ascii) users as well, 
> > but I hope it is a step into the right direction :-)
> > 
What version of SDL did you test this with? There is partial Unicode
support on X with the SDL-1.2.9 release.

There was a problem with Tux Paint, and there is/was a problem with SDL.

The SDL Windows backend is fixed in CVS:
https://bugzilla.libsdl.org/show_bug.cgi?id=39

The SDL X11 backend currently only has partial unicode support. I'm
helping work on it:
https://bugzilla.libsdl.org/show_bug.cgi?id=130

Here is a picture of Tux Paint in Russian on X, with the above patch
(although this should mostly work with the SDL 1.2.9 Release version):
http://www.johnnypops.demon.co.uk/tp-russian.png

Does this look more like what we are after?

Any help testing would be great.

If you want a working text-tool you need Tux Paint from CVS, and SDL
from CVS with the above patch (bug 130) if you are on X.

With help from Sam Lantinga (Mr. SDL), there is a good chance of the
next release of SDL-1.2.X having all this working,

cheers,
John.

[Tuxpaint-devel] [Fwd: Re: Bug#308194: #308194: tuxpaint: cannot type in russian]

[Ben A. <sy...@sa...>]

-------- Forwarded Message --------
> From: Alexandra N. Kossovsky <sa...@sa...>
> To: Ben Armstrong <sy...@sa...>,
> 30...@bu...
> Cc: deb...@li...
> Subject: Re: Bug#308194: #308194: tuxpaint: cannot type in russian
> Date: Sat, 4 Feb 2006 00:17:05 +0300
> 
> On Fri, Feb 03, 2006 at 02:55:23PM -0400, Ben Armstrong wrote:
> > On Sat, 2006-01-21 at 18:15 +0300, Alexandra N. Kossovsky wrote:
> > > Tuxpaint does not support Unicode at all. Some Americans think that
> > > supporting unicode is supporting Latin-1 mapping to unicode. Such "unicode
> > > support" does not work for Russians, Greeks and many other people. :-(
> > 
> > I am told that this is fixed in CVS.  However, I am puzzled by John's
> > response:
> > 
> > http://sourceforge.net/mailarchive/forum.php?thread_id=9527943&forum_id=44504
> > 
> > John appears to be saying that his version of SDL is required.  If that
> > is so, I can't package it for Debian.  However, if a Russian user would
> > like to try tuxpaint from CVS (see http://sf.net/projects/tuxpaint) to
> > see if it is any better with the latest SDL in Debian, I would
> > appreciate the help.
> 
> I've just tried CVS tuxpaint on the Sarge and Etch systems. I see the
> behaviour changed. Every time I type a Russian letter, I see a new letter
> on the screen, but it is not the Russian letter. It is ISO-8859-1 letter
> corresponding to the first byte of the unicode value.
> 
> I guess CVS tuxpaint should break ISO-8859-1 (non-ascii) users as well, 
> but I hope it is a step into the right direction :-)
>