Thread: [Tuxpaint-devel] the Sugar port
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel
|
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: 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 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 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: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: 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: 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: 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: <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: 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: 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: 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 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 |
Thanks for helping keep SourceForge clean.
X