tuxpaint-devel — General discussion list for Tux Paint developers

[Tuxpaint-devel] Handwriting-to-text magic tool [GSOC]

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

So the code is pretty rough, the methods in which things work need to be
improved (no temp file, no popen() a binary... roll everything into the
magic tool and do things in RAM), _but_... I've finally gotten
Namrata's magic tool to work on my system.

(Of course, no Namrata is having trouble building a fresh version of
lipitk, which the tool depends on.  Sigh!)

Here's a screenshot:

  http://www.newbreedsoftware.com/bill/news/images/drawText.png

(Yes, I realize the font is blurry :) )

-- 
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today!  http://www.tuxpaint.org/

Re: [Tuxpaint-devel] Paint tool: Single clicks do nothing

[Pere P. i C. <pe...@fo...>]

El dj 14 de 08 de 2008 a les 08:03 -0700, en/na Bill Kendrick va
escriure:
> On Thu, Aug 14, 2008 at 02:41:44PM +0200, Pere Pujal i Carabantes wrote:
> > Hi all!
> > 
> > Start tuxpaint, in paint tool, do several single clicks withouth
> > dragging the mouse:
> > nothing is drawed.
> 
> Oh dear.  Thanks for catching that.  I've applied your patch, and it seems
> good.  It might be even better if we only behaved like this for the
> directional brushes, but I think it's okay as it is, for now.

This draws on click for non directional brushes only, on both paint and
line tools
 diff tuxpaint.c.back tuxpaint/src/tuxpaint.c
3300,3301c3300,3303
< 
<           /* brush_draw(old_x, old_y, old_x, old_y, 1); fixes SF
#1934883? */
---
>           if (! brushes_directional[cur_brush])
>           {
>             brush_draw(old_x, old_y, old_x, old_y, 1); /*fixes SF
#1934883? */
>           }
3332,3334c3334,3337
< 
<           /* brush_draw(old_x, old_y, old_x, old_y, 1); fixes sf
#1934883? */
< 
---
>           if(! brushes_directional[cur_brush])
>           {
>             brush_draw(old_x, old_y, old_x, old_y, 1); /*fixes sf
#1934883? */
>           }

Yours
Pere

Re: [Tuxpaint-devel] Paint tool: Single clicks do nothing

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

On Thu, Aug 14, 2008 at 02:41:44PM +0200, Pere Pujal i Carabantes wrote:
> Hi all!
> 
> Start tuxpaint, in paint tool, do several single clicks withouth
> dragging the mouse:
> nothing is drawed.

Oh dear.  Thanks for catching that.  I've applied your patch, and it seems
good.  It might be even better if we only behaved like this for the
directional brushes, but I think it's okay as it is, for now.

Another idea would be (when drawing with a directional brush):
draw the middle shape on click.  If they then drag, undraw it, and draw
the appropriate one.  Otherwise, if they simply release, they'll get the
middle image.

Anyway, thx!

-bill!

[Tuxpaint-devel] Paint tool: Single clicks do nothing

[Pere P. i C. <pe...@fo...>]

Hi all!

Start tuxpaint, in paint tool, do several single clicks withouth
dragging the mouse:
nothing is drawed.

Change to line tool, see how single clicks draws and works fine.

Then look closer: do a click withouth drag and whitout release, see how
nothing is drawed until you release the mouse.

This happens as a side issue of the fix of #1934883 bug.
In tuxpaint.c, search for the string "fixes SF #1934883?" (you will find
two times, one for draw and one for line tools)

I think that the line tool is fine drawing at mouse release as a good
compromise between #1934883 and the single click issue of paint tool.

This patch adds draw on release to the paint tool:

diff tuxpaint.c.back tuxpaint/src/tuxpaint.c
3669c3669,3674
<         if (cur_tool == TOOL_LINES)
---
>         if (cur_tool == TOOL_BRUSH)
>         {
>           /* (Drawing on mouse release to fix single click issue) */
>           brush_draw(old_x, old_y, old_x, old_y, 1);
>         }
>         else if (cur_tool == TOOL_LINES)



A sumary of #1934883 bug: Directional brushes gets its first draw always
to up, disregarding the direction where they go further. Happened on
draw and on line tools.

OK to commit?
Pere

Re: [Tuxpaint-devel] Magic tool reports no tools (foo-script)

[foo-script <foo...@o2...>]

After those steps it works fine. Thx :)

Adam


Dnia 6 sierpnia 2008 18:24 "Andrew Corcoran" <aka...@gm...> napisał(a):

> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 

Re: [Tuxpaint-devel] Magic tool reports no tools (foo-script)

[Andrew C. <aka...@gm...>]

I'm unable to reproduce this, I've downloaded a fresh copy from the CVS done
a clean uninstall/install and then run tuxpaint with the --nosound option
but everythign worked perfectly.

Can you please try doing the following for me.

make clean

sudo make uninstall

cvs update

make

sudo make install

tuxpaint

tuxpaint --nosound

and tell me if you get the same problem with either the tuxpaint or the
tuxpaint --nosound commands. If you do could you give me a copy of the
mosaic_init() and tint_init() functions that you have on your machine. My
first impression is that for some reason your local copy isnt up to date
with the cvs as this was an issue that was happening with earlier version of
my tools and which I recently removed all the offending code. It seems very
unusual that the exact same error would occur again when all the code has
been removed.

Cheers,

Andrew



>

Re: [Tuxpaint-devel] Magic tool reports no tools (foo-script)

[foo-script <foo...@o2...>]

Nope. I use the newest cvs version :)
I mentioned about that warnings cause I wasn't sure do you know about them.

Best,
Adam


Dnia 5 sierpnia 2008 21:03 "Andrew Corcoran" <aka...@gm...> napisał(a):

> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> 

Re: [Tuxpaint-devel] Magic tool reports no tools (foo-script)

[Andrew C. <aka...@gm...>]

This is an issue with users who have no sound support, or run with sound
disabled. I uploaded a fix to the cvs two days ago, is this error still
occuring or are you using an old copy of the cvs?



On Tue, Aug 5, 2008 at 8:00 PM, <
tux...@li...> wrote:

> Send Tuxpaint-devel mailing list submissions to
>        tux...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> or, via email, send a message with subject or body 'help' to
>        tux...@li...
>
> You can reach the person managing the list at
>        tux...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tuxpaint-devel digest..."
>
>
> Today's Topics:
>
>   1. Magic tool reports no tools (foo-script)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Tue, 05 Aug 2008 00:00:59 +0200
> From: foo-script <foo...@o2...>
> Subject: [Tuxpaint-devel] Magic tool reports no tools
> To: tux...@li...
> Message-ID: <23d...@o2...>
> Content-Type: text/plain; charset="UTF-8"
>
> When lauching tuxpaint:
>
> Error: plugin /usr/local/lib/tuxpaint/plugins/mosaic.so failed to startup
> or reported 0 magic tools
> Error: plugin /usr/local/lib/tuxpaint/plugins/tint.so failed to startup or
> reported 0 magic tools
> Error: plugin /usr/local/lib/tuxpaint/plugins/rain.so failed to startup or
> reported 0 magic tools
> Error: plugin /usr/local/lib/tuxpaint/plugins/blur.so failed to startup or
> reported 0 magic tools
> Error: plugin /usr/local/lib/tuxpaint/plugins/sharpen.so failed to startup
> or reported 0 magic tools
> Error: plugin /usr/local/lib/tuxpaint/plugins/noise.so failed to startup or
> reported 0 magic tools
> Error: plugin /usr/local/lib/tuxpaint/plugins/alien.so failed to startup or
> reported 0 magic tools
> Error: plugin /usr/local/lib/tuxpaint/plugins/snow.so failed to startup or
> reported 0 magic tools
>
> Best,
> Adam
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
> ------------------------------
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>
>
> End of Tuxpaint-devel Digest, Vol 27, Issue 4
> *********************************************
>

[Tuxpaint-devel] Magic tool reports no tools

[foo-script <foo...@o2...>]

When lauching tuxpaint:

Error: plugin /usr/local/lib/tuxpaint/plugins/mosaic.so failed to startup or reported 0 magic tools
Error: plugin /usr/local/lib/tuxpaint/plugins/tint.so failed to startup or reported 0 magic tools
Error: plugin /usr/local/lib/tuxpaint/plugins/rain.so failed to startup or reported 0 magic tools
Error: plugin /usr/local/lib/tuxpaint/plugins/blur.so failed to startup or reported 0 magic tools
Error: plugin /usr/local/lib/tuxpaint/plugins/sharpen.so failed to startup or reported 0 magic tools
Error: plugin /usr/local/lib/tuxpaint/plugins/noise.so failed to startup or reported 0 magic tools
Error: plugin /usr/local/lib/tuxpaint/plugins/alien.so failed to startup or reported 0 magic tools
Error: plugin /usr/local/lib/tuxpaint/plugins/snow.so failed to startup or reported 0 magic tools

Best,
Adam

Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs

[Andrew C. <aka...@gm...>]

I've gone through mosaic.c and made a rewrite. I've removed all code from
switchin() and instead the cpu intensive code is only called when needed.
Unfortunatly this means that its impossible for the brush mode to work
without extremly high cpu usage and ive therefore set mosaic to be a
fullscreen mode only tool. Hopefully the cpu load when using fullscreen is
small enough not to cause significant annoyance.

Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs

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

On Sat, Aug 02, 2008 at 08:57:53AM +0200, Pere Pujal i Carabantes wrote:
> After the initialization, mosaic runs fine without loading my computer,
> what seems extrange from my user point of view is the extra load when
> clicking on a empty buttom or by changing between modes.

Ah, because all of Mosaic's work happens at switchin(), it seems.  Hrm. :^(
(It applies the filter to the entire image, then copies what's needed when
you click-and-drag.)

The fact that switchin/switchout get called on emtpy slots in the toolbar
is a bug, though...

-- 
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today!  http://www.tuxpaint.org/

Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs

[Andrew C. <aka...@gm...>]

As Bill says the tool itself is very a very cpu intensive task. The reason
all this work is done when the tool is loaded is so that the program doesnt
task the cpu / freeze while the user is drawing in brush mode as that would
make it very hard to use the tool. It would be possible to code so that
switching to full screen mode doesn't cause this but I'm afraid that a
difficult choice still remains with the brush effect (have the cpu tasked on
load or when drawing).

As to whether the tool is actually useful or not, well I think I might be a
bit biased and I'm probably not the right person to decide that, however I
think its very hard to have a valid opinion if you havn't even tried the
tool yourself.

Regards,

Andrew

On Sat, Aug 2, 2008 at 8:06 PM, <
tux...@li...> wrote:

> Send Tuxpaint-devel mailing list submissions to
>        tux...@li...
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
> or, via email, send a message with subject or body 'help' to
>        tux...@li...
>
> You can reach the person managing the list at
>        tux...@li...
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Tuxpaint-devel digest..."
>
>
> Today's Topics:
>
>   1. Some testing on current tuxpaint cvs (Pere Pujal i Carabantes)
>   2. Re: Some testing on current tuxpaint cvs (Bill Kendrick)
>   3. Re: Some testing on current tuxpaint cvs (Albert Cahalan)
>   4. Re: Some testing on current tuxpaint cvs (Pere Pujal i Carabantes)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Sat, 02 Aug 2008 01:44:20 +0200
> From: Pere Pujal i Carabantes <pe...@fo...>
> Subject: [Tuxpaint-devel] Some testing on current tuxpaint cvs
> To: Discussion list for Tux Paint developers
>        <tux...@li...>
> Message-ID: <121...@ho...>
> Content-Type: text/plain
>
> Hi all!
>
> I have a strange issue with magic mosaic, it loads cpu when selecting it
>
> To reproduce:
> start tuxpaint on window mode at least at 800x600, but is better seen at
> higher sizes, start top on a xterm or similar, keep both visible.
> go to magic, clic on mosaic and see how cpu loads and after normalizes.
> The progress bar is also shown.
>
> Without quitting mosaic type several times CTRL+Z or clic on the greyed
> Undo button or in a empty button below the "Quit" one, or change several
> times between draw mode and screen mode.
> see how cpu loads newly after each click and how the progress bar is
> shown on each clic.
>
> Instead, if you clic several times on the mosaic icon, cpu do not gets
> extra loads, and the progress bar don't appears.
>
>
>
> This two had worked for years, but now:
> Caligraphy doesn't work for me, I am unable to write anything, I don't
> even hear the sound(if any)
>
> Shift doesn't work for me, I hear the sounds as I drag the stylus(*),
> but nothing moves.
> (*) A wacom tablet that had working with tuxpaint for years.
>
>
> Rails: I can join a T or a +, instead, I am unable to join a L (a
> corner)
>
>
> Untranslated things:
> Rain and associated comments don't appears on po files.
>
>
>
>
> Hope this helps
> Yours
> Pere
>
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 1 Aug 2008 17:34:29 -0700
> From: Bill Kendrick <nb...@so...>
> Subject: Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs
> To: Discussion list for Tux Paint developers
>        <tux...@li...>
> Message-ID: <200...@so...>
> Content-Type: text/plain; charset=us-ascii
>
> On Sat, Aug 02, 2008 at 01:44:20AM +0200, Pere Pujal i Carabantes wrote:
> > To reproduce:
> > start tuxpaint on window mode at least at 800x600, but is better seen at
> > higher sizes, start top on a xterm or similar, keep both visible.
> > go to magic, clic on mosaic and see how cpu loads and after normalizes.
> > The progress bar is also shown.
>
> Mosaic is a very CPU-heavy task.  Unless Andrew can rewrite it to run
> more sensibly, it will likely be disabled in the next release. (Sorry! :) )
>
>
> <snip>
> > This two had worked for years, but now:
> > Caligraphy doesn't work for me, I am unable to write anything, I don't
> > even hear the sound(if any)
> >
> > Shift doesn't work for me, I hear the sounds as I drag the stylus(*),
> > but nothing moves.
> > (*) A wacom tablet that had working with tuxpaint for years.
>
> Oops - these two were reporting the wrong mode (fullscreen (click) rather
> than paint (click-drag-release)).  Thanks for pointing it out.
> Fixed!
>
>
> > Rails: I can join a T or a +, instead, I am unable to join a L (a
> > corner)
>
> I haven't looked at the Rails code very closely.  I think it should
> support click-and-drag.  As it is, clicking and dragging ends up
> acting like dozens or 100s of clicks in the same cell, which looks and
> acts poorly, in my opinion.
>
>
> > Untranslated things:
> > Rain and associated comments don't appears on po files.
>
> Ah, I figured it out, rain.c wasn't added to POTFILES.in.  Fixing now.
>
> Thx Pere!
>
> --
> -bill!
> "Tux Paint" - free children's drawing software for Windows / Mac OS X /
> Linux!
> Download it today!  http://www.tuxpaint.org/
>
>
>
> ------------------------------
>
> Message: 3
> Date: Fri, 1 Aug 2008 20:55:34 -0400
> From: "Albert Cahalan" <aca...@gm...>
> Subject: Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs
> To: "Discussion list for Tux Paint developers"
>        <tux...@li...>
> Message-ID:
>        <787...@ma...>
> Content-Type: text/plain; charset=ISO-8859-1
>
> On Fri, Aug 1, 2008 at 8:34 PM, Bill Kendrick <nb...@so...> wrote:
> > On Sat, Aug 02, 2008 at 01:44:20AM +0200, Pere Pujal i Carabantes wrote:
> >> To reproduce:
> >> start tuxpaint on window mode at least at 800x600, but is better seen at
> >> higher sizes, start top on a xterm or similar, keep both visible.
> >> go to magic, clic on mosaic and see how cpu loads and after normalizes.
> >> The progress bar is also shown.
> >
> > Mosaic is a very CPU-heavy task.  Unless Andrew can rewrite it to run
> > more sensibly, it will likely be disabled in the next release. (Sorry! :)
> )
>
> I'm not sure it's a good tool anyway. IMHO,
>
> * art tools are good
> * image mangling tools are bad
> * completely unrelated tools are bad
>
> AFAIK, not having seen it yet, it falls into that second
> catagory. It mangles the images. The point being...?
>
> If a tool has a global effect, that is a BIG hint that the
> tool is not all that useful for art. Probably it should go.
>
> Let's keep the focus on art. Some of the recent ideas
> are really straying from that, to the detriment of a good
> experience creating art.
>
>
>
> ------------------------------
>
> Message: 4
> Date: Sat, 02 Aug 2008 08:57:53 +0200
> From: Pere Pujal i Carabantes <pe...@fo...>
> Subject: Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs
> To: Discussion list for Tux Paint developers
>        <tux...@li...>
> Message-ID: <121...@ho...>
> Content-Type: text/plain
>
> El dv 01 de 08 de 2008 a les 17:34 -0700, en/na Bill Kendrick va
> escriure:
> > On Sat, Aug 02, 2008 at 01:44:20AM +0200, Pere Pujal i Carabantes wrote:
> > > To reproduce:
> > > start tuxpaint on window mode at least at 800x600, but is better seen
> at
> > > higher sizes, start top on a xterm or similar, keep both visible.
> > > go to magic, clic on mosaic and see how cpu loads and after normalizes.
> > > The progress bar is also shown.
> >
> > Mosaic is a very CPU-heavy task.  Unless Andrew can rewrite it to run
> > more sensibly, it will likely be disabled in the next release. (Sorry! :)
> )
> >
>
> After the initialization, mosaic runs fine without loading my computer,
> what seems extrange from my user point of view is the extra load when
> clicking on a empty buttom or by changing between modes.
>
> Yours
> Pere
>
>
>
>
>
>
> ------------------------------
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge
> Build the coolest Linux based applications with Moblin SDK & win great
> prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
>
> ------------------------------
>
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>
>
> End of Tuxpaint-devel Digest, Vol 27, Issue 1
> *********************************************
>

Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs

[Pere P. i C. <pe...@fo...>]

El dv 01 de 08 de 2008 a les 17:34 -0700, en/na Bill Kendrick va
escriure:
> On Sat, Aug 02, 2008 at 01:44:20AM +0200, Pere Pujal i Carabantes wrote:
> > To reproduce:
> > start tuxpaint on window mode at least at 800x600, but is better seen at
> > higher sizes, start top on a xterm or similar, keep both visible.
> > go to magic, clic on mosaic and see how cpu loads and after normalizes.
> > The progress bar is also shown.
> 
> Mosaic is a very CPU-heavy task.  Unless Andrew can rewrite it to run
> more sensibly, it will likely be disabled in the next release. (Sorry! :) )
> 

After the initialization, mosaic runs fine without loading my computer,
what seems extrange from my user point of view is the extra load when
clicking on a empty buttom or by changing between modes.

Yours
Pere

Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs

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

On Fri, Aug 1, 2008 at 8:34 PM, Bill Kendrick <nb...@so...> wrote:
> On Sat, Aug 02, 2008 at 01:44:20AM +0200, Pere Pujal i Carabantes wrote:
>> To reproduce:
>> start tuxpaint on window mode at least at 800x600, but is better seen at
>> higher sizes, start top on a xterm or similar, keep both visible.
>> go to magic, clic on mosaic and see how cpu loads and after normalizes.
>> The progress bar is also shown.
>
> Mosaic is a very CPU-heavy task.  Unless Andrew can rewrite it to run
> more sensibly, it will likely be disabled in the next release. (Sorry! :) )

I'm not sure it's a good tool anyway. IMHO,

* art tools are good
* image mangling tools are bad
* completely unrelated tools are bad

AFAIK, not having seen it yet, it falls into that second
catagory. It mangles the images. The point being...?

If a tool has a global effect, that is a BIG hint that the
tool is not all that useful for art. Probably it should go.

Let's keep the focus on art. Some of the recent ideas
are really straying from that, to the detriment of a good
experience creating art.

Re: [Tuxpaint-devel] Some testing on current tuxpaint cvs

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

On Sat, Aug 02, 2008 at 01:44:20AM +0200, Pere Pujal i Carabantes wrote:
> To reproduce:
> start tuxpaint on window mode at least at 800x600, but is better seen at
> higher sizes, start top on a xterm or similar, keep both visible.
> go to magic, clic on mosaic and see how cpu loads and after normalizes.
> The progress bar is also shown.

Mosaic is a very CPU-heavy task.  Unless Andrew can rewrite it to run
more sensibly, it will likely be disabled in the next release. (Sorry! :) )


<snip>
> This two had worked for years, but now:
> Caligraphy doesn't work for me, I am unable to write anything, I don't
> even hear the sound(if any) 
> 
> Shift doesn't work for me, I hear the sounds as I drag the stylus(*),
> but nothing moves.
> (*) A wacom tablet that had working with tuxpaint for years.

Oops - these two were reporting the wrong mode (fullscreen (click) rather
than paint (click-drag-release)).  Thanks for pointing it out.
Fixed!


> Rails: I can join a T or a +, instead, I am unable to join a L (a
> corner)

I haven't looked at the Rails code very closely.  I think it should
support click-and-drag.  As it is, clicking and dragging ends up
acting like dozens or 100s of clicks in the same cell, which looks and
acts poorly, in my opinion.


> Untranslated things:
> Rain and associated comments don't appears on po files.

Ah, I figured it out, rain.c wasn't added to POTFILES.in.  Fixing now.

Thx Pere!

-- 
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today!  http://www.tuxpaint.org/

[Tuxpaint-devel] Some testing on current tuxpaint cvs

[Pere P. i C. <pe...@fo...>]

Hi all!

I have a strange issue with magic mosaic, it loads cpu when selecting it

To reproduce:
start tuxpaint on window mode at least at 800x600, but is better seen at
higher sizes, start top on a xterm or similar, keep both visible.
go to magic, clic on mosaic and see how cpu loads and after normalizes.
The progress bar is also shown.

Without quitting mosaic type several times CTRL+Z or clic on the greyed
Undo button or in a empty button below the "Quit" one, or change several
times between draw mode and screen mode.
see how cpu loads newly after each click and how the progress bar is
shown on each clic.

Instead, if you clic several times on the mosaic icon, cpu do not gets
extra loads, and the progress bar don't appears.



This two had worked for years, but now:
Caligraphy doesn't work for me, I am unable to write anything, I don't
even hear the sound(if any) 

Shift doesn't work for me, I hear the sounds as I drag the stylus(*),
but nothing moves.
(*) A wacom tablet that had working with tuxpaint for years.


Rails: I can join a T or a +, instead, I am unable to join a L (a
corner)


Untranslated things:
Rain and associated comments don't appears on po files.




Hope this helps
Yours
Pere

Re: [Tuxpaint-devel] Rails plugin release

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

Hi Adam - I haven't seen any updates from you recently.  :(
(I did get the private email about translating things, but that's
not really related to GSOC :) )

What have you been working on?

Thx,

-bill!

On Sun, Jul 13, 2008 at 09:55:14PM +0200, foo-script wrote:
> Due to Pere Pujal i Carabantes idea I created "Rails" plugin.
> 
> Available at: http://szn.republika.pl/tuxpaint-magic-rails.tar.gz
> 
> Comments, ideas, bugs(?) are invited.
> 
> Enjoy! :)
> 
> 
> Best,
> Adam
> 
> -------------------------------------------------------------------------
> Sponsored by: SourceForge.net Community Choice Awards: VOTE NOW!
> Studies have shown that voting for your favorite open source project,
> along with a healthy diet, reduces your potential for chronic lameness
> and boredom. Vote Now at http://www.sourceforge.net/community/cca08
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

-- 
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today!  http://www.tuxpaint.org/

[Tuxpaint-devel] Mix_LoadWAV() and --nosound

[Andrew C. <aka...@gm...>]

I've come across an issue with developing magic tools using the
Mix_LoadWAV() function when  --nosound is enabled or when the users hardware
does not support sound.

First off I'd like to say that the whole problem is a result of checking to
make sure that Mix_LoadWAV() returns a valid value. If (as all the
previoustools do) no error checking is performed then this issue does not
occur. But to me that seem's like an inelegant solution. I'd also like to
point out that there is already code to make sure that no sound is played
under any condition if --nosound is enabled or tuxpaint is muted.

Mix_LoadWAV() is used by magic tools to load any sounds they wish to use. It
is a direct call to the SDL API and therin lies the issue. If sound is
disabled or unavailble then tuxpaint.c does not intialise the SDL Sound API
and therefor all calls to Mix_LoadWAV() fail and return an error condition.
If (as my tools do) the return condition of Mix_LoadWAV() is checked to make
sure that the sound file is loaded then it appears to the magic tool that
the sound file does not exist.

My suggested solution (below) is to make all magic tools call a tuxpaint api
function to load sounds rather than having them making direct calls to SDL
(it seems unusual that they dont do this already, considering the playsound
function is already used in this way). This function would act as a wrapper
for the SDL Mix_LoadWAV() function but would only return an error when sound
is enabled and the file doesnt exist. Since the tuxpaint playsound function
checks to see if sound is enabled before attempting to play a sound this
should cause no issues in the main tuxpaint code.

The only issue I can see with this solution is that it would probably be
best to update all current tools to use the new function (the old function
will still work, it would just be bad practice to use) so that new
developers dont inadvertandly copy old code.

I believe that is probably a better solution than focing the plugin
developer to ignore error checking and I wanted to check if anyone has any
comments or ideas on a better way of implementing a solution before I
started looking into adding this feature.

Regards,

Andew

//My suggested wrapper function

//Returns a pointer to a loaded sound file if sound is enabled, returns NULL
on error or -1 if sound is disabled

//magic_playsound can still be called if this fucntion returns -1 as
magic_playsound has inbuilt checking for disabled sound
Mix_Chunk * magic_loadsound(char* file){
  if (!use_sound){
  //If sound is diabled return a dummy value
  return (Mix_Chunk*)-1;
  }
  //Mix_LoadWAV returns NULL if the file doesnt exist so we can just pass on
the return value
  Mix_Chunk * temp = Mix_LoadWAV(file);
  return temp;
}

//Below is the already existing playsound function

void magic_playsound(Mix_Chunk * snd, int left_right, int up_down)
{
#ifndef NOSOUND

  int left, dist;


  // Don't play if sound is disabled (nosound), or sound is temporarily
  // muted (Alt+S), or sound ptr is NULL

  if (mute || !use_sound || snd == NULL)
  return;

**SNIP

.......

**SNIP
#endif
}

Re: [Tuxpaint-devel] Rendering of text when saving

[Pedersen, T. A. <tor...@he...>]

Hi again! Here are some changes, I have more in mind, but not finished yet :)

About the cursor changes in mouse motion event, there should have been a cur_cursor to see if any changes of cursor is needed before it is changed. I don't know if it would be best to have some integer value for each cursor for the test of this. In that case, the integers used for TOOL_* could be reused as cursor for hit in canvas, so 
if (cur_cursor != cur_tool) do_setcursor(cur_tool) would cover a lot of cases.

Also some places the cursor could  be set inside an already existing test for cur_tool instead of in its own test. I'll have another look at this later.

the diff looks like below.

Yours sincerely
Tor Arne Pedersen

2380c2380
<       {
---
>        {
2398,2401c2398
< 	    if (cur_tool == TOOL_TEXT && which != TOOL_TEXT &&
<                 which != TOOL_NEW && which != TOOL_OPEN &&
<                 which != TOOL_SAVE && which != TOOL_PRINT &&
<                 which != TOOL_QUIT)
---
> 	    if (cur_tool == TOOL_TEXT)
2423,2425d2419
< 	    // FIXME: this "if" is just plain gross
< 	    if (cur_tool != TOOL_TEXT)
< 	      draw_tux_text(tool_tux[cur_tool], tool_tips[cur_tool], 1);
2493c2487
< 	      draw_tux_text(tool_tux[cur_tool], tool_tips[cur_tool], 1);
---
> 
2575,2580c2569
< 
< 	      if (do_open() == 0)
<               {
<                 if (old_tool == TOOL_TEXT)
< 	          do_render_cur_text(0);
<               }
---
> 	      do_open(); 
2583d2571
< 
2587d2574
< 
2589d2575
< 
2598,2599d2583
< 	      else if (cur_tool == TOOL_TEXT)
< 		draw_fonts();
2628,2629d2611
<                 cur_tool = old_tool;
< 
2631,2633d2612
<           
<                 if (cur_tool == TOOL_TEXT)
<                   do_render_cur_text(0);
2637d2615
< 
2639d2616
< 
2659,2666d2635
<               /* If they haven't hit [Enter], but clicked 'Print', add their text now -bjk 2007.10.25 */
<               if (old_tool == TOOL_TEXT && texttool_len > 0)
<               {
<                 rec_undo_buffer();
<                 do_render_cur_text(1);
<                 texttool_len = 0;
<                 cursor_textwidth = 0;
<               }
2682a2652
>             draw_tux_text(tool_tux[cur_tool], tool_tips[cur_tool], 1);


-----Opprinnelig melding-----
Fra: tux...@li... på vegne av Bill Kendrick
Sendt: on 23.07.2008 22:37
Til: Discussion list for Tux Paint developers
Emne: Re: [Tuxpaint-devel] Rendering of text  when saving
 

Hi Tor, thanks.  Yeah, that's a bug.  Feel free to post the changes
you made, or point me to the particular line of code, if you can.

I fixed this for Print, since a lot of students were having
problems in classes, but obviously didn't do Save. :^/

As for switch/case, I personally never liked those, and never got into using
them.


On Wed, Jul 23, 2008 at 08:06:51PM +0200, Pedersen, Tor Arne wrote:
>    Hello,
>    Thanks for a great application for my children. I would love to help out
>    with this project if any more hands are needed.
> 
>    I had an issue with the text not being rendered when save was hit, so I
>    read the code and found that this was done intentionally by doing a if
>    cur_tool != lots-of-tools {render current text}. Also a few lines down,
>    some text are rendered anyway. Why this behaviour? I changed it in my
>    local copy of the code to render the text if any tools were clicked. Even
>    hitting Text-tool again should render the current text, in my opinion.
> 
>    While I looked for the solution of the issue described above, I found some
>    lines marked fix-me, and I also found a couple of places that should have
>    had a fix-me-marking :) Some of this I can fix. Can I just do it, and
>    where should I post suggested changes?
> 
>    I was also wondering if it would be better to swap some if-elses with
>    switch cases, especially for those with 6-7 or even 12 tests.
> 
>    Yours,
>    Tor Arne Pedersen

-bill!

-------------------------------------------------------------------------
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
_______________________________________________
Tuxpaint-devel mailing list
Tux...@li...
https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] Rendering of text when saving

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

Hi Tor, thanks.  Yeah, that's a bug.  Feel free to post the changes
you made, or point me to the particular line of code, if you can.

I fixed this for Print, since a lot of students were having
problems in classes, but obviously didn't do Save. :^/

As for switch/case, I personally never liked those, and never got into using
them.


On Wed, Jul 23, 2008 at 08:06:51PM +0200, Pedersen, Tor Arne wrote:
>    Hello,
>    Thanks for a great application for my children. I would love to help out
>    with this project if any more hands are needed.
> 
>    I had an issue with the text not being rendered when save was hit, so I
>    read the code and found that this was done intentionally by doing a if
>    cur_tool != lots-of-tools {render current text}. Also a few lines down,
>    some text are rendered anyway. Why this behaviour? I changed it in my
>    local copy of the code to render the text if any tools were clicked. Even
>    hitting Text-tool again should render the current text, in my opinion.
> 
>    While I looked for the solution of the issue described above, I found some
>    lines marked fix-me, and I also found a couple of places that should have
>    had a fix-me-marking :) Some of this I can fix. Can I just do it, and
>    where should I post suggested changes?
> 
>    I was also wondering if it would be better to swap some if-elses with
>    switch cases, especially for those with 6-7 or even 12 tests.
> 
>    Yours,
>    Tor Arne Pedersen

-bill!

[Tuxpaint-devel] Rendering of text when saving

[Pedersen, T. A. <tor...@he...>]

Hello,
Thanks for a great application for my children. I would love to help out with this project if any more hands are needed.

I had an issue with the text not being rendered when save was hit, so I read the code and found that this was done intentionally by doing a if cur_tool != lots-of-tools {render current text}. Also a few lines down, some text are rendered anyway. Why this behaviour? I changed it in my local copy of the code to render the text if any tools were clicked. Even hitting Text-tool again should render the current text, in my opinion.

While I looked for the solution of the issue described above, I found some lines marked fix-me, and I also found a couple of places that should have had a fix-me-marking :) Some of this I can fix. Can I just do it, and where should I post suggested changes?

I was also wondering if it would be better to swap some if-elses with switch cases, especially for those with 6-7 or even 12 tests.

Yours, 
Tor Arne Pedersen

Re: [Tuxpaint-devel] [SDL] Tux Paint build for Mac OS X 10.2.8 ?

[Martin F. <mf...@gm...>]

Thanks for the suggestion.  It's been a while ago since my last  
attempt at an OS X 10.2.8 build, so I really can't recall how I  
compiled the dependencies, but it gives me something to focus on if I  
give it another go.  I suppose all the libraries need to be compiled  
with gcc 3.3.

Martin

On 19-Jul-08, at 3:55 PM, Gregory Smith wrote:

> On Jul 19, 2008, at 1:48 AM, Bill Kendrick wrote:
>
>> Thanks Gregory.  Here's something that Martin Fuhrer, who currently
>> maintains Tux Paint for OS X, pointed out in response to this thread
>> over on the tuxpaint-devel mailing list:
>>
>>  Yes, installing XCode 2.5 and the OS X 10.2.8 SDK on Leopard
>> should be
>>  no problem.  The actual problem lies elsewhere: when I twice
>> tried to
>>  build Tux Paint for OS X 10.2.8 a few years ago, using XCode 2.x and
>>  the OS X 10.2.8 SDK, I always ran into strange link errors due to
>>  duplicate symbols in the OS X 10.2.8 libraries and elsewhere in the
>>  Tux Paint dependencies (libintl I think, but my memory is hazy...).
>>  In the end I gave up in frustration.  I can always give it another
>>  try, but I'm not convinced that the duplicate symbols will have put
>>  aside their differences and made friends in these intervening
>> years ;)
>
> It sounds like one of the dependencies was built with the wrong gcc,
> or against the wrong SDK. Should be easy to fix, just check the
> settings for that library and rebuild.
>
> Gregory
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel

Re: [Tuxpaint-devel] [SDL] Tux Paint build for Mac OS X 10.2.8 ?

[Gregory S. <wo...@tr...>]

On Jul 19, 2008, at 1:48 AM, Bill Kendrick wrote:

> Thanks Gregory.  Here's something that Martin Fuhrer, who currently
> maintains Tux Paint for OS X, pointed out in response to this thread
> over on the tuxpaint-devel mailing list:
>
>   Yes, installing XCode 2.5 and the OS X 10.2.8 SDK on Leopard  
> should be
>   no problem.  The actual problem lies elsewhere: when I twice  
> tried to
>   build Tux Paint for OS X 10.2.8 a few years ago, using XCode 2.x and
>   the OS X 10.2.8 SDK, I always ran into strange link errors due to
>   duplicate symbols in the OS X 10.2.8 libraries and elsewhere in the
>   Tux Paint dependencies (libintl I think, but my memory is hazy...).
>   In the end I gave up in frustration.  I can always give it another
>   try, but I'm not convinced that the duplicate symbols will have put
>   aside their differences and made friends in these intervening  
> years ;)

It sounds like one of the dependencies was built with the wrong gcc,  
or against the wrong SDK. Should be easy to fix, just check the  
settings for that library and rebuild.

Gregory

Re: [Tuxpaint-devel] [SDL] Tux Paint build for Mac OS X 10.2.8 ?

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

On Sat, Jul 19, 2008 at 12:24:49AM -0400, Gregory Smith wrote:
> On Jul 18, 2008, at 6:00 PM, René Dudfield wrote:
> 
> >I guess tiger can also build for 10.2.8?
> 
> It sure can
> 
> >pygame.org would also be interested in knowing how to build for 10.2.8
> >
> >So any tips would be much appreciated :)
> 
> I just followed this guide:
> http://developer.apple.com/documentation/DeveloperTools/Conceptual/ 
> cross_development/
> 
> Take a look at any of the SDL framework projects for examples.
> 
> Gregory

Thanks Gregory.  Here's something that Martin Fuhrer, who currently
maintains Tux Paint for OS X, pointed out in response to this thread
over on the tuxpaint-devel mailing list:

  Yes, installing XCode 2.5 and the OS X 10.2.8 SDK on Leopard should be
  no problem.  The actual problem lies elsewhere: when I twice tried to
  build Tux Paint for OS X 10.2.8 a few years ago, using XCode 2.x and
  the OS X 10.2.8 SDK, I always ran into strange link errors due to
  duplicate symbols in the OS X 10.2.8 libraries and elsewhere in the
  Tux Paint dependencies (libintl I think, but my memory is hazy...).
  In the end I gave up in frustration.  I can always give it another
  try, but I'm not convinced that the duplicate symbols will have put
  aside their differences and made friends in these intervening years ;)

So I guess I was off in my understanding in precisely _what_ the issue
was. :^P

But hey, since we're talking, if anyone wants to try giving Martin a hand
doing this, and navigating the library issues, I'd love the help!

-- 
-bill!
"Tux Paint" - free children's drawing software for Windows / Mac OS X / Linux!
Download it today!  http://www.tuxpaint.org/

Re: [Tuxpaint-devel] [fwd] [SDL] Tux Paint build for Mac OS X 10.2.8 ?

[Martin F. <mf...@gm...>]

Yes, installing XCode 2.5 and the OS X 10.2.8 SDK on Leopard should be  
no problem.  The actual problem lies elsewhere: when I twice tried to  
build Tux Paint for OS X 10.2.8 a few years ago, using XCode 2.x and  
the OS X 10.2.8 SDK, I always ran into strange link errors due to  
duplicate symbols in the OS X 10.2.8 libraries and elsewhere in the  
Tux Paint dependencies (libintl I think, but my memory is hazy...).   
In the end I gave up in frustration.  I can always give it another  
try, but I'm not convinced that the duplicate symbols will have put  
aside their differences and made friends in these intervening years ;)

Martin

On 18-Jul-08, at 9:04 PM, Bill Kendrick wrote:

>
> Well, here's an answer on the SDL mailing list.  Martin, would this
> work with us?
>
> -bill!
>
> ----- Forwarded message from Gregory Smith ------
>
> Xcode 2.5 can be installed in Leopard, and can build for 10.2.8, so  
> if you
> can build for Mac OS X at all, I don't see why you can't build for  
> 10.2.8.
> That's how I build Aleph One.
>
> Gregory
>
> ----- End forwarded message -----
>
> -- 
> -bill!
> "Tux Paint" - free children's drawing software for Windows / Mac OS  
> X / Linux!
> Download it today!  http://www.tuxpaint.org/
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's  
> challenge
> Build the coolest Linux based applications with Moblin SDK & win  
> great prizes
> Grand prize is a trip for two to an Open Source event anywhere in  
> the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel