Thread: Re: [Tuxpaint-devel] Tux Paint 0.9.16 build for Mac OS X? (Page 2)
An award-winning drawing program for children of all ages
Brought to you by:
wkendrick
Menu
▾
▴
tuxpaint-devel
|
From: Martin F. <mf...@gm...> - 2006-09-19 05:01:05
|
Hi Bill and Matthew, > iPhoto Diet? What's that? It's something like Atkin's diet, but for photos. ;-) It's an open source duplicate-photo remover I've been developing for a few years. Unfortunately it breaks every time Apple releases a major upgrade to iPhoto, so I'm kept busy upgrading it about once a year. > >> so I haven't been able to contribute anything to Tux Paint. I'd be >> happy to compile the latest rc1 or rc2 sometime this week. > > Great, thanks! I'm sure I can find some Mac users out there (along > with > myself, with this PPC-style Mac Mini I have) who can test. > > Would you be able to build a binary that runs native on Intel, too? Yes, I will look into making a Universal binary (PPC/Intel). The SDL libraries are already universal, so the frameworks just need to be included in the TuxPaint application bundle. I'll have to compile libiconv, libintl, and libpng as universal libraries, and link those in - provided this goes alright, we should be in business. We have to keep in mind that universal binary apps need to be compiled with gcc 4, and gcc 4 compiled apps typically require Mac OS X 10.3.9 or later to run (so a universal binary that also runs on 10.2.8 is most likely not possible). > >> This will probably be after the >> 0.9.16 release, however, so by all means, if you'd like to resolve >> these bugs beforehand, feel free to invite another OS X developer on >> board! I'll be happy to contribute what I can when time permits :-) > > I think it can be okay to release 0.9.16 for Mac later, or perhaps > call it 0.9.17, depending on how much has to change before it works... Okay, we'll see how things develop in the coming weeks... > Of course, with Windows, we release _both_ EXE installers _and_ ZIP > archives, > so it may make sense to similarly provide both PKG and DMG versions > for Mac > users. I think it's better just to stick with the disk image DMG version. PKG installers are useful if the program has multiple files that need to be installed in various locations on a user's drive, but because Tux Paint has been bundled into a single "file" (the "Tux Paint.app" bundle) that the user can drag from the disk image to any location on the hard drive, a PKG installer would be redundant. > I am willing to help out when I can. I really do not have much > development skills. However, I am willing to test compiling in xcode > and testing. I am pretty good at making .pkg package / installer > files (actually certified on it). > If Martin can help me out with > some pointers on using xcode I am sure it would help too. Sure, Matt, I'd be happy to show you through compiling the Tux Paint in XCode. Perhaps we can discuss this in couple weeks, once I am able to free up a bit more time. You can also catch me on iChat <mf...@ma...> Best regards, Martin |
|
From: Bill K. <nb...@so...> - 2006-09-19 05:16:47
|
On Mon, Sep 18, 2006 at 10:59:15PM -0600, Martin Fuhrer wrote:
> Yes, I will look into making a Universal binary (PPC/Intel). The SDL
> libraries are already universal, so the frameworks just need to be
> included in the TuxPaint application bundle. I'll have to compile
> libiconv, libintl, and libpng as universal libraries, and link those
> in - provided this goes alright, we should be in business. We have
> to keep in mind that universal binary apps need to be compiled with
> gcc 4, and gcc 4 compiled apps typically require Mac OS X 10.3.9 or
> later to run (so a universal binary that also runs on 10.2.8 is most
> likely not possible).
Hrm, would it be a huge pain to produce two versions of Tux Paint,
at least for a while? One universal binary for 10.3.9 and above, and
a version that's more compatible with 10.2.8...?
I now realize how insanely expensive commercial operating systems can be,
and can understand parents and schools still using the older platforms.
(It still works, right!? :^) )
<snip>
> Okay, we'll see how things develop in the coming weeks...
:^)
<snip>
> I think it's better just to stick with the disk image DMG version.
> PKG installers are useful if the program has multiple files that need
> to be installed in various locations on a user's drive, but because
> Tux Paint has been bundled into a single "file" (the "Tux Paint.app"
> bundle) that the user can drag from the disk image to any location on
> the hard drive, a PKG installer would be redundant.
Okay! ("not broken, don't fix it"... sounds good :^) )
<snip>
> Sure, Matt, I'd be happy to show you through compiling the Tux Paint
> in XCode. Perhaps we can discuss this in couple weeks, once I am able
> to free up a bit more time. You can also catch me on iChat
> <mf...@ma...>
I've also seen Matthew on freenode. :)
--
-bill!
bi...@ne...
http://www.newbreedsoftware.com/
|
|
From: Martin F. <mf...@gm...> - 2006-10-12 01:46:05
|
I had some time last night to put together a universal binary of Tux
Paint 0.9.16rc2. It compiles :-) but doesn't run :-( I'm getting
the following error:
Error: I couldn't load a graphics file:
Tux Paint.app/Contents/Resources/brushes//kuroneko.dat
The Simple DirectMedia Layer error that occurred was:
Unsupported image format
I presume kurenko.dat is an image file, and I've checked that I
linked against SDL 1.2.11 and SDL Image 1.2.5, which I believe are
the latest versions. Any ideas?
Martin
On 18-Sep-06, at 11:16 PM, Bill Kendrick wrote:
> On Mon, Sep 18, 2006 at 10:59:15PM -0600, Martin Fuhrer wrote:
>> Yes, I will look into making a Universal binary (PPC/Intel). The SDL
>> libraries are already universal, so the frameworks just need to be
>> included in the TuxPaint application bundle. I'll have to compile
>> libiconv, libintl, and libpng as universal libraries, and link those
>> in - provided this goes alright, we should be in business. We have
>> to keep in mind that universal binary apps need to be compiled with
>> gcc 4, and gcc 4 compiled apps typically require Mac OS X 10.3.9 or
>> later to run (so a universal binary that also runs on 10.2.8 is most
>> likely not possible).
>
> Hrm, would it be a huge pain to produce two versions of Tux Paint,
> at least for a while? One universal binary for 10.3.9 and above, and
> a version that's more compatible with 10.2.8...?
>
> I now realize how insanely expensive commercial operating systems
> can be,
> and can understand parents and schools still using the older
> platforms.
> (It still works, right!? :^) )
>
> <snip>
>> Okay, we'll see how things develop in the coming weeks...
>
> :^)
>
>
> <snip>
>> I think it's better just to stick with the disk image DMG version.
>> PKG installers are useful if the program has multiple files that need
>> to be installed in various locations on a user's drive, but because
>> Tux Paint has been bundled into a single "file" (the "Tux Paint.app"
>> bundle) that the user can drag from the disk image to any location on
>> the hard drive, a PKG installer would be redundant.
>
> Okay! ("not broken, don't fix it"... sounds good :^) )
>
>
> <snip>
>> Sure, Matt, I'd be happy to show you through compiling the Tux Paint
>> in XCode. Perhaps we can discuss this in couple weeks, once I am able
>> to free up a bit more time. You can also catch me on iChat
>> <mf...@ma...>
>
> I've also seen Matthew on freenode. :)
>
>
> --
> -bill!
> bi...@ne...
> http://www.newbreedsoftware.com/
>
> ----------------------------------------------------------------------
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
> share your
> opinions on IT & business topics through brief surveys -- and earn
> cash
> http://www.techsay.com/default.php?
> page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> Tuxpaint-devel mailing list
> Tux...@li...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
|
|
From: Bill K. <nb...@so...> - 2006-10-12 01:51:50
|
On Wed, Oct 11, 2006 at 07:45:56PM -0600, Martin Fuhrer wrote:
> I had some time last night to put together a universal binary of Tux
> Paint 0.9.16rc2. It compiles :-) but doesn't run :-( I'm getting
> the following error:
>
> Error: I couldn't load a graphics file:
> Tux Paint.app/Contents/Resources/brushes//kuroneko.dat
> The Simple DirectMedia Layer error that occurred was:
> Unsupported image format
>
> I presume kurenko.dat is an image file,
No, it is a text file describing some details about the "kuroneko.png"
brush image. (Most brushes do not have corresponding .dat files, but
this one, and some others, do.)
Now, why it's trying to load the .dat file as a PNG is confusing, because
it should skip it.
Line 5627 of tuxpaint.c:
if (strcasestr(files[i].str, ".png"))
(It's an implicit test of "!= NULL" there, btw.)
> and I've checked that I
> linked against SDL 1.2.11 and SDL Image 1.2.5, which I believe are
> the latest versions. Any ideas?
See if strcasestr is working right? :)
Thx!
-bill!
|
|
From: Bill K. <nb...@so...> - 2006-10-12 01:53:05
|
On Wed, Oct 11, 2006 at 07:45:56PM -0600, Martin Fuhrer wrote: > I had some time last night to put together a universal binary of Tux > Paint 0.9.16rc2. It compiles :-) but doesn't run :-( I'm getting > the following error: <snip> Oh, and in the meantime, try moving all of the ".dat" files out of the way, just to see if Tux Paint runs. Those specific brushes will not look right, nor work they way they should (e.g., animated and/or directional), but otherwise things should work. Feel free to see if all ~70 locales are rendering properly, too. ;^D (My wrist hurts after doing that _twice_ just now under WinXP :^( ) THx! -bill! |
|
From: Martin F. <mf...@gm...> - 2006-10-12 02:52:21
|
>
> Now, why it's trying to load the .dat file as a PNG is confusing,
> because
> it should skip it.
>
> Line 5627 of tuxpaint.c:
>
> if (strcasestr(files[i].str, ".png"))
>
> (It's an implicit test of "!= NULL" there, btw.)
>
>
>> and I've checked that I
>> linked against SDL 1.2.11 and SDL Image 1.2.5, which I believe are
>> the latest versions. Any ideas?
>
> See if strcasestr is working right? :)
Aha, that's the problem. I didn't compile with -DHAVE_STRCASESTR, so
TuxPaint's custom strcasestr() is being called. I had to change the
return statement from
return (result - uphaystack + (char *) haystack);
to:
if (result != NULL)
return (result - uphaystack + (char *) haystack);
else
return NULL;
and now everything runs fine. I still have to clean up a couple
things and then I'll get a disk image posted.
Martin
|
|
From: Bill K. <nb...@so...> - 2006-10-12 07:33:36
|
On Wed, Oct 11, 2006 at 08:52:13PM -0600, Martin Fuhrer wrote: > Aha, that's the problem. I didn't compile with -DHAVE_STRCASESTR, so > TuxPaint's custom strcasestr() is being called. I had to change the > return statement from > > return (result - uphaystack + (char *) haystack); > > to: > > if (result != NULL) > return (result - uphaystack + (char *) haystack); > else > return NULL; > > and now everything runs fine. I still have to clean up a couple > things and then I'll get a disk image posted. I've applied this change to CVS, too. Thanks! Glad to hear it's working, can't wait to give it a try! -bill! |
|
From: Martin F. <mf...@gm...> - 2006-10-12 03:13:11
|
The eraser tool leaves ghosted bounding rectangles behind as I drag it across the canvas. Is this a known bug? http://pages.cpsc.ucalgary.ca/~fuhrer/temp/tuxPaintEraser.jpg Martin On 11-Oct-06, at 7:53 PM, Bill Kendrick wrote: > On Wed, Oct 11, 2006 at 07:45:56PM -0600, Martin Fuhrer wrote: >> I had some time last night to put together a universal binary of Tux >> Paint 0.9.16rc2. It compiles :-) but doesn't run :-( I'm getting >> the following error: > <snip> > > Oh, and in the meantime, try moving all of the ".dat" files out of the > way, just to see if Tux Paint runs. Those specific brushes will not > look right, nor work they way they should (e.g., animated and/or > directional), > but otherwise things should work. > > Feel free to see if all ~70 locales are rendering properly, too. ;^D > (My wrist hurts after doing that _twice_ just now under WinXP :^( ) > > THx! > > -bill! > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: Bill K. <nb...@so...> - 2006-10-12 07:41:06
|
On Wed, Oct 11, 2006 at 09:13:02PM -0600, Martin Fuhrer wrote: > The eraser tool leaves ghosted bounding rectangles behind as I drag > it across the canvas. Is this a known bug? > http://pages.cpsc.ucalgary.ca/~fuhrer/temp/tuxPaintEraser.jpg This does not seem to happen on x86 Linux or Windows. I've expanded the screen refresh by 1px on each side, in case there's some math difference going on when it determines how big the XOR was that needs to be drawn. I'm committing to CVS now. Did this not happen on Tux Paint 0.9.15? I don't rememebr it... :^/ -bill! |
|
From: Bill K. <nb...@so...> - 2006-10-12 07:41:26
|
On Wed, Oct 11, 2006 at 09:13:02PM -0600, Martin Fuhrer wrote: > The eraser tool leaves ghosted bounding rectangles behind as I drag > it across the canvas. Is this a known bug? > http://pages.cpsc.ucalgary.ca/~fuhrer/temp/tuxPaintEraser.jpg Oh, also, is it just the round erasers? Or the square ones? (That's the big diff between 0.9.15 and 0.9.16) -bill! |
|
From: Martin F. <mf...@gm...> - 2006-10-12 13:39:36
|
The ghosting happens with both round and square erasers. When I let go of the mouse and drag the eraser tool over the ghosted lines, or when I move another window over Tux Paint and move it off again, the ghosting disappears, so it does appear to be a refresh issue. The problem does not appear in Tux Paint 0.9.15. I'll try out the latest sources tonight. Martin On 12-Oct-06, at 1:41 AM, Bill Kendrick wrote: > On Wed, Oct 11, 2006 at 09:13:02PM -0600, Martin Fuhrer wrote: >> The eraser tool leaves ghosted bounding rectangles behind as I drag >> it across the canvas. Is this a known bug? >> http://pages.cpsc.ucalgary.ca/~fuhrer/temp/tuxPaintEraser.jpg > > Oh, also, is it just the round erasers? Or the square ones? > (That's the big diff between 0.9.15 and 0.9.16) > > -bill! > > ---------------------------------------------------------------------- > --- > Using Tomcat but need to do more? Need to support web services, > security? > Get stuff done quickly with pre-integrated technology to make your > job easier > Download IBM WebSphere Application Server v.1.0.1 based on Apache > Geronimo > http://sel.as-us.falkag.net/sel? > cmd=lnk&kid=120709&bid=263057&dat=121642 > _______________________________________________ > Tuxpaint-devel mailing list > Tux...@li... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: Albert C. <aca...@gm...> - 2006-10-15 22:33:58
|
> > Would you be able to build a binary that runs native on Intel, too? > > Yes, I will look into making a Universal binary (PPC/Intel). The SDL > libraries are already universal, so the frameworks just need to be > included in the TuxPaint application bundle. I'll have to compile > libiconv, libintl, and libpng as universal libraries, and link those > in - provided this goes alright, we should be in business. We have > to keep in mind that universal binary apps need to be compiled with > gcc 4, and gcc 4 compiled apps typically require Mac OS X 10.3.9 or > later to run (so a universal binary that also runs on 10.2.8 is most > likely not possible). I think you can do this: 1. compile the ppc version with the old tools 2. compile the x86 version with the new tools 3. use the new tools (lipo?) to join them into a universal binary If you do end up with two separate installs, there isn't much point in doing a universal binary. |
|
From: Martin F. <mf...@gm...> - 2006-10-18 05:54:55
|
On 17-Oct-06, at 4:59 AM, Mark K. Kim wrote: > On Mon, Oct 16, 2006 at 09:41:55PM -0600, Martin Fuhrer wrote: > >> Hmm... including SDL_ttf 2.0.6 doesn't help.* I also ran Tux >> Paint 0.9.14 >> and 0.9.15 and I also get the squares with the Korean language >> selected, >> so the problem may have been around for quite a while on the >> Mac side of >> things.** > > Oh no... Thank you for looking into this, as I have no Mac to test it > out on myself! Actually, scratch the foreign font problems. XCode was bundling the .ttf fonts incorrectly, so Tux Paint was unable to load them. I've fixed the XCode project (can't believe I didn't notice this problem in the earlier Tux Paint versions!), and Chinese Traditional and Japanese fonts now work fine. Tux Paint is still displaying squares for Korean and Chinese Simplified fonts - however, this appears to be because the required fonts (ko.ttf and zh_cn.ttf) are missing from my CVS workspace (presumably, they should be in the fonts/locale directory along with the other foreign fonts). Are these fonts available anywhere? Martin |
|
From: Bill K. <nb...@so...> - 2006-10-18 07:12:35
|
On Tue, Oct 17, 2006 at 11:53:33PM -0600, Martin Fuhrer wrote: > > Actually, scratch the foreign font problems. XCode was bundling > the .ttf fonts incorrectly, so Tux Paint was unable to load them. > I've fixed the XCode project (can't believe I didn't notice this > problem in the earlier Tux Paint versions!), and Chinese Traditional > and Japanese fonts now work fine. Tux Paint is still displaying > squares for Korean and Chinese Simplified fonts - however, this > appears to be because the required fonts (ko.ttf and zh_cn.ttf) are > missing from my CVS workspace (presumably, they should be in the > fonts/locale directory along with the other foreign fonts). Are > these fonts available anywhere? They are not in the main Tux Paint project, because they are too large. You can download them from here: http://www.tuxpaint.org/download/fonts/ :) Thx! -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Martin F. <mf...@gm...> - 2006-10-15 23:25:35
|
On 15-Oct-06, at 4:33 PM, Albert Cahalan wrote: >>> Would you be able to build a binary that runs native on Intel, too? >> >> Yes, I will look into making a Universal binary (PPC/Intel). The SDL >> libraries are already universal, so the frameworks just need to be >> included in the TuxPaint application bundle. I'll have to compile >> libiconv, libintl, and libpng as universal libraries, and link those >> in - provided this goes alright, we should be in business. We have >> to keep in mind that universal binary apps need to be compiled with >> gcc 4, and gcc 4 compiled apps typically require Mac OS X 10.3.9 or >> later to run (so a universal binary that also runs on 10.2.8 is most >> likely not possible). > > I think you can do this: > > 1. compile the ppc version with the old tools > 2. compile the x86 version with the new tools > 3. use the new tools (lipo?) to join them into a universal binary > > If you do end up with two separate installs, there isn't much > point in doing a universal binary. I have universal binaries working (I'll get them posted tonight for public testing). In short, to compile universal binaries of libraries with configure scripts, I did the following: > setenv CFLAGS '-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386'' > setenv CXXFLAGS '-isysroot /Developer/SDKs/MacOSX10.4u.sdk -arch ppc -arch i386' > setenv LDFLAGS '-Wl,-syslibroot,/Developer/SDKs/MacOSX10.4u.sdk - arch ppc -arch i386' > ./configure > make Both ppc and x86 object files and libraries are generated and "lipoed" together into universal libraries. To check the architecture of a library file, I run: > lipo -info libiconv.a Architectures in the fat file: libiconv.a are: i386 ppc For libraries without configure scripts (eg. libpng), I first ran make to build the ppc library, and copied it into a "ppc" directory. I then manually edited the makefiles to include the "-arch i386" compiler flag, ran make to build the x86 library, and copied it into an "i386" directory. Finally, I ran lipo as follows: > lipo -create i386/libpng.a ppc/libpng.a -output libpng.a In the TuxPaint XCode project, I turned on the Intel and PPC options and selected the Mac OS X 10.4u SDK (see the Read Me in the XCode project), and compiled the app. Martin |
|
From: Bill K. <nb...@so...> - 2006-10-15 23:43:16
|
On Sun, Oct 15, 2006 at 05:25:21PM -0600, Martin Fuhrer wrote: > > I have universal binaries working (I'll get them posted tonight for > public testing). BTW, I've just put 0.9.16rc6 (see an upcoming post) on my FTP site, which incorporates all of the OSX changes you made to CVS since rc5. Thx! <snip> > In the TuxPaint XCode project, I turned on the Intel and PPC options > and selected the Mac OS X 10.4u SDK (see the Read Me in the XCode > project), and compiled the app. How much bigger will a Universal Binary be, compared to a PPC-only and an x86-only binary? Also, any chance of Tux Paint 0.9.16 running on OS X 10.2.8? Last I heard (last year after 0.9.15 was released), many people were still using that version on their Macs. (Presumably, mostly schools w/ tight budgets.) So... it's pretty important to me that we support it. (Hell, I still want to see Tux Paint on OS 9 some day, but... :) ) Thx! -- -bill! bi...@ne... http://www.newbreedsoftware.com/ |
|
From: Martin F. <mf...@gm...> - 2006-10-16 01:20:29
|
I've posted the Mac OS X Tux Paint 0.9.16rc5 builds here: www.cpsc.ucalgary.ca/~fuhrer/temp/tuxpaint-0.9.16rc5-macosx.dmg www.cpsc.ucalgary.ca/~fuhrer/temp/tuxpaintstamps-2006.10.12-macosx.dmg They are compiled as universal binary, though because I only have a PowerPC Mac, it would be nice if someone with an Intel-based Mac could test these and make sure they run fine. The eraser ghosted lines problem still exists. I've noticed that this problem only exists in windowed mode; if Tux Paint runs fullscreen, the problem is gone... Could this be an SDL problem? > > How much bigger will a Universal Binary be, compared to a PPC-only > and an x86-only binary? For the Tux Paint application bundle (binaries + resources): Tux Paint 0.9.16 PPC: 13 MB Tux Paint 0.9.16 Universal: 13.3 MB So a fairly negligible size difference. Mind you, the PPC application bundle contains the universal binary SDL frameworks, so these will definitely add some disk space in terms of x86 code. The 0.3 MB size increase in the universal is due to the x86 Tux Paint code, plus the x86 code linked in from the static libraries libpng.a, libiconv.a, and libintl.a. > Also, any chance of Tux Paint 0.9.16 running on OS X 10.2.8? > Last I heard (last year after 0.9.15 was released), many people were > still using that version on their Macs. (Presumably, mostly > schools w/ > tight budgets.) > > So... it's pretty important to me that we support it. I have read recently that it actually is possible to create a universal binary app that supports OS X 10.2.8, but I'm not certain as to how this is done. I might have to peruse some developer forums for more information about this - but I have a feeling there are some tricks and caveats involved (Apple's stance is that universal binaries require OS X 10.3.9 or newer)... It is definitely possible to build a PowerPC-only app that supports OS X 10.2.8 and up (this would be distributed alongside the universal binary version of Tux Paint), but I ran into some odd compile errors when I tried this earlier in the year. I can revisit this, but the next few weeks are busy for me, so it won't be for a while (I also have to visit some of the longstanding Mac OS X bug reports for Tux Paint). Martin |
|
From: Bill K. <nb...@so...> - 2006-10-16 21:48:23
|
On Sun, Oct 15, 2006 at 07:20:15PM -0600, Martin Fuhrer wrote: > I've posted the Mac OS X Tux Paint 0.9.16rc5 builds here: > > www.cpsc.ucalgary.ca/~fuhrer/temp/tuxpaint-0.9.16rc5-macosx.dmg > www.cpsc.ucalgary.ca/~fuhrer/temp/tuxpaintstamps-2006.10.12-macosx.dmg Oh yeah, do you think you'd be able to provide a checkbox interface in the installer, like we have for Windows? Or, alternatively, could you provide separate stamps DMGs, one for each category? (Like we have for RPM packages.) Thx! -bill! |
Thanks for helping keep SourceForge clean.
X