tuxpaint-devel — General discussion list for Tux Paint developers

[Tuxpaint-devel] Color picker

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

I've added a color picker!

The rightmost button in the color palette now brings up a square with
~50,000+ colors in it.  Click within the square to select the color,
or click 'Back' to abort (and keep the color what it was before).

Let me know what you think. It's in CVS.

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] 7 new Magic tools

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

On Thu, Jul 19, 2007 at 08:34:12PM +0200, Karl Ove Hufthammer wrote:
> 
> This one needs special handling when the selected 
> colour is black (which *is* the default).

I want to brighten it a bit, as well as maybe add a brushed aluminum effect.

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] compiling error paper.h

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

On Mon, Jul 23, 2007 at 04:26:19PM +0200, Ben Egger wrote:
> hi,
> i get a compiling error with version 0.9.17:

Hi Ben - as of v.0.9.17, Tux Paint now depends on 'libpaper'.  If you already
have that package installed, as the error message said, you _also_ need the
'devel' version of the package (which contains the C header file) to be able
to build Tux Paint from source.

What platform are you trying to build TUx Paint on?  Presumably Linux or
some other Unix.  If Linux, what distro?  Is libpaper available?  If not,
perhaps we have it for you (Shin-Ichi packaged it for some Red Hat and
Fedora versions, for example:  http://www.tuxpaint.org/download/linux-rpm/ )

Good luck!


> ...Compiling PostScript print support...
> src/postscript_print.c:51:19: error: paper.h: No such file or directory
> src/postscript_print.c:55:2: error: #error
> "---------------------------------------------------"
> src/postscript_print.c:56:2: error: #error "If you installed libpaper from a
> package, be sure"
> src/postscript_print.c:57:2: error: #error "to get the development package,
> as well!"
> src/postscript_print.c:58:2: error: #error "(e.g., 'libpaper-dev.rpm')"
> src/postscript_print.c:59:2: error: #error
<snip>

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

[Tuxpaint-devel] compiling error paper.h

[Ben E. <egg...@gm...>]

hi,
i get a compiling error with version 0.9.17:

...Compiling PostScript print support...
src/postscript_print.c:51:19: error: paper.h: No such file or directory
src/postscript_print.c:55:2: error: #error
"---------------------------------------------------"
src/postscript_print.c:56:2: error: #error "If you installed libpaper from a
package, be sure"
src/postscript_print.c:57:2: error: #error "to get the development package,
as well!"
src/postscript_print.c:58:2: error: #error "(e.g., 'libpaper-dev.rpm')"
src/postscript_print.c:59:2: error: #error
"---------------------------------------------------"
src/postscript_print.c: In function 'do_ps_save':
src/postscript_print.c:107: warning: implicit declaration of function
'paperinit'
src/postscript_print.c:115: warning: implicit declaration of function
'systempapername'
...

Re: [Tuxpaint-devel] 7 new Magic tools

[Karl O. H. <ka...@hu...>]

Onsdag 11. juli 2007 skreiv Bill Kendrick:
>Fetch 'em from CVS and tell me what you think!
>
>=A0 Metal Paint

This one needs special handling when the selected=20
colour is black (which *is* the default).

=2D-=20
Karl Ove Hufthammer

Re: [Tuxpaint-devel] 7 new Magic tools

[Karl O. H. <ka...@hu...>]

Onsdag 11. juli 2007 skreiv Bill Kendrick:
>=A0 Kalidescope
>=A0 Glass Tile
>=A0 Metal Paint
>=A0 Emboss
>=A0 Foam
>=A0 Flowers
>=A0 Waves
>
>I had a lot of fun making Flowers and Foam. =A0These were all written with=
in
>6hrs during my two 3hr train trips to and from work yesterday. :)

I like the flower one very much. It needs antialiased stems, though.

=2D-=20
Karl Ove Hufthammer

[Tuxpaint-devel] SDL_Pango header problem

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

Hi there!  Thanks for SDL_Pango.  I'm beginning to update my project
"Tux Paint" to use it in favor of SDL_ttf.

Unfortunately, I get linking errors when I #include "SDL_Pango.h"
in multiple files.  (I do so in both 'tuxpaint.c' and 'fonts.c', a C file
full of helper routines.)

  obj/fonts.o:(.rodata+0x0): multiple definition of `_MATRIX_WHITE_BACK'
  obj/tuxpaint.o:(.rodata+0x0): first defined here
  obj/fonts.o:(.data+0x0): multiple definition of `MATRIX_WHITE_BACK'
  obj/tuxpaint.o:(.data+0x0): first defined here
  obj/fonts.o:(.rodata+0x10): multiple definition of `_MATRIX_BLACK_BACK'
  obj/tuxpaint.o:(.rodata+0x10): first defined here
  obj/fonts.o:(.data+0x4): multiple definition of `MATRIX_BLACK_BACK'
  obj/tuxpaint.o:(.data+0x4): first defined here
...etc.

By simply removing the various color matrices in the header, I was able
to get things to link.  I think you could do either this, or declare them
all as 'static'.

Thanks in advance,

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

[Tuxpaint-devel] SDL_Pango for i18n rendering

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

Just committed to CVS:

  Began adding support for using SDL_Pango, a wrapper to Pango,
  a library for layout and rendering of text, with an emphasis on
  internationalization.  (The hope is to improve support for languages
  that SDL_ttf doesn't support well; e.g., Arabic and Telegu.)

  TTF_Font structs and some functions were replaced by a new
  TuxPaint_Font struct and function, which wraps around either TTF_Font
  or SDLPango_Context, depending on whether SDL_Pango is being used.

  Note: STILL NEEDS WORK!


Please poke at it. :)

-bill!

[Tuxpaint-devel] 7 new Magic tools

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

Fetch 'em from CVS and tell me what you think!

  Kalidescope
  Glass Tile
  Metal Paint
  Emboss
  Foam
  Flowers
  Waves

I had a lot of fun making Flowers and Foam.  These were all written within
6hrs during my two 3hr train trips to and from work yesterday. :)

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Tux Paint 'Magic' tools turning into plugin architecture

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

On Sat, Jul 07, 2007 at 10:06:39AM -0700, Mark K. Kim wrote:
> On Wed, Jul 04, 2007 at 12:57:45PM -0700, Bill Kendrick wrote:
> [regarding magic tools plugins]
> > This is the thing I'm concerned about -- portability.
> 
> Libtool creates cross-platform shared libraries.  It's one of the
> Autotools package (Autoconf, Automake, Libtool).

Was just looking into this, due to John P. mentioning it.
I'm not currently using libtool, but am getting this creeping feeling
I should. :)

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Tux Paint 'Magic' tools turning into plugin architecture

[Mark K. K. <mkk...@gm...>]

On Wed, Jul 04, 2007 at 12:57:45PM -0700, Bill Kendrick wrote:
[regarding magic tools plugins]
> This is the thing I'm concerned about -- portability.

Libtool creates cross-platform shared libraries.  It's one of the
Autotools package (Autoconf, Automake, Libtool).

-Mark

[Tuxpaint-devel] Magic tools ported; comments requested

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

Due to an admittedly sad circumstance yesterday, there were some major
train delays in my multi-hour commute home, causing it to take about 6-7hrs.
The good news is, this gave me a long, solid chunk of time alone with
my laptop.

Tux Paint in CVS now has had all Magic tools[*] converted into external
plugins.  Some plugin objects contain multiple tools, but they are simply
exposed within Tux Paint as separate buttons, like they were before.

(e.g., Block, Chalk and Drip were fairly similar, so they're all in the
same '.so' file.)

I've began documenting the API -- it's a bit rough, so I'd love some
comments on it.  (And Albert, if you can think of a way to, alternatively,
build Tux Paint so that these separate Magic plugin C files are compiled
as normal objects and connected to Tux Paint at link time, that'd make
SE Linux users happy, I imagine :^) )

Docs are visible here, in CVS:

  http://tuxpaint.cvs.sourceforge.net/*checkout*/tuxpaint/tuxpaint/magic/docs/html/README.html

And an example plugin is here:

  http://tuxpaint.cvs.sourceforge.net/*checkout*/tuxpaint/tuxpaint/magic/docs/tp_magic_example.c

And the API header file is here:

  http://tuxpaint.cvs.sourceforge.net/*checkout*/tuxpaint/tuxpaint/src/tp_magic_api.h


I've already asked John P. and Martin F. to look into how this all
affects Win32 and OSX builds (I'm guessing low-impact).  As they provide
details on how the plugins can be built on those platforms, I'll update
the API's REAMDE docs.

Thanks in advance!

[*] Except 'Sparkles', which, except for its sound effect, was easily
    replaced with an animated/randomized paint brush.

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Printing problems was glibc detected ... double free or corruption

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

On Mon, 2 Jul 2007 11:11:43 -0700
Bill Kendrick <nb...@so...> wrote:
> Ouch!  So fprintf() is getting localized.  I guess we should
> replace the %.2f's in there with our own (maybe %d.%d and then do
> some int math on the scale and translate values)

Why not write a C macro to wrap the problematic fprintf()s to change
to "C" locale and back again via setlocale?

Ben
--
 ,-.  nSLUG    http://www.nslug.ns.ca   sy...@sa...
 \`'  Debian   http://www.debian.org    sy...@de...
  `          [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
             [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: [Tuxpaint-devel] New release in Debian unstable/sid

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

On Wed, 04 Jul 2007 19:31:19 -0300
Ben Armstrong <sy...@sa...> wrote:

> On Thu, 05 Jul 2007 00:22:40 +0200
> Pere Pujal i Carabantes <pe...@fo...> wrote:
> > Just a question, the print problem i've reported here appears as well in
> > the sid packages. Should I post a bug report?
> 
> add more info to the existing bug# to confirm its presence in 0.9.17.  thanks

Oh!  I see now.  That's a whole new bug.  I was thinking of this one:

http://bugs.debian.org/370721

I will have to check with the submitter if this still happens or not with
0.9.17 once my packages enter "testing".

Ben
--
 ,-.  nSLUG    http://www.nslug.ns.ca   sy...@sa...
 \`'  Debian   http://www.debian.org    sy...@de...
  `          [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
             [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: [Tuxpaint-devel] UK National Curriculum (for 0.9.18 or 1.0)

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

On Thu, Jul 05, 2007 at 12:07:29AM +0100, Caroline Ford wrote:
> I've had a quick look at the approval stuff for ICT support for the UK
> national curriculum. (I'm not a teacher, I'm a former public sector
> worker, but not in education).

Awesome.  When I have more time, I'll look into your email further
and add additional comments.

Anything you see missing, let us know here, and/or post an RFE to
the SourceForge.net project.  (Probably good to mention it's for the ICT
stuff, so that it stands out.)

-bill!

Re: [Tuxpaint-devel] Tux Paint 'Magic' tools turning into plugin architecture

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

On Wed, Jul 04, 2007 at 10:26:43PM +0100, Caroline Ford wrote:
> I think there are other open source plugin standards that it would be
> cool to be compliant with, if we can. KDE has something for Krita etc?
> Does the GIMP?

I'm not sure any of them would be exactly what Tux Paint needs.
Tux Paint's API would be an X,Y location (or pair of, for mouse motion)
which are meant to affect the current canvas.  Most Gimp plugins affect
the current layer or selection, and often require additional user input
(e.g., "you want to blur... how much?   [ 3 ] [OK]" :) )


> I've no idea if it is viable but I love the idea, an opensource
> equivalent of the photoshop plugin.
> 
> BTW have we officially released? Was there a fanfare? ;)

0.9.17 was released on July 1st.  I posted to tuxpaint-news.
Oops, I need to post to tuxpaint-users, too.

So busy on the train on Tues/Thurs, working full time 5 days a week,
and with a baby at home, that I don't get much online time to do the kind
of PR I used to.

I do subscribe to Google's Blog Search for "tuxpaint OR 'tux paint'",
and noticed a lot of software sites and software and personal blogs
mentioning the new release, and hit a few of the standard sites
(freshmeat, linuxgames, etc.)

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] Tux Paint 'Magic' tools turning into plugin architecture

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

On 7/4/07, Bill Kendrick <nb...@so...> wrote:
> On Wed, Jul 04, 2007 at 02:42:31AM -0400, Albert Cahalan wrote:
> > Cleaning up that code is an excellent idea, but the *.so thing
> > doesn't seem so great.
> >
> > The *.so files will slow the start-up time. My rough guess,
> > assuming 2 disk seeks per file and 20 files, is one second.
> > (good ideas to cut startup time would be appreciated)
> > This is also one more thing to go wrong on SE Linux and
> > for portability.
>
> This is the thing I'm concerned about -- portability.

Hey, the other stuff matters too.

It can be surprisingly difficult to make SE Linux happy.
A distribution will of course include the required magic
for the packaged install, but that doesn't help compiling
from source code. (the common killer: text relocations)

Nobody likes start-up time, kid or not.

> One major benefit of making them shared libs is that people can
> create and test new magic tools without needing to download and build
> Tux Paint.  All they'll need is a C compiler and SDL libs, and I guess
> some "libtuxpaint-dev" package for headers and such.
>
> (Similar to 'libgimp2.0-dev' and 'libgimp2.0-docs' for writign GIMP plugins)
>
> Actually, it may even make more sense to sen the Magic tools
> 24bpp or 32bpp data, rather than even usign SDL_Surface and the whole
> getpixel/putpixel mess.

I really can't see this getting used. If somebody really
does want to add stuff, I don't see why they couldn't
just build the whole thing from source. That's probably
even easier to do. Having full source is good anyway.

BTW, designing a stable ABI is really hard. I've never
been able to do it for procps, despite the numerous
requests for general availability of the library.

[Tuxpaint-devel] UK National Curriculum (for 0.9.18 or 1.0)

[Caroline F. <car...@go...>]

I've had a quick look at the approval stuff for ICT support for the UK
national curriculum. (I'm not a teacher, I'm a former public sector
worker, but not in education).

I'm looking at this to see if we need some specific content or
documentation or a something to tap into the UK education software
market. 

http://www.curriculumonline.gov.uk/default.htm

http://www.curriculumonline.gov.uk/SupplierCentre/supplierwelcome.htm is
the guidelines on being a "supplier". Whether we could be a supplier,
whether it would be Tux4Kids, or whether it would be a downstream like
Edubuntu I don't know. 

I don't know who (if anyone) is interested in this but I'm doing to try
and compare tuxpaint to the national curriculum to see if there is
anything we are obviously missing, that could be implemented easily, say
with some extra stamps.

http://www.nc.uk.net/webdav/harmonise?Page/@id=6016

The plan would be both for the website (and we could do this for other
countries with national curricula) and as a plan of action for
additional content.

In UK education jargon we cover key stages 1 & 2. Key stage 1 is 5-7
years old (years 1 to 2), Key stage 2 is 7-11 (years 3-6). We also cover
pre-KS1 but I'm not sure what that's called and how regimented it is..

I think it would be pretty easy to point out how we fit in with this:
http://www.nc.uk.net/webdav/harmonise?Page/@id=6004&Subject/@id=3331
(ICT KS1&2 programme of study).

I'm pretty sure our stuff is considerably better than other programs out
there - I just think that schools don't know about it. The education
software I've seen has been dreadful. What do we do?

Caroline

Re: [Tuxpaint-devel] New release in Debian unstable/sid

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

On Thu, 05 Jul 2007 00:22:40 +0200
Pere Pujal i Carabantes <pe...@fo...> wrote:
> Just a question, the print problem i've reported here appears as well in
> the sid packages. Should I post a bug report?

add more info to the existing bug# to confirm its presence in 0.9.17.  thanks

ben

--
 ,-.  nSLUG    http://www.nslug.ns.ca   sy...@sa...
 \`'  Debian   http://www.debian.org    sy...@de...
  `          [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
             [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: [Tuxpaint-devel] New release in Debian unstable/sid

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

El dc 04 de 07 del 2007 a les 07:53 -0300, en/na Ben Armstrong va
escriure:
> Any sid users out there can now find new releases of tuxpaint, tuxpaint-data,
> tuxpaint-stamps-default and tuxpaint-config at their local Debian mirror.
> 

Thanks!!!

Just a question, the print problem i've reported here appears as well in
the sid packages. Should I post a bug report?

 

Yours
Pere

Re: [Tuxpaint-devel] New release in Debian unstable/sid

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

On Wed, 4 Jul 2007 12:49:48 -0700
Bill Kendrick <nb...@so...> wrote:

> Thanks Ben.

No prob.

> Tell me how I can improve this way-out-of-date page, wouldya? :)
> 
>   http://www.tuxpaint.org/download/linux-debian/

Looks good now.  As soon as the packages.d.o pages are rebuilt they will
reflect that 0.9.17, etc. are already in Debian sid.

Ben
--
 ,-.  nSLUG    http://www.nslug.ns.ca   sy...@sa...
 \`'  Debian   http://www.debian.org    sy...@de...
  `          [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
             [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: [Tuxpaint-devel] New release in Debian unstable/sid

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

On Wed, 4 Jul 2007 12:47:13 -0700
Bill Kendrick <nb...@so...> wrote:
> Stamps were packaged separately upstream (that is, 'source' .tar.gz's, by me)
> back in 0.9.16.
> 
> Shin-Ichi has packaged RPMs as separate groups, but it's up to Ben
> (and the other Deb devs) to decide whether he/they want(s) to go through
> the trouble downstream.

I would do this if my users asked for it.  Nobody has asked.  File a wishlist
bug with as much detail as possible about what you want done and why.

Ben
--
 ,-.  nSLUG    http://www.nslug.ns.ca   sy...@sa...
 \`'  Debian   http://www.debian.org    sy...@de...
  `          [ gpg 395C F3A4 35D3 D247 1387 2D9E 5A94 F3CA 0B27 13C8 ]
             [ pgp 7F DA 09 4B BA 2C 0D E0 1B B1 31 ED C6 A9 39 4F ]

Re: [Tuxpaint-devel] Tux Paint 'Magic' tools turning into plugin architecture

[Caroline F. <car...@go...>]

On Tue, 2007-07-03 at 22:55 -0700, Bill Kendrick wrote:
> I'm putting together a basic (for now) plugin API in Tux Paint 0.9.18
> that will replace the hard-coded Magic tool code in tuxpaint.c.
> 
> A new 'magic' subfolder has been added to the project, with its own Makefile
> and 'images' subfolder full of icons.  I've ported the 'Negative' tool, so far.
> The code uses SDL's "SDL_LoadObject()" function, and friends (found
> prototyped in SDL_loadso.h).  The 'magic' folder generates ".so" files on
> Linux, which are then placed in /usr/[local/]lib/tuxpaint/.
> 
> That directory is scanned by Tux Paint at startup, and any object files it
> can find and open, and query for the proper set of functions, will appear
> as Magic tools in Tux Paint.
> 
> It's all very rough, and somewhat broken, but it was all written while
> in transit on trains today, on my 100mi trek back from work.
> 
> Comments?  (Other than, "you're insane", thank you :) )
> 
I think there are other open source plugin standards that it would be
cool to be compliant with, if we can. KDE has something for Krita etc?
Does the GIMP?

I've no idea if it is viable but I love the idea, an opensource
equivalent of the photoshop plugin.

BTW have we officially released? Was there a fanfare? ;)

Caroline

Re: [Tuxpaint-devel] Tux Paint 'Magic' tools turning into plugin architecture

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

On Wed, Jul 04, 2007 at 02:42:31AM -0400, Albert Cahalan wrote:
> Cleaning up that code is an excellent idea, but the *.so thing
> doesn't seem so great.
> 
> The *.so files will slow the start-up time. My rough guess,
> assuming 2 disk seeks per file and 20 files, is one second.
> (good ideas to cut startup time would be appreciated)
> This is also one more thing to go wrong on SE Linux and
> for portability.

This is the thing I'm concerned about -- portability.
How does a project like The GIMP handle it?


One major benefit of making them shared libs is that people can
create and test new magic tools without needing to download and build
Tux Paint.  All they'll need is a C compiler and SDL libs, and I guess
some "libtuxpaint-dev" package for headers and such.

(Similar to 'libgimp2.0-dev' and 'libgimp2.0-docs' for writign GIMP plugins)

Actually, it may even make more sense to sen the Magic tools
24bpp or 32bpp data, rather than even usign SDL_Surface and the whole
getpixel/putpixel mess.

I figure I've got 6mo to a year to figure this junk out, before a new
release of Tux Paint, but I really _would_ like to try to go the .so/.dll/etc.
route.

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/

Re: [Tuxpaint-devel] New release in Debian unstable/sid

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

On Wed, Jul 04, 2007 at 07:53:21AM -0300, Ben Armstrong wrote:
> Any sid users out there can now find new releases of tuxpaint, tuxpaint-data,
> tuxpaint-stamps-default and tuxpaint-config at their local Debian mirror.

Thanks Ben.

Tell me how I can improve this way-out-of-date page, wouldya? :)

  http://www.tuxpaint.org/download/linux-debian/

-- 
-bill!
bi...@ne...
http://www.newbreedsoftware.com/