Tux Paint 0.9.17 released

Tux Paint 0.9.17 has been released!

http://www.tuxpaint.org/latest/tuxpaint-0.9.17-press-release-en.php3

Why do you SDL folks care? Well, this new version now includes
Input Method support (with support for Japanese and Korean text input),
using our own IM codebase.

Additionally, it now supports SVG-based stamp artwork, utilizing either
libcairo1, libsvg and libsvg-cairo, or librsvg2 and libcairo2.

As Tux Paint is GPL, you can poke around in the source code and use parts
for your own GPL applications, if you wish to do so!

(We may perhaps one day extract the IM and SVG stuff – and perhaps other
things like the print code for POSIX, Win32, OSX and BeOS – into LGPL libs,
too!)

It’s now available as Source (of course), RPMs for RedHat 9 and
Fedora CORE 1 through 7, and Windows. Mac OS X version coming soon.

Enjoy!

http://www.tuxpaint.org/--
-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

Great, except SDL is LGPL, isn’t it? Is GPL code compatible inside of an
LGPL program?On 7/2/07, Bill Kendrick wrote:

Tux Paint 0.9.17 has been released!

http://www.tuxpaint.org/latest/tuxpaint-0.9.17-press-release-en.php3

Why do you SDL folks care? Well, this new version now includes
Input Method support (with support for Japanese and Korean text input),
using our own IM codebase.

Additionally, it now supports SVG-based stamp artwork, utilizing either
libcairo1, libsvg and libsvg-cairo, or librsvg2 and libcairo2.

As Tux Paint is GPL, you can poke around in the source code and use parts
for your own GPL applications, if you wish to do so!

(We may perhaps one day extract the IM and SVG stuff – and perhaps other
things like the print code for POSIX, Win32, OSX and BeOS – into LGPL
libs,
too!)

It’s now available as Source (of course), RPMs for RedHat 9 and
Fedora CORE 1 through 7, and Windows. Mac OS X version coming soon.

Enjoy!

http://www.tuxpaint.org/


-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/


SDL mailing list
SDL at lists.libsdl.org
http://lists.libsdl.org/listinfo.cgi/sdl-libsdl.org


“If you see somebody who you don’t know getting into a crop duster that
doesn’t belong to you, report them.” – President George W. Bush

Hello !

Great, except SDL is LGPL, isn’t it? Is GPL code compatible inside of an
LGPL program?

As the complete TuxPaint Source is open,
this should be no problem.

CU

As owners of the code, we can re-release it as LGPL if we want to. :slight_smile:

-bill!On Mon, Jul 02, 2007 at 04:03:10PM -0400, James Buchwald wrote:

Great, except SDL is LGPL, isn’t it? Is GPL code compatible inside of an
LGPL program?

Well, actually, although he was confused about the currently-GPLed Tux Paint
code becoming LGPL, he DOES have a point… You can’t simply take someone’s
GPL code and re-release it as LGPL (or any OTHER license) without their
permission.

I believe the other-way-around is ok, though. Not really on-topic for the
SDL, list, though…On Mon, Jul 02, 2007 at 10:11:12PM +0200, Torsten Giebl wrote:

Hello !

Great, except SDL is LGPL, isn’t it? Is GPL code compatible inside of an
LGPL program?

As the complete TuxPaint Source is open,
this should be no problem.


-bill!
bill at newbreedsoftware.com
http://www.newbreedsoftware.com/

Why do you SDL folks care? Well, this new version now includes
Input Method support (with support for Japanese and Korean text
input),
using our own IM codebase.

In the game I’m working on (SDL based or course), I will need to
implement japanese text input on MacOS X, Windows and Linux.

On all platform, the input UI will be made by us in OpenGL (scrolling
in the chars and so on), as it’s a fullscreen game.

So, basically, what I need is a simple API which takes the user input
(an ascii string) and returns me a bunch of info (current kana,
available possibilities…), of course, this is to simplify, but
that’s just to place the kind of API I want.

At the moment, I have 0 experience in coding IM, I know how to use
them (and know that MacOS X japanese input is far better than MS
thing) but that’s all.

What was your approach (yea I know, I could dig in the code, but
before I wanna know the general idea) ?

Is anybody experienced with IM?

In my point of view, there is two major “choices”, creating adapters
to OS IM or bundling an IM lib. As, in our scenario, we have to do
all the interface, I would go for the IM lib, as it would unify the
user experience on all platforms.

Just to stay on topic, if I have to use a lib to have a cross
platform IM support, I will create an SDL compatible lib.

RegardsOn Jul 2, 2007, at 9:58 PM, Bill Kendrick wrote:

Kuon from japan.

“Your computer requests another OS, deny or allow?”

Blog:
http://kuon.goyman.com/