Re: [school-discuss] Tux Print?

[Bruno Coudoin <bruno.coudoin@free.fr>]

Le vendredi 05 novembre 2004 à 15:34 -0500, Bill Kendrick a écrit :
> On Fri, Nov 05, 2004 at 02:40:45PM -0500, Doug Loss wrote:
> > Bill Kendricks, I remember a while ago that you and I (and a few others) 
> > talked about the possibility of creating a "Tux Print" program to fill 
> > the space in the OSS world that PrintMaster and PrintShop Pro fill in 
> > the Windows world.  As I recall, you thought it would be a fairly easy 
> > thing to do.  I know that you've had your hands full with other things, 
> > but do you have any other thoughts on this or suggestions for people who 
> > might be interested in trying to create something like it?
> 
> Hey Doug.  Yeah, sorry for all my half-started attempts at projects. ;^)
> 
> I'm beginning to think that a different environment might be better for
> the two apps I was coming up with: Tux Print (described fairly accurately
> above) and Tux Writer (a word processor for kids).
> 
> I think rather than being based entirely on SDL and friends, it makes more
> sense to use a more app-oriented library like GTK+, Qt or even FLTK.
> (It doesn't make sense to reinvent such complex GUI widgets.)
> 
> Tux Print was the main project I was going to work on first, but it
> initally got held up because I really wanted SVG support.  An SVG rendering
> library for SDL has been started, but last I saw, was nowhere close to
> finished.  (I think the main coder and myself were the only folks interested!)
> 
> Tux Print needs SVG (and TTF) support because we're talking about
> printing things that could span numerous pages (like a poster made of 3x3
> sheets of US Letter or A4 or paper, or a banner made of 10x1 or 12x1 sheets).
> Bitmaps would either need to be HUGE, or would just come out ugly and
> pixellated.
> 
> Also, since the main PURPOSE of Tux Print is to print, it needs to be very
> robust and mature when it comes to talking to various OS's printing systems.
> My original trick of "pngtopnm | pnmtops | lpr" in Tux Paint for Linux just
> isn't going to cut it, I think. :^)
> 
> 
> I think the main goals of a Tux Print project should be:
> 
>   1. Openness (GPL or other Open Source license for the code AND artwork)
> 
>   2. Portability (Linux, Windows, Mac OS X, Mac OS classic, etc.)
> 
>   3. Internationalization
> 
>   4. Vector graphics support (SVG clipart and TTF fonts)
> 
>   5. Ease of use (try to keep the interface more like Tux Paint and less
>      like OpenOffice.org; gear it to kids aged 5-10 or 3-8 or something)
> 
>   6. Ease of installation & configuration (for the parents and teachers
>      who have better things to do than fight with some program for their kids)
> 
> 
> #1 is pretty much obvious, with the folks we've got out on these lists
> and in the greater Linux and FLOSS communities.  Done.
> 
> #2 was going to be handled (for UI at least) by SDL, but again, I think
> a slightly more mature and robust GUI library should be used, rather than
> rolling our own.  It COULD be done in SDL, but #3 and #4 are affected.
> If it's done with a GUI library, it MUST be something that runs 'everywhere.'
> You just can't know where your OSS app will end up! ;^)
> 
> #3 has been /relatively/ easy in Tux Paint, after much support from the
> likes of Karl Ove Hufthammer and Mark K. Kim.  There are places where it
> fails, though, like the 'Text' tool's input, and support for some of the
> more complicated (to render) languages. :^/  The popular GUI libraries
> like Qt and GTK+ would help here.
> 
> #4 was my initial sticking point. (Then I got busy and moved and
> distracted, as usual.)  If I had a 100% working SVG renderer for SDL
> today, I might actually start finishing up the /current/ Tux Print code.
> But, once again, our other GUI friends actually DO support SVG already!
> (SDL, of course, already does TTF, so that's dealt with.)
> 
> #5 is very important to me.  My thought is that the Tux* apps should be
> for the very youngest kids.  If older kids want to mess with them, they
> can, but by the time they get older, they can probably handle the 'grown up'
> apps like The Gimp and OpenOffice.org.  The youngest kids don't have much in
> the way of these kinds of apps, though (in the Linux & Open Source realm).
> I think I did a good job making Tux Paint functional and easy-to-use
> using SDL, but it's just a painting canvas.  Tux Print needs to be a /little/
> more complicated (but again, not MUCH more!)
> 
> One fear I've had regarding Tux Print and Tux Writer using pre-existing GUI
> libraries is that those libraries would add unnecessary complexity.
> KDE apps benefit from right-click and menu bars and so forth, but something
> like Tux Print should look like a very simple PDA app or a game... that's
> how I designed Tux Paint. :^)
> 
> 
> Anyway, I'm starting to ramble. :)  Does the above help in any way? ;)
> 

Bill, gcompris already does vector graphics, even animations. It saves
and load the graphism as svg. It's perhaps not up to your expectation
but please evaluate it to be sure.

For the tux writer idea, I had also been requested this by some users.
gcompris is gtk based. It's possible and easy to do it using python and
gtk as a new activity for gcompris.

Beside the traditional word processor, I'd like also to have a word
processor trainer where a text to reproduce is presented. It should help
teachers.

Having a multi activity software, well integrated solves some
maintenance issue. It's harder to maintain and install several tool
rather than one.

I'll be please if the gcompris 'development platform' could be used for
your needs.

Regards,

-- 
Bruno Coudoin
http://gcompris.net free educational software for kids
http://ofset.org    free educational software for all