tuxpaint-devel Mailing List for Tux Paint (Page 117)
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel — General discussion list for Tux Paint developers
You can subscribe to this list here.
| 2005 |
Jan
|
Feb
|
Mar
(15) |
Apr
(5) |
May
(12) |
Jun
(15) |
Jul
(21) |
Aug
(2) |
Sep
(14) |
Oct
(32) |
Nov
(47) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2006 |
Jan
(33) |
Feb
(59) |
Mar
(17) |
Apr
(5) |
May
|
Jun
(6) |
Jul
(7) |
Aug
(19) |
Sep
(64) |
Oct
(161) |
Nov
(9) |
Dec
(23) |
| 2007 |
Jan
(6) |
Feb
(46) |
Mar
(55) |
Apr
(41) |
May
(43) |
Jun
(44) |
Jul
(46) |
Aug
(25) |
Sep
(16) |
Oct
(29) |
Nov
(50) |
Dec
(64) |
| 2008 |
Jan
(11) |
Feb
(18) |
Mar
(52) |
Apr
(37) |
May
(40) |
Jun
(78) |
Jul
(85) |
Aug
(31) |
Sep
(23) |
Oct
(13) |
Nov
(19) |
Dec
(37) |
| 2009 |
Jan
(36) |
Feb
(24) |
Mar
(86) |
Apr
(43) |
May
(36) |
Jun
(151) |
Jul
(23) |
Aug
(40) |
Sep
(11) |
Oct
(91) |
Nov
(68) |
Dec
(27) |
| 2010 |
Jan
|
Feb
(11) |
Mar
(79) |
Apr
(50) |
May
(26) |
Jun
(44) |
Jul
(31) |
Aug
(6) |
Sep
(2) |
Oct
(16) |
Nov
(11) |
Dec
(4) |
| 2011 |
Jan
(14) |
Feb
(5) |
Mar
(22) |
Apr
(1) |
May
(5) |
Jun
(5) |
Jul
(13) |
Aug
(1) |
Sep
(3) |
Oct
(18) |
Nov
(15) |
Dec
(25) |
| 2012 |
Jan
(1) |
Feb
(9) |
Mar
(41) |
Apr
(32) |
May
|
Jun
(2) |
Jul
(5) |
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
(2) |
| 2013 |
Jan
|
Feb
(5) |
Mar
(16) |
Apr
(21) |
May
(3) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
(13) |
Nov
(1) |
Dec
(3) |
| 2014 |
Jan
|
Feb
(12) |
Mar
(6) |
Apr
(35) |
May
|
Jun
(12) |
Jul
(35) |
Aug
(98) |
Sep
(3) |
Oct
(8) |
Nov
(4) |
Dec
(1) |
| 2015 |
Jan
(4) |
Feb
(9) |
Mar
(58) |
Apr
(9) |
May
(15) |
Jun
(23) |
Jul
|
Aug
(32) |
Sep
(12) |
Oct
(21) |
Nov
(5) |
Dec
(14) |
| 2016 |
Jan
(6) |
Feb
(3) |
Mar
(37) |
Apr
(18) |
May
(5) |
Jun
(8) |
Jul
|
Aug
(21) |
Sep
(5) |
Oct
(20) |
Nov
(4) |
Dec
(6) |
| 2017 |
Jan
(2) |
Feb
|
Mar
|
Apr
(19) |
May
(8) |
Jun
(3) |
Jul
(3) |
Aug
(5) |
Sep
|
Oct
(4) |
Nov
(4) |
Dec
(6) |
| 2018 |
Jan
(3) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(4) |
Sep
(4) |
Oct
|
Nov
|
Dec
(3) |
| 2019 |
Jan
|
Feb
|
Mar
(5) |
Apr
|
May
|
Jun
(2) |
Jul
(1) |
Aug
(3) |
Sep
(14) |
Oct
(2) |
Nov
(1) |
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
(1) |
Apr
(1) |
May
(2) |
Jun
|
Jul
|
Aug
(3) |
Sep
(15) |
Oct
(9) |
Nov
(11) |
Dec
(7) |
| 2021 |
Jan
(12) |
Feb
(2) |
Mar
(16) |
Apr
|
May
|
Jun
(11) |
Jul
|
Aug
(4) |
Sep
(24) |
Oct
(68) |
Nov
(61) |
Dec
|
| 2022 |
Jan
(42) |
Feb
(17) |
Mar
(20) |
Apr
(2) |
May
(23) |
Jun
(4) |
Jul
(6) |
Aug
|
Sep
(27) |
Oct
(4) |
Nov
(10) |
Dec
(31) |
| 2023 |
Jan
(4) |
Feb
(18) |
Mar
(8) |
Apr
(11) |
May
(18) |
Jun
(47) |
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
(2) |
| 2024 |
Jan
(10) |
Feb
|
Mar
|
Apr
(3) |
May
(4) |
Jun
(3) |
Jul
(6) |
Aug
|
Sep
(2) |
Oct
(1) |
Nov
|
Dec
(3) |
| 2025 |
Jan
(2) |
Feb
(11) |
Mar
(3) |
Apr
(1) |
May
(22) |
Jun
(5) |
Jul
(15) |
Aug
(5) |
Sep
|
Oct
(3) |
Nov
|
Dec
|
|
From: Bill K. <nb...@so...> - 2008-01-29 17:12:03
|
On Tue, Jan 29, 2008 at 01:05:28PM +0800, HackerGene wrote: > Bill , have you recieved my translation files ? I did, but I have not had time to put it into CVS, sorry! I'll try to do that today. -bill! |
|
From: HackerGene <hac...@gm...> - 2008-01-29 05:05:30
|
Bill , have you recieved my translation files ? -- Regards. -HackerGene. --~--~---------~--~----~------------~-------~--~----~ HomePage: http://www.allhonker.com Projects: http://snort.org.cn http://tuxpaint.cn --~--~---------~--~----~------------~-------~--~----~ We advocate the philosophy which lead us to explore the world that is "Free , Opensource and Share". ---Allhonker Network Information Security Team. |
|
From: Pere P. i C. <pe...@fo...> - 2008-01-24 18:21:23
|
On Wed, 2008-01-23 at 19:49 -0800, Bill Kendrick wrote: > > Happens for me too! Can you add a bug for it to SF.net? > Done and proposed a patch: http://sourceforge.net/tracker/index.php?func=detail&aid=1879066&group_id=66938&atid=516295 Yours Pere |
|
From: Bill K. <nb...@so...> - 2008-01-24 03:49:54
|
On Wed, Jan 23, 2008 at 11:01:28PM +0100, Pere Pujal i Carabantes wrote: > Hi all! > > Can someone confirm this?: Happens for me too! Can you add a bug for it to SF.net? Thx! -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Pere P. i C. <pe...@fo...> - 2008-01-23 22:01:54
|
Hi all! Can someone confirm this?: Start tuxpaint, select the arrow brush and the line tool, draw from the bottom to the up various times. I get the brush not right distributed, some are close, some are separate. The cat brush does something similar, the paint tool with those brushes too. Yours Pere. |
|
From: TOYAMA Shin-i. <sh...@wm...> - 2008-01-15 15:05:11
|
Hi John, Yesterday, I was able to have time to test your instructions. Almost of all things were O.K. and finally I got tuxpaint.exe which seems to work perfectly! Thank you for your great effort to build up this complicated environment and to document detail instruction. Here are some quick reports about some slight differences between the results I got and your instructions. a) libtool version The result of "libtool --version" was different from yours, like --------------------------- $ libtool --version ltmain.sh (GNU libtool) 1.5 (1.1220 2003/04/05 19:32:58) Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. --------------------------- b) Installing Pango At the stage of building GTK+, I found that .pc file for Pango had not been installed. So, I had to turn back to the installation stage of Pango and edit modules/Makefile to disable some processes which causes error related to the 'pango-querymodules' before doing "make install". Did you do something like this? c) Installing libgsf "configure" ended with error caused by the lack of python. So, I added "--without-python" option for "configure". John Popplewell wrote in <200...@ro...> >Hi, > >I've put up some instructions detailing how to build the dependencies >and Tux Paint itself. > >MinGW/MSYS - Tux Paint 0.9.18 (2K/XP only) >http://johnnypops.demon.co.uk/mingw/index.html > >MinGW/MSYS - Tux Paint 0.9.17 (9x/ME/2K/XP) <- the old stuff >http://johnnypops.demon.co.uk/mingw-old/index.html > >I'm hoping to make a set of pre-built dependencies available so that >others may create new plugins without spending a lot of time just getting >Tux Paint working. When it's been tested, Bill has offered to host the >pre-built bundle. > >Working on a HOWTO for putting a plugin together, > >cheers, >John. -- TOYAMA Shin-ichi mailto:sh...@wm... |
|
From: Bill K. <nb...@so...> - 2008-01-07 17:18:16
|
Martin has put together the library bits necessary to build Tux Paint with Apple's XCode development tools, and I've placed them online, here: ftp://ftp.tuxpaint.org/unix/x/tuxpaint/source/libs/macosx/ He also recently updated the XCode project in CVS, so you'll want to get the latest from the SourceForge.net repository. Enjoy! -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Caroline F. <car...@go...> - 2008-01-01 21:28:33
|
On Tue, 2008-01-01 at 12:56 -0800, Bill Kendrick wrote: > On Tue, Jan 01, 2008 at 05:48:10PM +0000, Caroline Ford wrote: > > The stamps package is massive though (20 meg), they do have a point. > > They really just wanted to make the stamps optional, but also requested > > cleverer packaging. > > Again, is breaking it up into categories out of the question? > I doubt it - and it would certainly be easier than having a default + categories. I'll make some debian packages of the categories. I made a package of the full set for Hardy (here - http://ppa.launchpad.net/secretlondon/ubuntu/pool/main/t/tuxpaint-stamps/ it's the deb). Caroline |
|
From: Bill K. <nb...@so...> - 2008-01-01 20:56:23
|
On Tue, Jan 01, 2008 at 05:48:10PM +0000, Caroline Ford wrote: > The stamps package is massive though (20 meg), they do have a point. > They really just wanted to make the stamps optional, but also requested > cleverer packaging. Again, is breaking it up into categories out of the question? -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Caroline F. <car...@go...> - 2008-01-01 17:39:21
|
On Sun, 2007-12-30 at 11:26 -0800, Bill Kendrick wrote: > On Sun, Dec 30, 2007 at 11:20:05AM +0000, Caroline Ford wrote: > > Arrgh. How do you know we have too much stuff? I've been making things > > like brushes and stamps presuming that we can never really have too > > much. > > Well, remember he's on a much more restrictive environment, being on the XO-1. > (Extremely reduced RAM and filespace, compared to a 'normal' modern desktop > or laptop.) fair enough. I presumed this was cross platform - it seems really obvious that different platforms get different amounts of content. > > > Is this just a packaging problem? > > Are the Ubuntu folks against simply having separate stamp packages based > on the various Makefile targets? Shin-Ichi has been building separate > RPM packages for stamps, based on that. It's not the Ubuntu folks as much as some users (I think they are from Baltix which is an Ubuntu based distro targeting the Baltic states of Latvia, Lithuania and Estonia) The stamps package is massive though (20 meg), they do have a point. They really just wanted to make the stamps optional, but also requested cleverer packaging. Caroline |
|
From: Albert C. <aca...@gm...> - 2008-01-01 08:55:47
|
This one is pretty bad I think, though it's been there a while. It wasn't obvious that Tux Paint was at fault until I tested with the gimp. Maybe an event queue overflows. Pick the fine-point brush. Move the mouse quickly in a circle, trying to trace over your path. I see a decent curve for about 40 degrees of the circle, then a straight line cutting across the circle for about 80 degrees. This repeats, giving me what looks like triangles with chewed-off corners. Quickly drawing a curly thing will also show it well. The gimp does not suffer from this. I already tried turning off sound. It didn't help. I see this on two machines: 1. 450 Mhz Mac G4 Cube with a USB mouse 2. the OLPC XO-1, B4 hardware revision In both cases I'm running at 1200x900. |
|
From: Pere P. i C. <pe...@fo...> - 2007-12-31 15:47:07
|
On Mon, 2007-12-31 at 14:24 +0100, tor...@at... wrote: > There are some stamps where you can change the color. They are (unless > something has changed lately) heavy on the processor. There are two kinds of thoose stamps: colorable and tintable tintable are as you say heavy on processor. colorable are light on processor and disckspace, some of them can be better compressed thought if they were a transparency over a full black layer like stamps/symbols/shapes/pawprint.png instead a transparency over a draw like stamps/symbols/alphabets/asl/asl_a.png The gain on disckspace when compressing will be about 10% for each image. Not sure if this gain will be seen in memory usage as tuxpaint takes just the alpha channel of colorable images. > Kind regards, > Tore Yours Pere |
|
From: <tor...@at...> - 2007-12-31 13:24:05
|
Is SVG supported on the XO-1? Those stamp files should at least be small. There are some stamps where you can change the color. They are (unless something has changed lately) heavy on the processor. They should probably be removed for the XO-1. The stamp problem really isn't just a problem for the XO-1. It would be nice to limit the number of stamps to specific themes before the children get an exercise. Underwater air planes are probably cool, but not necessarily what the teacher is lookin for :-) Maybe a good solution would be to look for stamps both at the local computer and at a local server? And a program to delete stamps and load stamps from the web? Then the teacher could download the stamps they need, and all the children would get them from the local server? Kind regards, Tore |
|
From: Albert C. <aca...@gm...> - 2007-12-30 20:06:18
|
On Dec 30, 2007 6:20 AM, Caroline Ford <car...@go...> wrote: > On Sat, 2007-12-29 at 14:14 -0500, Albert Cahalan wrote: > > On Dec 29, 2007 1:50 PM, Bill Kendrick <nb...@so...> wrote: > > > On Sat, Dec 29, 2007 at 03:03:50AM -0500, Albert Cahalan wrote: > > > > Tux Paint has an excess of low-quality brushes, stamps, > > > > and magic tools. Perhaps a disinterested 3rd party should > > > > tell us what to throw away. > > > > > > I'm happy leaving it to you to decide. > > > > I'm sure! Throwing away somebody else's stuff is a > > great source of conflict. Some of my own stuff might > > even need to go; will I be too lenient or too harsh? > > Arrgh. How do you know we have too much stuff? I've been making things > like brushes and stamps presuming that we can never really have too > much. I mostly don't think there is too much. There are numerous low-resolution stamps. There are stamps that duplicate functionality of the text tool. Making the user scroll past dozens of undesirable stamps is not nice. The brush situation is getting weird. Many of the new brushes can only be properly used as stamps. > Is this just a packaging problem? There is a bug/complaint on the Ubuntu > bug tracker that -stamps is too big and a request that we split it into > -stamps-default and stamps-*. That sure wouldn't help me with the Sugar port. I have to merge the stamps collection into the same package as the program. Size is an issue for me, but I realize that the Sugar port is not normal. I suggest closing the bug/complaint about package size. Ubuntu is targeted toward normal desktop systems. My main concern is that the user may have trouble finding the best stuff in a sea of lesser stuff. It's not just stamps. It's magic tools, and, well, everything. > Would this help or do you think we need to > find an uninterested party? We could try and find some way of doing > community blood letting but I'm sure I can be as possessive about my > stuff as anyone else.. Maybe I can talk Eben (OLPC UI designer) into looking at things. Maybe the web site could poll users for their favorite stuff. Maybe we should have the program send back some feedback data about tool usage; this was done recently for the gimp. (careful: there will naturally be a bias toward things that are at the top of the list) |
|
From: Bill K. <nb...@so...> - 2007-12-30 19:29:13
|
On Tue, Dec 18, 2007 at 11:46:18PM +0000, Caroline Ford wrote: > In Ubuntu-land -config is in universe (ie an extra optional thing to > install) and tuxpaint proper is in main (because it is installed by > default in Edubuntu). This means that the vast majority of users won't > touch or install -config. BTW, FWIW, the main Tux Paint manpage mentions that --sysfonts can "cause trouble." -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Bill K. <nb...@so...> - 2007-12-30 19:26:53
|
On Sun, Dec 30, 2007 at 11:20:05AM +0000, Caroline Ford wrote: > Arrgh. How do you know we have too much stuff? I've been making things > like brushes and stamps presuming that we can never really have too > much. Well, remember he's on a much more restrictive environment, being on the XO-1. (Extremely reduced RAM and filespace, compared to a 'normal' modern desktop or laptop.) > Is this just a packaging problem? In terms of stamps, we could suggest installing only certain categories, but that really doesn't cover "high quality" (high rez, good photo or art quality) versus "lower quality" (low rez, bad photo, not the best art, etc.) > There is a bug/complaint on the Ubuntu bug tracker that -stamps is > too big and a request that we split it into -stamps-default and > stamps-*. Would this help or do you think we need to find an > uninterested party? We could try and find some way of doing > community blood letting but I'm sure I can be as possessive about my > stuff as anyone else.. Are the Ubuntu folks against simply having separate stamp packages based on the various Makefile targets? Shin-Ichi has been building separate RPM packages for stamps, based on that. Therefore, not "default" and "other", but separate packages for the whole gamut: animals, vehicles, hobbies, seasonal, etc... Maybe I'll go see if I can suggest that in that bug. :) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Caroline F. <car...@go...> - 2007-12-30 11:15:14
|
On Sat, 2007-12-29 at 14:14 -0500, Albert Cahalan wrote: > On Dec 29, 2007 1:50 PM, Bill Kendrick <nb...@so...> wrote: > > On Sat, Dec 29, 2007 at 03:03:50AM -0500, Albert Cahalan wrote: > > > First of all, it runs. > > > http://wiki.laptop.org/go/Tux_Paint > > > > Awesome. Is it worth mirroring the binary over on SF.net and adding an XO > > page to the main TP website? (I'd of course link to the wiki there, too.) > > I doubt it, as I'm likely to be making updates soonish. > Am I able to update files on the website? > > Definitely add a link. > > > > Tux Paint has an excess of low-quality brushes, stamps, > > > and magic tools. Perhaps a disinterested 3rd party should > > > tell us what to throw away. > > > > I'm happy leaving it to you to decide. > > I'm sure! Throwing away somebody else's stuff is a > great source of conflict. Some of my own stuff might > even need to go; will I be too lenient or too harsh? Arrgh. How do you know we have too much stuff? I've been making things like brushes and stamps presuming that we can never really have too much. Is this just a packaging problem? There is a bug/complaint on the Ubuntu bug tracker that -stamps is too big and a request that we split it into -stamps-default and stamps-*. Would this help or do you think we need to find an uninterested party? We could try and find some way of doing community blood letting but I'm sure I can be as possessive about my stuff as anyone else.. Caroline |
|
From: Albert C. <aca...@gm...> - 2007-12-29 19:36:53
|
On Dec 29, 2007 2:22 PM, Bill Kendrick <nb...@so...> wrote: > Well, I mirrored the current rev, and put a page up. I'm happy to update > SF.net as new releases come out. Any reason for the '-1' version #? > Is that an XO requirement? It is a requirement, though perhaps poorly-defined. It's the revision number. There is another number, or maybe the same number, used to version over-the-network interfaces for shared activities. I'll have to clarify that before I make another *.xo file. |
|
From: Bill K. <nb...@so...> - 2007-12-29 19:22:22
|
On Sat, Dec 29, 2007 at 02:14:48PM -0500, Albert Cahalan wrote:
>
> I doubt it, as I'm likely to be making updates soonish.
> Am I able to update files on the website?
The website is in CVS ("tuxpaint-website" module), but the live version
would of course need to be brought up to date, as it lives on my server.
> Definitely add a link.
Well, I mirrored the current rev, and put a page up. I'm happy to update
SF.net as new releases come out. Any reason for the '-1' version #?
Is that an XO requirement?
<snip>
> > I'm happy leaving it to you to decide.
>
> I'm sure! Throwing away somebody else's stuff is a
> great source of conflict. Some of my own stuff might
> even need to go; will I be too lenient or too harsh?
The curse of the volunteer! ;) _I'm_ certainly not a disinterested party.
Blah.
<snip>
> > Why did the XO build not find them?
>
> I have no idea, except that paths are weird.
Likely. Ok.
> It's not nice having this switch at all. I can see a need
> to limit the number of system fonts in case there is not
> enough memory. If crashes are the problem, I could add
> some crash protection on systems with fork().
As you wish! :)
--
-bill!
bi...@ne...
http://www.newbreedsoftware.com/
|
|
From: Albert C. <aca...@gm...> - 2007-12-29 19:14:44
|
On Dec 29, 2007 1:50 PM, Bill Kendrick <nb...@so...> wrote: > On Sat, Dec 29, 2007 at 03:03:50AM -0500, Albert Cahalan wrote: > > First of all, it runs. > > http://wiki.laptop.org/go/Tux_Paint > > Awesome. Is it worth mirroring the binary over on SF.net and adding an XO > page to the main TP website? (I'd of course link to the wiki there, too.) I doubt it, as I'm likely to be making updates soonish. Am I able to update files on the website? Definitely add a link. > > Tux Paint has an excess of low-quality brushes, stamps, > > and magic tools. Perhaps a disinterested 3rd party should > > tell us what to throw away. > > I'm happy leaving it to you to decide. I'm sure! Throwing away somebody else's stuff is a great source of conflict. Some of my own stuff might even need to go; will I be too lenient or too harsh? > > Why is sysfonts off by default? I had **NO** fonts on > > the OLPC XO until I enabled sysfonts. > > Tux Paint ships with a handful of fonts that (should, at least) work. > (The stuff in data/fonts/) > > Why did the XO build not find them? I have no idea, except that paths are weird. It's not nice having this switch at all. I can see a need to limit the number of system fonts in case there is not enough memory. If crashes are the problem, I could add some crash protection on systems with fork(). |
|
From: Bill K. <nb...@so...> - 2007-12-29 18:50:43
|
On Sat, Dec 29, 2007 at 03:03:50AM -0500, Albert Cahalan wrote: > First of all, it runs. > http://wiki.laptop.org/go/Tux_Paint Awesome. Is it worth mirroring the binary over on SF.net and adding an XO page to the main TP website? (I'd of course link to the wiki there, too.) > I will need to fix the Makefile. Much breakage is likely; > I hope that won't affect anybody. <snip> Well, ping us when you've committed something, so we can all test it. <snip> > Tux Paint has an excess of low-quality brushes, stamps, > and magic tools. Perhaps a disinterested 3rd party should > tell us what to throw away. I'm happy leaving it to you to decide. > Why is sysfonts off by default? I had **NO** fonts on > the OLPC XO until I enabled sysfonts. Tux Paint ships with a handful of fonts that (should, at least) work. (The stuff in data/fonts/) Why did the XO build not find them? > The *.so files are bad. They aren't built with -fPIC or -fpic. > Run-time relocation is required. At best, this will slow the > start-up time and eat memory. On some SE Linux setups, > Tux Paint will need special security-override markings just > to run. Adding -fpic via a Makefile variable. Like I said, we can look into building them directly into Tux Paint itself, as an option (which'd be a default for some platforms, like the XO). -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Albert C. <aca...@gm...> - 2007-12-29 08:03:44
|
First of all, it runs. http://wiki.laptop.org/go/Tux_Paint I will need to fix the Makefile. Much breakage is likely; I hope that won't affect anybody. Currently there is no working DESTDIR support; the PKG_ROOT and PREFIX stuff is somehow broken. This causes the difficult install process; paths in the binary start off with "../TuxPaint.activity/" instead of "./" or nothing. Setting VIDEO_BPP to anything other than 32 will break both stamps and fonts. I guess grass and other tools break as well. Maybe just give up on this one; it would simplify things. Tux Paint has an excess of low-quality brushes, stamps, and magic tools. Perhaps a disinterested 3rd party should tell us what to throw away. Why is sysfonts off by default? I had **NO** fonts on the OLPC XO until I enabled sysfonts. The *.so files are bad. They aren't built with -fPIC or -fpic. Run-time relocation is required. At best, this will slow the start-up time and eat memory. On some SE Linux setups, Tux Paint will need special security-override markings just to run. |
|
From: Caroline F. <car...@go...> - 2007-12-18 23:32:08
|
On Mon, 2007-12-17 at 08:44 -0800, Bill Kendrick wrote: > On Mon, Dec 17, 2007 at 12:59:07AM +0000, Caroline Ford wrote: > > My concern is making a package that doesn't have a fix for the >127 > > fonts bug, and whether this is worse or better than leaving it at > > 0.9.17. > > I'm not 100% certain, but I'm pretty sure the bug's been around longer > than just 0.9.18. :) Additionally, this affects people when "Use System Fonts" > is enabled, and we actually say, in Tux Paint Config's GUI, that this option > may cause instability. So this doesn't affect normal installs? In Ubuntu-land -config is in universe (ie an extra optional thing to install) and tuxpaint proper is in main (because it is installed by default in Edubuntu). This means that the vast majority of users won't touch or install -config. If normal user installing Edubuntu from the CD isn't affected then I don't think I care that much. I've emailed the Ubuntu-devel-discuss mailing list to ask them what they think. Caroline |
|
From: Bill K. <nb...@so...> - 2007-12-17 16:44:07
|
On Mon, Dec 17, 2007 at 12:59:07AM +0000, Caroline Ford wrote: > My concern is making a package that doesn't have a fix for the >127 > fonts bug, and whether this is worse or better than leaving it at > 0.9.17. I'm not 100% certain, but I'm pretty sure the bug's been around longer than just 0.9.18. :) Additionally, this affects people when "Use System Fonts" is enabled, and we actually say, in Tux Paint Config's GUI, that this option may cause instability. > I don't know how to make a tuxpaint-devel package. If someone does it > I'm sure we can argue for it to be included. I think all we need out of it is: Config script (similar to sdl-config, gtk-config, etc.): /usr/bin/tp-magic-config Man page: /usr/share/man/man1/tp-magic-config.1.gz API header file: /usr/include/tuxpaint/tp_magic_api.h Documentation (directory): /usr/share/doc/tuxpaint-dev/ Dependency-wise, we obviously recommend 'tuxpaint', and we require 'libsdl-dev' and 'libsdl-mixer1.2-dev', and I think that's it. (Based on what tp_magic_api.h #includes.) Ben, you around? -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Bill K. <nb...@so...> - 2007-12-17 16:38:26
|
On Mon, Dec 17, 2007 at 12:29:39AM +0000, Caroline Ford wrote: > On Sun, 2007-12-16 at 16:12 -0800, Bill Kendrick wrote: > > > > > SDL_pango is, unfortunately, not being used with the Text Tool at the moment. > > I still need to figure out how, if at all, that would be possible. > > I may need to use Pango directly. > > It's a build dependency though, and stops 0.9.18 running on slightly > older systems such as Ubuntu dapper. What's it being used for? SDL_pango is being used to render the UI text (prompts, button labels, etc.) SDL_ttf was simply not robust enough to handle the more complex languages, like Telugu or Arabic. You can build _without_ Pango, though. Shin-Ichi did this for older Fedoras. John is going to do it for older Windowses. Check INSTALL.txt. :) -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
49 messages has been excluded from this view by a project administrator.
