tuxpaint-devel — General discussion list for Tux Paint developers

Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

On 6/27/07, Caroline Ford <car...@go...> wrote:
> On Wed, 2007-06-27 at 09:03 -0700, Bill Kendrick wrote:

> > This is why Tux Paint Config is so full of options. :)
>
> Oh config certainly :) I was worried we were going to introduce complex
> printer dialogs!

Complex is no good. I don't think 2 to 6 icons, showing the page
as it will be printed, would be complex.

Really, shoving stuff into Tux Paint Config is like shoving
mistakes under the carpet. Say, "Tux Paint Carpet" anyone?
This makes some functionality needlessly adult-only.

[Tuxpaint-devel] Tux Paint 0.9.17rc1 and friends source tarballs available!

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

I've just rolled together what's in CVS and posted them to my FTP site.
Please download and test.  Send any minor updates ASAP.  Porting and
packaging folks, please tell me immediately if you find any issues building.

Once some beta testing has been done, I'll post official source builds
to SourceForge, and officially announce the release.  (Porters/packagers,
if you cannot roll together either betas and/or official builds soon,
let me know so I don't wait around for you :^) )

Thanks, and good work, everyone!  Big kudos to Caroline Ford for submitting
a ton of new content, and Martin Fuhrer for cleaning up lots of bits and
pieces of the OS X code!

  ftp://ftp.tuxpaint.org/unix/x/tuxpaint/testbuilds/source/

Thanks again!

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

Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

On Wed, 2007-06-27 at 09:03 -0700, Bill Kendrick wrote:
> On Wed, Jun 27, 2007 at 04:58:49PM +0100, Caroline Ford wrote:
> > 
> > I think generally if you were doing a school report you'd save it and
> > then play with it in the GIMP (or equivalent). 
> 
> Well, I can see making a picture, then printing it at the top of the
> page and scribbling your name and classroom at the bottom right corner.
> 
Ah okay. we mean different things by school report. For me a school
report is something a teacher would produce.
> 
> > Is the added complexity just going to affect user friendliness? It has
> > to be kid proof. 
> 
> This is why Tux Paint Config is so full of options. :)

Oh config certainly :) I was worried we were going to introduce complex
printer dialogs!

Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

On Wed, Jun 27, 2007 at 04:58:49PM +0100, Caroline Ford wrote:
> 
> I think generally if you were doing a school report you'd save it and
> then play with it in the GIMP (or equivalent). 

Well, I can see making a picture, then printing it at the top of the
page and scribbling your name and classroom at the bottom right corner.


> Is the added complexity just going to affect user friendliness? It has
> to be kid proof. 

This is why Tux Paint Config is so full of options. :)

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

Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

On Wed, 2007-06-27 at 08:52 -0700, Bill Kendrick wrote:
> On Wed, Jun 27, 2007 at 12:21:20AM -0400, Albert Cahalan wrote:
> > PostScript 3 is from 1997.
> 
> I'm betting some schools out there have printers older than that. :)
> 
> 
> <snip> 
> > That needed support in the GUI. A person might want
> > rotation or not.
> 
> I think _typically_, people want it printed as full-page as possible.
> 
> 
> > If you're doing the cover page for a school report or some
> > little book, you probably want the image centered at the top.
> > For other stuff, you might want to fill the page.

I think generally if you were doing a school report you'd save it and
then play with it in the GIMP (or equivalent). 

Is the added complexity just going to affect user friendliness? It has
to be kid proof. 

Caroline

Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

On Wed, Jun 27, 2007 at 12:21:20AM -0400, Albert Cahalan wrote:
> PostScript 3 is from 1997.

I'm betting some schools out there have printers older than that. :)


<snip> 
> That needed support in the GUI. A person might want
> rotation or not.

I think _typically_, people want it printed as full-page as possible.


> If you're doing the cover page for a school report or some
> little book, you probably want the image centered at the top.
> For other stuff, you might want to fill the page.

That's a good example of why one would NOT want it full-page and rotated.
So yeah, I do agree that adding a UI level would be nice.  It'd have to
be optional, for the younger kids.  (And let the parents set some default,
maybe.)

Thx!

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

Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

On 6/26/07, Bill Kendrick <nb...@so...> wrote:
> On Tue, Jun 26, 2007 at 12:46:44AM -0400, Albert Cahalan wrote:
> > We had a proposed fix that looked good. It got sent to the
> > mailing list. It adjusted "%%%%BeginData: %u Binary Bytes\n"
> > include 6 more bytes for "image\n" if I remember right.
> > It seems that the fix never made it in to CVS. I can't find the
> > change anywhere. That might have done the job.
>
> Hrm, sorry if that one flew past me. :^(
>
>
> > The old code sent the data in the obvious manner, as 24-bit
> > sRGB data. The new code uses a very inefficient and awkward
> > representation. It's planar (!) and hexidecimal.
>
> Well, there's still time to change it.  I liked that "pnmtops" saved
> as Level 2 PostScript, which I _imagine_ is more portable than Level 3,
> being older and such...

PostScript 3 is from 1997.

> > Now we can't handle sideways printers. There might not
> > be any of course, but that is lost functionality.
>
> I'm not sure what this means.  As it stands, if you have Tux Paint
> in a typical landscape orientation (e.g., 1024x768) and you print on
> an 11"x17" printer, the image will be rotated sideways to fit.

The old postscript was not printer-specific; it automatically
adjusted itself. This was great for network print queues that
might choose a somewhat random printer for the output.
(maybe choose the printer based on the IP address of the
client, so that the printout occurs in the same room)

> I have no idea if the previous code was this flexible -- there seemed to be
> some PS code in there for rotating, but the fprintf() was commented out.

That needed support in the GUI. A person might want
rotation or not.

If you're doing the cover page for a school report or some
little book, you probably want the image centered at the top.
For other stuff, you might want to fill the page.

> > I'm really suspicious of the whole paper size thing. This makes
> > the assumption that the user has made a paper size setting
> > and that it is correct. The physical printer hardware might not
> > agree with whatever random value Tux Paint ends up getting.
>
> It should be what the user has defined their papersize to be, either
> system-wide, or specific to Tux Paint.

Yes, I know. I'm doubting that this is a reasonable expectation.

As a matter of fact, my printer config at work is always
chopping things off around the margins. So this is a
real problem. (Fedora 7 with some Xerox office thing)

I think it is really nice to be able to ship the postscript off
to a completely unknown printer and get good results.
Printer configuration is really difficult; commonly one's printer
is not in the list of choices but numerous similar ones are.
(older models, European market models, Japanese market
models, high-end models with features you don't have...)
The user picks a random almost-right choice and hopes
that the output isn't too bad.

> > Anyway, I really wish the simple fix had been tried.
>
> One can simply download Tux Paint 0.9.16 source code, make the change,
> and see if it worked.  Of course, IIRC, _I_ never personally had a printing
> problem on my system, so I never found out exactly what was wrong.

Same here. It always worked fine for me. The people with
the problems never provided feedback on the proposed fix.
The fix did look good though, apparently correcting an error
I made in assuming that the "image\n" text wasn't to be
included in the byte count.

> And a request to those of you who DO decide to work on the PostScript
> stuff (at this point, or in the future) -- PostScript is kind of cryptic.

"kind of"???  :-)

Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

On Tue, Jun 26, 2007 at 12:46:44AM -0400, Albert Cahalan wrote:
> We had a proposed fix that looked good. It got sent to the
> mailing list. It adjusted "%%%%BeginData: %u Binary Bytes\n"
> include 6 more bytes for "image\n" if I remember right.
> It seems that the fix never made it in to CVS. I can't find the
> change anywhere. That might have done the job.

Hrm, sorry if that one flew past me. :^(


> The old code sent the data in the obvious manner, as 24-bit
> sRGB data. The new code uses a very inefficient and awkward
> representation. It's planar (!) and hexidecimal.

Well, there's still time to change it.  I liked that "pnmtops" saved
as Level 2 PostScript, which I _imagine_ is more portable than Level 3,
being older and such...


> Now we can't handle sideways printers. There might not
> be any of course, but that is lost functionality.

I'm not sure what this means.  As it stands, if you have Tux Paint
in a typical landscape orientation (e.g., 1024x768) and you print on
an 11"x17" printer, the image will be rotated sideways to fit.

If, however, you're on a tablet PC in portrait orientation (e.g., 768x1024)
and print on that same paper, the image will NOT be rotated.

I tested a few combinations (asking for different papersizes and Tux Paint
canvases) and viewed the resulting PS in KPDF, and it worked reasonably
well.

I have no idea if the previous code was this flexible -- there seemed to be
some PS code in there for rotating, but the fprintf() was commented out.


> I'm really suspicious of the whole paper size thing. This makes
> the assumption that the user has made a paper size setting
> and that it is correct. The physical printer hardware might not
> agree with whatever random value Tux Paint ends up getting.

It should be what the user has defined their papersize to be, either
system-wide, or specific to Tux Paint.


> Pushing regular stuff into Tux Paint Config is not good.
> It's likely that few people run this. It is also bad to expect
> that the Alt printing stuff is usable. Things ought to work
> right, every time, without the add-on hacks.

Well, the point here, was to work as intelligently as possible with the
least feedback from the user.  In the end, it may come down to a documentation
problem (e.g., "maybe your system is set up for A4, but you're in the US
so your printer is Letter?  check your system printing config").

At the moment, it's a "Known Issues" documentation problem.  (The whole lot of
printing problems, in fact... e.g., "try running through 'ps2ps' on Linux" and
"try running Tux Paint through the PPC simulator ('Rosetta') on Intel Macs")


> Note that there are 6 reasonable printing locations on the
> paper. (landscape or not, centered in the too-small dimension
> or to one side in that dimension) It'd be nice to make all 6
> of these available in the normal print dialog. (thumbnails)

Not a bad idea, actually.


> Anyway, I really wish the simple fix had been tried.

One can simply download Tux Paint 0.9.16 source code, make the change,
and see if it worked.  Of course, IIRC, _I_ never personally had a printing
problem on my system, so I never found out exactly what was wrong.


And a request to those of you who DO decide to work on the PostScript
stuff (at this point, or in the future) -- PostScript is kind of cryptic.
Could you please include C comments that explain what the PS is trying to
do? :^)

Thx,

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

Re: [Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

On 6/25/07, Bill Kendrick <nb...@so...> wrote:
>
> The PostScript generating code in Tux Paint has been moved to an external
> set of source files (postscript_print.c and .h) and the PS content itself
> has been rewritten from the ground up (based on NetPBM's "pnmtops" source
> code, and examining its output).
>
> It's not perfect, but it should be a lot better.
>
> Bonus: Tux Paint targets that use this PostScript generating code
> (that is, _not_ Windows, Mac OS X or BeOS, which have their own
> platform-specific print code) now uses "libprint" to determine the
> user's or system's current default paper size (e.g., "letter" or "a4").
>
> That size (in PS points) is included in the generated PostScript, and
> Tux Paint asks the PS device to scale the user's picture up to fit
> on the page.  It rotates it appropriately, based on paper size and
> image aspect ratio.
>
> Finally, Tux Paint lets the user specify a different paper size than
> what "libprint" discovers (via $PAPER or /etc/papersize).  A pulldown
> that shows all paper sizes known by "libprint" has been added to
> Tux Paint Config.
>
> PLEASE TEST! :^)  Recommendations to make it perfect would be appreciated.
> (Look for "FIXME" comments in the postscript_print.c :^) )
>
> Thanks!  (Special thanks to my friend Henry House for looking over the
> current PS output for me, and giving recommendations.  And thanks to
> Jef Poskanzer, who wrote "pnmtops" back in the day.)

Well, I can't complain too much because I never found the time
to look into things, but... I think this is a step backwards.

We had a proposed fix that looked good. It got sent to the
mailing list. It adjusted "%%%%BeginData: %u Binary Bytes\n"
include 6 more bytes for "image\n" if I remember right.
It seems that the fix never made it in to CVS. I can't find the
change anywhere. That might have done the job.

The old code sent the data in the obvious manner, as 24-bit
sRGB data. The new code uses a very inefficient and awkward
representation. It's planar (!) and hexidecimal.

Now we can't handle sideways printers. There might not
be any of course, but that is lost functionality.

I'm really suspicious of the whole paper size thing. This makes
the assumption that the user has made a paper size setting
and that it is correct. The physical printer hardware might not
agree with whatever random value Tux Paint ends up getting.

Pushing regular stuff into Tux Paint Config is not good.
It's likely that few people run this. It is also bad to expect
that the Alt printing stuff is usable. Things ought to work
right, every time, without the add-on hacks.

Note that there are 6 reasonable printing locations on the
paper. (landscape or not, centered in the too-small dimension
or to one side in that dimension) It'd be nice to make all 6
of these available in the normal print dialog. (thumbnails)

Anyway, I really wish the simple fix had been tried.

[Tuxpaint-devel] Tux Paint PostScript printing code rewritten

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

The PostScript generating code in Tux Paint has been moved to an external
set of source files (postscript_print.c and .h) and the PS content itself
has been rewritten from the ground up (based on NetPBM's "pnmtops" source
code, and examining its output).

It's not perfect, but it should be a lot better.

Bonus: Tux Paint targets that use this PostScript generating code
(that is, _not_ Windows, Mac OS X or BeOS, which have their own
platform-specific print code) now uses "libprint" to determine the
user's or system's current default paper size (e.g., "letter" or "a4").

That size (in PS points) is included in the generated PostScript, and
Tux Paint asks the PS device to scale the user's picture up to fit
on the page.  It rotates it appropriately, based on paper size and
image aspect ratio.

Finally, Tux Paint lets the user specify a different paper size than
what "libprint" discovers (via $PAPER or /etc/papersize).  A pulldown
that shows all paper sizes known by "libprint" has been added to
Tux Paint Config.

PLEASE TEST! :^)  Recommendations to make it perfect would be appreciated.
(Look for "FIXME" comments in the postscript_print.c :^) )

Thanks!  (Special thanks to my friend Henry House for looking over the
current PS output for me, and giving recommendations.  And thanks to
Jef Poskanzer, who wrote "pnmtops" back in the day.)

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

[Tuxpaint-devel] libRSVG support now in CVS!

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

I got SVG support working again on my Kubuntu 07.04 (Fiesty) laptop
last night, using libRSVG and its Cairo backend!

Unfortunately, libRSVG has _mavy_ dependencies.  OTOH, it's actually
_available_ for Ubuntu (and presumably other distros), unlike the
older libs I had been using before.

To summarize:

  make           -- builds with librsvg-2 and libcairo-2 and friends
  make oldsvg    -- builds with libcairo-1, libsvg and libsvg-cairo
  make nosvg     -- disables SVG support (no deps beyond what 0.9.16 needed)

Next up:  Try to figure out PostScript problems.  Then it's time for
a new release!

Get your updates in quick!  And please begin testing what's in CVS, if you can!
(I hope to make a beta release some time next week, and a final release
before the end of June, if I can!)

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

Re: [Tuxpaint-devel] Green Fedora

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

On 20-Jun-07, at 6:51 PM, Bill Kendrick wrote:

> On Tue, Jun 19, 2007 at 10:21:25PM -0600, Martin Fuhrer wrote:
>> While packaging the latest stamps for the Mac OS X installer, I
>> noticed that the hats directory contains the following files:
>>
>> green_fedora.png
>> green_fedora.txt
>> green_fedora_01.svg
>> green_fedora_01.txt
>>
>> The PNG and SVG files both contain the exact same hat, so I'm tempted
>> to rename green_fedora_01.svg to green_fedora.txt,
>
> I assume you meant "green_fedora.svg" :)

Must have been a neural short circuit . :)

>
>> and get rid of
>> green_fedora_01.txt.  Any objections to this?
>
> Fine by me!

Done!

Martin

Re: [Tuxpaint-devel] Green Fedora

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

On Tue, Jun 19, 2007 at 10:21:25PM -0600, Martin Fuhrer wrote:
> While packaging the latest stamps for the Mac OS X installer, I  
> noticed that the hats directory contains the following files:
> 
> green_fedora.png
> green_fedora.txt
> green_fedora_01.svg
> green_fedora_01.txt
> 
> The PNG and SVG files both contain the exact same hat, so I'm tempted  
> to rename green_fedora_01.svg to green_fedora.txt,

I assume you meant "green_fedora.svg" :)


> and get rid of  
> green_fedora_01.txt.  Any objections to this?

Fine by me!


> The SVG file also contained a stray red rectangle in the lower right  
> corner, which I have edited out.

Cool, thx!

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

[Tuxpaint-devel] Green Fedora

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

While packaging the latest stamps for the Mac OS X installer, I  
noticed that the hats directory contains the following files:

green_fedora.png
green_fedora.txt
green_fedora_01.svg
green_fedora_01.txt

The PNG and SVG files both contain the exact same hat, so I'm tempted  
to rename green_fedora_01.svg to green_fedora.txt, and get rid of  
green_fedora_01.txt.  Any objections to this?

The SVG file also contained a stray red rectangle in the lower right  
corner, which I have edited out.

Martin

[Tuxpaint-devel] Slides from "Tux Paint, Again" presentation

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

I did a presentation on the upcoming version of Tux Paint at the
Linux Users' Group of Davis in California last night.

Slides and example code are available online:

  http://www.tuxpaint.org/presentations/lugod-2007-06/

and mirrored at the LUGOD website:

  http://www.lugod.org/presentations/tuxpaintagain/

Enjoy!

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

[Tuxpaint-devel] PostScript bug on Linux - anyone want to tackle?

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

Anyone out here feel comfortable trying to tackle the printing bug
in Linux?  (Faulty PostScript; running through "ps2ps" seems to help.)

If I don't hear anything soon, I'll try my hand at it.  *gulp!*

Thx,

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

Re: [Tuxpaint-devel] Configuration for Current and All Users

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

On Sun, Jun 17, 2007 at 10:56:06PM -0600, Martin Fuhrer wrote:
> The additions will require some testing on Windows and Linux, to make  
> sure the files are written to the correct locations (for Linux,  
> you'll need to add a CONFDIR variable to the Makefile, similar to the  
> CONFDIR variable in the Tux Paint Makefile), and to ensure any other  
> bugs are caught.  Hopefully the usage is clear - let me know if  
> anything isn't!

Hi Martin, thanks for adding this!  GCC on Linux had some complaints,
but I just corrected them and committed back to CVS.

I haven't tested it much yet, but will do so soon.  I'll also update the
docs a bit with info about this new feature.  Thanks again!

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

[Tuxpaint-devel] Configuration for Current and All Users

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

I submitted some additions to Tux Paint Config so that Tux Paint may  
be configured for the current user or all users via a "Settings for"  
drop-down menu.  Depending on menu selection, clicking "Apply" will  
write out the settings to the user's config file or the system-wide  
config file.  If a system-wide config file exists, there is an option  
for the current user to use the system-wide settings (the "Use All  
Users Settings" checkbox - maybe someone can come up with a better  
name).  If this checkbox is checked, all the configuration widgets  
are intentionally greyed out and the user config file is deleted;  
unchecking the checkbox will re-enable the widgets and generate a new  
user config file.

The additions will require some testing on Windows and Linux, to make  
sure the files are written to the correct locations (for Linux,  
you'll need to add a CONFDIR variable to the Makefile, similar to the  
CONFDIR variable in the Tux Paint Makefile), and to ensure any other  
bugs are caught.  Hopefully the usage is clear - let me know if  
anything isn't!

Martin

Re: [Tuxpaint-devel] Tuxpaint now in OpenBSD

[Antoine J. <aja...@lp...>]

On Thu, 14 Jun 2007, Caroline Ford wrote:
> Do we need to make sure we have a static link to the source of 0.9.16
> somewhere for the ports tree? It links to sourceforge mirrors - I
> presume we don't delete/move old versions.

As long as older vesions are available on sourceforge, there's no need 
for a static link.

> So on our website we should link to any mirror *except* the fanout in
> Canada?

Well... you could link to the CVS web for the port:
http://www.openbsd.org/cgi-bin/cvsweb/ports/games/tuxpaint/

As for the package itself, I don't know, we usually go like:
$ export PKG_PATH=your_favorite_mirror
$ pkg_add tuxpaint

Of course, you could just link to the package itself on one of the 
mirrors (linking to the master site is ok too).

> Thanks for this! It's always great to be ported to a new OS :)
>
> BTW we're planning on releasing 0.9.17 this month.

Cool, my daughter will be very happy ;)

-- 
Antoine

Re: [Tuxpaint-devel] Tuxpaint now in OpenBSD

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

On Thu, 2007-06-14 at 08:46 +0200, Antoine Jacoutot wrote:

> > I'm not sure which mirror the web site should link to - I think we
> > should probably mirror locally. (I've copied Antoine into this email so
> > hopefully he'll know if we should do anything special)
> 
> Well, what we usually do is:
> your_favorite_mirror/OpenBSD/4.1/packages/i386/tuxpaint-0.9.16p0.tgz
> ...
> 
> There's no point in mirrorring locally as our package system also takes 
> care of dependencies.

Do we need to make sure we have a static link to the source of 0.9.16
somewhere for the ports tree? It links to sourceforge mirrors - I
presume we don't delete/move old versions.

So on our website we should link to any mirror *except* the fanout in
Canada?

> Anyway, thanks for your interested in this port, I actually wanted to 
> tell tuxpaint people about it and just forgot ;)
> 

Thanks for this! It's always great to be ported to a new OS :)

BTW we're planning on releasing 0.9.17 this month.

Caroline

Re: [Tuxpaint-devel] Tuxpaint now in OpenBSD

[Antoine J. <aja...@lp...>]

On Wed, 13 Jun 2007, Bill Kendrick wrote:
>> In the ports tree it is under ** /ports/games ** not /ports/education/
>> or /ports/graphics/

It is physically under ports/games, but it's part of both categories, 
games and graphics.

-- 
Antoine

Re: [Tuxpaint-devel] Tuxpaint now in OpenBSD

[Antoine J. <aja...@lp...>]

On Thu, 14 Jun 2007, Caroline Ford wrote:
> I've just checked and Tuxpaint did make it into ports and packages for
> OpenBSD 4.1 (In OpenBSD land a port a patch to source code. The
> collection of patches is called the ports tree. Packages are
> pre-compiled binaries)

To be precise, a port is like a recipe + patches to build a package 
(like portage under Gentoo or a SRPM spec+patches).

> Alpha, AMD 64, i386, PowerPC, SPARC, SPARC 64
>
> mips64 (the stamps but not the rest?)

That means there was an error building the rest, but I don't have a mips 
platform to debug this ;)

> I'm not sure which mirror the web site should link to - I think we
> should probably mirror locally. (I've copied Antoine into this email so
> hopefully he'll know if we should do anything special)

Well, what we usually do is:
your_favorite_mirror/OpenBSD/4.1/packages/i386/tuxpaint-0.9.16p0.tgz
...

There's no point in mirrorring locally as our package system also takes 
care of dependencies.
Anyway, thanks for your interested in this port, I actually wanted to 
tell tuxpaint people about it and just forgot ;)

-- 
Antoine

[Tuxpaint-devel] Extra website/package stuff

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

Under Linux we mention Debian, 'RPM' and slackware.

We should mention Ubuntu too. For Ubuntu Tuxpaint is in Add/Remove
Applications in the Education category. It's also installed by default
in Edubuntu. (http://www.edubuntu.org/)

They use Debian's packaging but I wouldn't presume that Ubuntu users
have the technical know-how to cope with our Debian instructions.

FreeBSD
We say they are on 0.9.14. I've just checked and they are on 0.9.16.
They are also on 2006.10.21 (not 2004.10.03) for stamps.

ps. FreeBSD's logo has changed. It's just a stylised head now.

NetBSD
Our links are broken. The links for binaries should be:

ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/graphics/tuxpaint/README.html
version: tuxpaint-0.9.14

ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/graphics/tuxpaint-stamps/README.html
version: 2004.10

ftp://ftp.netbsd.org/pub/pkgsrc/current/pkgsrc/graphics/tuxpaint-config/README.html
version: 0.0.5

This is looking a bit unmaintained :(

I've found this - http://pkgsrc.se/hist/graphics/tuxpaint which gives a
revision history. It *has* been updated as recently as March but it
looks like they are still using 0.9.14 code.

Caroline

Re: [Tuxpaint-devel] Tuxpaint now in OpenBSD

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

On Thu, Jun 14, 2007 at 12:12:24AM +0100, Caroline Ford wrote:
> I've just checked and Tuxpaint did make it into ports and packages for
> OpenBSD 4.1 (In OpenBSD land a port a patch to source code. The
> collection of patches is called the ports tree. Packages are
> pre-compiled binaries)

Awesome, thanks for the note, Caroline!


<snip>
> In the ports tree it is under ** /ports/games ** not /ports/education/
> or /ports/graphics/

:^(

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

[Tuxpaint-devel] Tuxpaint now in OpenBSD

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

I've just checked and Tuxpaint did make it into ports and packages for
OpenBSD 4.1 (In OpenBSD land a port a patch to source code. The
collection of patches is called the ports tree. Packages are
pre-compiled binaries)

It's in three separate packages:

tuxpaint-0.9.16p0.tgz 
tuxpaint-config-0.0.7.tgz
tuxpaint-stamps-20061021.tgz

The maintainer is Antoine Jacoutot <aja...@op...>

As a binary it appears for the following architectures:

Alpha, AMD 64, i386, PowerPC, SPARC, SPARC 64

mips64 (the stamps but not the rest?)

We should update the web site (http://www.tuxpaint.org/download/) with
this stuff. These are links to the packages on the Canadian fanout site.
I'm not sure which mirror the web site should link to - I think we
should probably mirror locally. (I've copied Antoine into this email so
hopefully he'll know if we should do anything special)

i386
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/i386/tuxpaint-0.9.16p0.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/i386/tuxpaint-stamps-20061021.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/i386/tuxpaint-config-0.0.7.tgz

AMD64
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/amd64/tuxpaint-0.9.16p0.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/amd64/tuxpaint-stamps-20061021.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/amd64/tuxpaint-config-0.0.7.tgz

PowerPC
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/powerpc/tuxpaint-0.9.16p0.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/powerpc/tuxpaint-stamps-20061021.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/powerpc/tuxpaint-config-0.0.7.tgz

Alpha
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/alpha/tuxpaint-0.9.16p0.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/alpha/tuxpaint-stamps-20061021.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/alpha/tuxpaint-config-0.0.7.tgz

SPARC
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/sparc/tuxpaint-0.9.16p0.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/sparc/tuxpaint-stamps-20061021.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/sparc/tuxpaint-config-0.0.7.tgz

SPARC64
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/sparc64/tuxpaint-0.9.16p0.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/sparc64/tuxpaint-stamps-20061021.tgz
ftp://ftp.openbsd.org/pub/OpenBSD/4.1/packages/sparc64/tuxpaint-config-0.0.7.tgz

In the ports tree it is under ** /ports/games ** not /ports/education/
or /ports/graphics/

HTH

Caroline