Thanks for helping keep SourceForge clean.
Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
Tux Paint
An award-winning drawing program for children ages 3 to 12
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
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Bill Kendrick <nbs@so...> - 2017-06-15 19:49:31
|
----- Forwarded message from Bill Kendrick <nbs@...> ----- Date: Wed, 14 Jun 2017 23:36:10 -0700 From: Bill Kendrick <nbs@...> Subject: [Tuxpaint-users] Tux Paint's turning 15! To: Tux Paint Users <tuxpaint-users@...> Reply-To: Discussion list for parents and teachers using Tux Paint <tuxpaint-users@...> It's hard to believe it, but Tux Paint is turning 15 years old this month! June 16th, 2002 was the date of the first usable version of Tux Paint. Thanks very much to everyone who has helped me along the way (especially those who are keeping the project going, while I've not had the time or inclination to work on it, thanks to a busy day job, two kids, new hobbies, and a bit of burn-out), and of course thanks to everyone who uses & enjoys & shares Tux Paint! I've made an 'event' over on the Facebook page for Tux Paint (have you "Like"-ed the page yet!? :^) ), which you can join and share if you'd like! https://www.facebook.com/events/1343407825728599 -- -bill! Sent from my computer ----- End forwarded message ----- |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-06-02 19:38:06
|
El dv 02 de 06 de 2017 a les 20:54 +0200, en/na Jacques Chion va escriure: > Hello, > > i wish to compile SDL2_Pango, that i got on sourceforge. > > But when i run ./configure i have the error : > > config.status: error: cannot find input file: `Makefile.in' > > What's wrong ? It compiles fine a .deb package: fakeroot ./debian/rules binary that will create the files libsdl2-pango1_0.1.2-6_amd64.deb libsdl2-pango1-dbgsym_0.1.2-6_amd64.deb libsdl2-pango-dev_0.1.2-6_amd64.deb in the parent directory However, as you say, it doesn't compiles with ./configure&&make, will see what can I do about this. Thanks for reporting Pere > > Regards > > Jacques > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: Jacques Chion <jacques.chion@or...> - 2017-06-02 18:54:51
|
Hello, i wish to compile SDL2_Pango, that i got on sourceforge. But when i run ./configure i have the error : config.status: error: cannot find input file: `Makefile.in' What's wrong ? Regards Jacques |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-05-22 17:47:29
|
El dj 04 de 05 de 2017 a les 00:52 +0200, en/na Pere Pujal i Carabantes va escriure: > > Stamps, f-droid now supports Android expansion files, one idea to benefit from that could be to put all images plus translations and dat files into > one > expansion file, then only provide updates to it. Speaked descriptions could go into separate downloads. > I think I am going to discard this idea, expansion files means forceful download of the stamps... Maybe apks with the different stamps, but once installed the stamps on the sdcard we should warn the user that she can remove/uninstall the apk to recover space. Another idea is a stamp downloader, I started one last winter, it needs a server hosting the stamps packages (SF? newbreed?) and it also has to cope with cache of downloaded stamps to not end with the stamps plus the packages. Other ideas? Thanks for any comments Pere |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-05-19 18:32:02
|
El dc 17 de 05 de 2017 a les 07:57 -0500, en/na B.J. va escriure: > Thanks for getting back to me though! Yeah it’s definitely some sort of library referencing problem…I don’t understand the Mac library naming > conventions either myself (it is SDL-2.0.5, which I compiled myself). Now I am really lost, SDL_GetDrawableSize is supported since 2.0.1 and you said it gave you errors until you changed to SDL_GetRendererOutputSize which available from 2.0.0 Sorry for not being of more help Pere > Well I’ll keep trying to learn more about XCode and do what I can to try linking in different ways etc. Long/short though, I wish I had some advice > from Martin Fuhrer, Carlo Gandolfi, or Douglad Barbieri, since they evidently knew a lot more about MacOS programming than I do. While it’s really > fun learning a new platform, I’m also just ready to have a TuxPaint that’ll run on the newer Sierra operating system. I’ll keep trying, BUT if > anyone else out there has experience with XCode I’d appreciate some better guidance than I’m getting from outside forums so far :) Everyone wish me > luck... > > > On May 16, 2017, at 16:04, Pere Pujal i Carabantes <perepujal@...> wrote: > > > > El dl 15 de 05 de 2017 a les 11:50 -0500, en/na B.J. va escriure: > > > Maybe more interesting… > > > > > > ~ after changing calls from "libiconv" to "iconv" (as it looks like a typdef created them derivatively anyway), those issues go away, but then I > > > get > > > a compiler error claiming there are 3 different main () functions. Maybe that has to do with the deprecation of the SDL_main function in > > > SDL2? Not > > > sure, but if I then change the other 2 "main" functions in macosx/fcinstaller.m and src/tuxpaint.c (since the Cocoa NS caller in > > > macosx/SDL_main.m is > > > probably the one I want?) it compiles finally, and when run the executable reports the following stdout when run ~ > > > > > > $ ./tuxpaint > > > dyld: Library not loaded: /usr/local/lib/libSDL2-2.0.0.dylib > > > Referenced from: /usr/local/lib/libSDL2_image-2.0.0.dylib > > > Reason: Incompatible library version: libSDL2_image-2.0.0.dylib requires version 5.0.0 or later, but libSDL2-2.0.0.dylib provides version 1.0.0 > > > > I really don't understand nothing about MacOs, but looks like you are trying with libSDL2 2.0.0 > > What would happen with libSDL2 2.0.5 ? > > > > HTH > > Pere > > > > > Abort trap: 6 > > > > > > $ otool -L tuxpaint > > > /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57740.51.3) > > > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.65.0) > > > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0) > > > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0) > > > /usr/local/lib/libSDL2-2.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) > > > /usr/local/lib/libSDL2_image-2.0.0.dylib (compatibility version 1.0.0, current version 1.1.0) > > > /usr/local/lib/libSDL2_ttf-2.0.0.dylib (compatibility version 15.0.0, current version 15.0.0) > > > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) > > > /usr/local/lib/libpng16.16.dylib (compatibility version 46.0.0, current version 46.0.0) > > > /usr/local/lib/libSDL2_mixer-2.0.0.dylib (compatibility version 1.0.0, current version 1.1.0) > > > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) > > > /usr/local/lib/libpaper.1.dylib (compatibility version 3.0.0, current version 3.2.0) > > > /usr/local/lib/libfontconfig.1.dylib (compatibility version 11.0.0, current version 11.2.0) > > > /usr/local/lib/libcairo.2.dylib (compatibility version 11403.0.0, current version 11403.8.0) > > > /usr/local/lib/libfribidi.0.dylib (compatibility version 4.0.0, current version 4.6.0) > > > /usr/local/lib/libintl.9.dylib (compatibility version 11.0.0, current version 11.4.0) > > > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.51.1) > > > /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1504.82.104) > > > /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1349.64.0) > > > /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) > > > > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > Tuxpaint-devel mailing list > > > Tuxpaint-devel@... > > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Tuxpaint-devel mailing list > > Tuxpaint-devel@... > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: B.J. <bj@ko...> - 2017-05-17 13:26:11
|
Thanks for getting back to me though! Yeah it’s definitely some sort of library referencing problem…I don’t understand the Mac library naming conventions either myself (it is SDL-2.0.5, which I compiled myself). Well I’ll keep trying to learn more about XCode and do what I can to try linking in different ways etc. Long/short though, I wish I had some advice from Martin Fuhrer, Carlo Gandolfi, or Douglad Barbieri, since they evidently knew a lot more about MacOS programming than I do. While it’s really fun learning a new platform, I’m also just ready to have a TuxPaint that’ll run on the newer Sierra operating system. I’ll keep trying, BUT if anyone else out there has experience with XCode I’d appreciate some better guidance than I’m getting from outside forums so far :) Everyone wish me luck... > On May 16, 2017, at 16:04, Pere Pujal i Carabantes <perepujal@...> wrote: > > El dl 15 de 05 de 2017 a les 11:50 -0500, en/na B.J. va escriure: >> Maybe more interesting… >> >> ~ after changing calls from "libiconv" to "iconv" (as it looks like a typdef created them derivatively anyway), those issues go away, but then I get >> a compiler error claiming there are 3 different main () functions. Maybe that has to do with the deprecation of the SDL_main function in SDL2? Not >> sure, but if I then change the other 2 "main" functions in macosx/fcinstaller.m and src/tuxpaint.c (since the Cocoa NS caller in macosx/SDL_main.m is >> probably the one I want?) it compiles finally, and when run the executable reports the following stdout when run ~ >> >> $ ./tuxpaint >> dyld: Library not loaded: /usr/local/lib/libSDL2-2.0.0.dylib >> Referenced from: /usr/local/lib/libSDL2_image-2.0.0.dylib >> Reason: Incompatible library version: libSDL2_image-2.0.0.dylib requires version 5.0.0 or later, but libSDL2-2.0.0.dylib provides version 1.0.0 > > I really don't understand nothing about MacOs, but looks like you are trying with libSDL2 2.0.0 > What would happen with libSDL2 2.0.5 ? > > HTH > Pere > >> Abort trap: 6 >> >> $ otool -L tuxpaint >> /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57740.51.3) >> /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.65.0) >> /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0) >> /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0) >> /usr/local/lib/libSDL2-2.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) >> /usr/local/lib/libSDL2_image-2.0.0.dylib (compatibility version 1.0.0, current version 1.1.0) >> /usr/local/lib/libSDL2_ttf-2.0.0.dylib (compatibility version 15.0.0, current version 15.0.0) >> /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) >> /usr/local/lib/libpng16.16.dylib (compatibility version 46.0.0, current version 46.0.0) >> /usr/local/lib/libSDL2_mixer-2.0.0.dylib (compatibility version 1.0.0, current version 1.1.0) >> /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) >> /usr/local/lib/libpaper.1.dylib (compatibility version 3.0.0, current version 3.2.0) >> /usr/local/lib/libfontconfig.1.dylib (compatibility version 11.0.0, current version 11.2.0) >> /usr/local/lib/libcairo.2.dylib (compatibility version 11403.0.0, current version 11403.8.0) >> /usr/local/lib/libfribidi.0.dylib (compatibility version 4.0.0, current version 4.6.0) >> /usr/local/lib/libintl.9.dylib (compatibility version 11.0.0, current version 11.4.0) >> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.51.1) >> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1504.82.104) >> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1349.64.0) >> /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Tuxpaint-devel mailing list >> Tuxpaint-devel@... >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-05-16 21:04:42
|
El dl 15 de 05 de 2017 a les 11:50 -0500, en/na B.J. va escriure: > Maybe more interesting… > > ~ after changing calls from "libiconv" to "iconv" (as it looks like a typdef created them derivatively anyway), those issues go away, but then I get > a compiler error claiming there are 3 different main () functions. Maybe that has to do with the deprecation of the SDL_main function in SDL2? Not > sure, but if I then change the other 2 "main" functions in macosx/fcinstaller.m and src/tuxpaint.c (since the Cocoa NS caller in macosx/SDL_main.m is > probably the one I want?) it compiles finally, and when run the executable reports the following stdout when run ~ > > $ ./tuxpaint > dyld: Library not loaded: /usr/local/lib/libSDL2-2.0.0.dylib > Referenced from: /usr/local/lib/libSDL2_image-2.0.0.dylib > Reason: Incompatible library version: libSDL2_image-2.0.0.dylib requires version 5.0.0 or later, but libSDL2-2.0.0.dylib provides version 1.0.0 I really don't understand nothing about MacOs, but looks like you are trying with libSDL2 2.0.0 What would happen with libSDL2 2.0.5 ? HTH Pere > Abort trap: 6 > > $ otool -L tuxpaint > /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57740.51.3) > /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.65.0) > /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0) > /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0) > /usr/local/lib/libSDL2-2.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) > /usr/local/lib/libSDL2_image-2.0.0.dylib (compatibility version 1.0.0, current version 1.1.0) > /usr/local/lib/libSDL2_ttf-2.0.0.dylib (compatibility version 15.0.0, current version 15.0.0) > /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) > /usr/local/lib/libpng16.16.dylib (compatibility version 46.0.0, current version 46.0.0) > /usr/local/lib/libSDL2_mixer-2.0.0.dylib (compatibility version 1.0.0, current version 1.1.0) > /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) > /usr/local/lib/libpaper.1.dylib (compatibility version 3.0.0, current version 3.2.0) > /usr/local/lib/libfontconfig.1.dylib (compatibility version 11.0.0, current version 11.2.0) > /usr/local/lib/libcairo.2.dylib (compatibility version 11403.0.0, current version 11403.8.0) > /usr/local/lib/libfribidi.0.dylib (compatibility version 4.0.0, current version 4.6.0) > /usr/local/lib/libintl.9.dylib (compatibility version 11.0.0, current version 11.4.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.51.1) > /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1504.82.104) > /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1349.64.0) > /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: B.J. <bj@ko...> - 2017-05-15 17:42:43
|
Maybe more interesting… ~ after changing calls from "libiconv" to "iconv" (as it looks like a typdef created them derivatively anyway), those issues go away, but then I get a compiler error claiming there are 3 different main () functions. Maybe that has to do with the deprecation of the SDL_main function in SDL2? Not sure, but if I then change the other 2 "main" functions in macosx/fcinstaller.m and src/tuxpaint.c (since the Cocoa NS caller in macosx/SDL_main.m is probably the one I want?) it compiles finally, and when run the executable reports the following stdout when run ~ $ ./tuxpaint dyld: Library not loaded: /usr/local/lib/libSDL2-2.0.0.dylib Referenced from: /usr/local/lib/libSDL2_image-2.0.0.dylib Reason: Incompatible library version: libSDL2_image-2.0.0.dylib requires version 5.0.0 or later, but libSDL2-2.0.0.dylib provides version 1.0.0 Abort trap: 6 $ otool -L tuxpaint /System/Library/Frameworks/Security.framework/Versions/A/Security (compatibility version 1.0.0, current version 57740.51.3) /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation (compatibility version 150.0.0, current version 1349.65.0) /System/Library/Frameworks/ApplicationServices.framework/Versions/A/ApplicationServices (compatibility version 1.0.0, current version 48.0.0) /System/Library/Frameworks/Cocoa.framework/Versions/A/Cocoa (compatibility version 1.0.0, current version 22.0.0) /usr/local/lib/libSDL2-2.0.0.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/local/lib/libSDL2_image-2.0.0.dylib (compatibility version 1.0.0, current version 1.1.0) /usr/local/lib/libSDL2_ttf-2.0.0.dylib (compatibility version 15.0.0, current version 15.0.0) /usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.8) /usr/local/lib/libpng16.16.dylib (compatibility version 46.0.0, current version 46.0.0) /usr/local/lib/libSDL2_mixer-2.0.0.dylib (compatibility version 1.0.0, current version 1.1.0) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0) /usr/local/lib/libpaper.1.dylib (compatibility version 3.0.0, current version 3.2.0) /usr/local/lib/libfontconfig.1.dylib (compatibility version 11.0.0, current version 11.2.0) /usr/local/lib/libcairo.2.dylib (compatibility version 11403.0.0, current version 11403.8.0) /usr/local/lib/libfribidi.0.dylib (compatibility version 4.0.0, current version 4.6.0) /usr/local/lib/libintl.9.dylib (compatibility version 11.0.0, current version 11.4.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1238.51.1) /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit (compatibility version 45.0.0, current version 1504.82.104) /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation (compatibility version 300.0.0, current version 1349.64.0) /usr/lib/libobjc.A.dylib (compatibility version 1.0.0, current version 228.0.0) |
|
From: B.J. <bj@ko...> - 2017-05-15 13:50:51
|
GetDrawable replaced with GetRenderer twice in tuxpaint.c - not able to test but no more compile errors
call to FcInit commented in SDLMain.m (mac specific) - may break? is it a problem with my cairo?
now just SDL_Main and libiconv to resolve as indicated below; recommendations?
$ cc -O0 -g -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/X11/include -I/usr/local/include/fribidi -DVER_DATE=\"2017-05-02\" -DVER_VERSION=\"0.9.23\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSVG -DNO_SDLPANGO -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/postscript_print.o macosx/SDLMain.o macosx/macosx_print.o macosx/TransparentTextView.o macosx/speech.o macosx/patch.o macosx/message.o macosx/fcinstaller.o -framework Security -framework CoreFoundation -framework ApplicationServices -framework Cocoa -L/usr/local/lib -lSDL2 -lSDL2_image -lSDL2_ttf -lz -lpng -lSDL2_mixer -lpaper -L/usr/local/lib -lfribidi -lintl
Undefined symbols for architecture x86_64:
"_SDL_main", referenced from:
-[SDLMain applicationDidFinishLaunching:] in SDLMain.o
"_libiconv", referenced from:
_iconv in patch.o
"_libiconv_open", referenced from:
_iconv_open in patch.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
All feedback/comments/guidance appreciated :) Thank you!
B.J. |
|
From: B.J. <bj@ko...> - 2017-05-04 15:04:41
|
Do the problems below look like calls to SDL1? It would make sense I guess, since I made the object files from source that was added to the main tree (in the “macosx" directory) to Cocoa-ize the SDL1 port, I think, and probably hasn’t been touched since. I made the object files to resolve the few unaddressed functions from the SDL2 compile and here’s what I got back from the compiler—curious about anyone’s thoughts :) Thanks for peeking:
—
$ cc -O0 -g -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/X11/include -I/usr/local/include/fribidi -DVER_DATE=\"2017-05-02\" -DVER_VERSION=\"0.9.23\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSVG -DNO_SDLPANGO -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/postscript_print.o macosx/SDLMain.o macosx/macosx_print.o macosx/TransparentTextView.o macosx/speech.o macosx/patch.o macosx/message.o macosx/fcinstaller.o -L/usr/local/lib -lSDL2 -lSDL2_image -lSDL2_ttf -lz -lpng -lSDL2_mixer -lpaper -L/usr/local/lib -lfribidi -lintl
Undefined symbols for architecture x86_64:
"_AuthorizationCopyRights", referenced from:
-[SDLMain installFontconfigFilesWithAuthorization] in SDLMain.o
"_AuthorizationCreate", referenced from:
-[SDLMain installFontconfigFilesWithAuthorization] in SDLMain.o
"_AuthorizationExecuteWithPrivileges", referenced from:
-[SDLMain installFontconfigFilesWithAuthorization] in SDLMain.o
"_AuthorizationFree", referenced from:
-[SDLMain installFontconfigFilesWithAuthorization] in SDLMain.o
"_CFBundleCopyBundleURL", referenced from:
-[SDLMain setupWorkingDirectory:] in SDLMain.o
"_CFBundleGetInfoDictionary", referenced from:
_getApplicationName in SDLMain.o
"_CFBundleGetMainBundle", referenced from:
-[SDLMain setupWorkingDirectory:] in SDLMain.o
_getApplicationName in SDLMain.o
"_CFRelease", referenced from:
-[SDLMain setupWorkingDirectory:] in SDLMain.o
"_CFURLCreateCopyDeletingLastPathComponent", referenced from:
-[SDLMain setupWorkingDirectory:] in SDLMain.o
"_CFURLGetFileSystemRepresentation", referenced from:
-[SDLMain setupWorkingDirectory:] in SDLMain.o
"_FcInit", referenced from:
-[SDLMain setupFontconfig] in SDLMain.o
"_NSAllocateMemoryPages", referenced from:
-[NSString(ReplaceSubString) stringByReplacingRange:with:] in SDLMain.o
"_NSApp", referenced from:
-[SDLMain applicationDidFinishLaunching:] in SDLMain.o
-[ModalDelegate wait] in macosx_print.o
_DisplayPageSetup in macosx_print.o
_SurfacePrint in macosx_print.o
"_NSApplicationMain", referenced from:
_main in SDLMain.o
"_NSDeallocateMemoryPages", referenced from:
-[NSString(ReplaceSubString) stringByReplacingRange:with:] in SDLMain.o
"_NSDefaultRunLoopMode", referenced from:
-[ModalDelegate wait] in macosx_print.o
"_NSDeviceRGBColorSpace", referenced from:
_CreateImage in macosx_print.o
"_NSFontAttributeName", referenced from:
-[SDLMain onAbout:] in SDLMain.o
"_NSForegroundColorAttributeName", referenced from:
-[TransparentTextView activateURLs] in TransparentTextView.o
"_NSLinkAttributeName", referenced from:
-[TransparentTextView activateURLs] in TransparentTextView.o
"_NSLog", referenced from:
_CreateImage in macosx_print.o
"_NSParagraphStyleAttributeName", referenced from:
-[SDLMain onAbout:] in SDLMain.o
"_OBJC_CLASS_$_NSApplication", referenced from:
_OBJC_CLASS_$_SDLApplication in SDLMain.o
"_OBJC_CLASS_$_NSArchiver", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSAttributedString", referenced from:
objc-class-ref in SDLMain.o
"_OBJC_CLASS_$_NSAutoreleasePool", referenced from:
objc-class-ref in fcinstaller.o
"_OBJC_CLASS_$_NSBitmapImageRep", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSBundle", referenced from:
objc-class-ref in SDLMain.o
objc-class-ref in fcinstaller.o
"_OBJC_CLASS_$_NSColor", referenced from:
objc-class-ref in TransparentTextView.o
"_OBJC_CLASS_$_NSDate", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSDictionary", referenced from:
objc-class-ref in TransparentTextView.o
"_OBJC_CLASS_$_NSFileManager", referenced from:
objc-class-ref in SDLMain.o
objc-class-ref in fcinstaller.o
l_OBJC_$_CATEGORY_NSFileManager_$_CreateDirectoryRecursively in fcinstaller.o
"_OBJC_CLASS_$_NSFont", referenced from:
objc-class-ref in SDLMain.o
"_OBJC_CLASS_$_NSImage", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSMutableAttributedString", referenced from:
objc-class-ref in SDLMain.o
"_OBJC_CLASS_$_NSMutableDictionary", referenced from:
objc-class-ref in SDLMain.o
"_OBJC_CLASS_$_NSMutableString", referenced from:
objc-class-ref in SDLMain.o
objc-class-ref in TransparentTextView.o
"_OBJC_CLASS_$_NSObject", referenced from:
_OBJC_CLASS_$_CocoaToSDLBridge in SDLMain.o
_OBJC_CLASS_$_SDLMain in SDLMain.o
_OBJC_CLASS_$_ModalDelegate in macosx_print.o
"_OBJC_CLASS_$_NSPageLayout", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSParagraphStyle", referenced from:
objc-class-ref in SDLMain.o
"_OBJC_CLASS_$_NSPrintInfo", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSPrintOperation", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSPrinter", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSProcessInfo", referenced from:
objc-class-ref in SDLMain.o
"_OBJC_CLASS_$_NSSpeechSynthesizer", referenced from:
objc-class-ref in speech.o
"_OBJC_CLASS_$_NSString", referenced from:
objc-class-ref in SDLMain.o
l_OBJC_$_CATEGORY_NSString_$_ReplaceSubString in SDLMain.o
objc-class-ref in speech.o
objc-class-ref in fcinstaller.o
"_OBJC_CLASS_$_NSTextView", referenced from:
_OBJC_CLASS_$_TransparentTextView in TransparentTextView.o
"_OBJC_CLASS_$_NSURL", referenced from:
objc-class-ref in TransparentTextView.o
"_OBJC_CLASS_$_NSUnarchiver", referenced from:
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSUserDefaults", referenced from:
objc-class-ref in SDLMain.o
objc-class-ref in macosx_print.o
"_OBJC_CLASS_$_NSView", referenced from:
_OBJC_CLASS_$_ImageView in macosx_print.o
"_OBJC_CLASS_$_NSWorkspace", referenced from:
objc-class-ref in SDLMain.o
"_OBJC_METACLASS_$_NSApplication", referenced from:
_OBJC_METACLASS_$_SDLApplication in SDLMain.o
"_OBJC_METACLASS_$_NSObject", referenced from:
_OBJC_METACLASS_$_SDLApplication in SDLMain.o
_OBJC_METACLASS_$_CocoaToSDLBridge in SDLMain.o
_OBJC_METACLASS_$_SDLMain in SDLMain.o
_OBJC_METACLASS_$_ImageView in macosx_print.o
_OBJC_METACLASS_$_ModalDelegate in macosx_print.o
_OBJC_METACLASS_$_TransparentTextView in TransparentTextView.o
"_OBJC_METACLASS_$_NSTextView", referenced from:
_OBJC_METACLASS_$_TransparentTextView in TransparentTextView.o
"_OBJC_METACLASS_$_NSView", referenced from:
_OBJC_METACLASS_$_ImageView in macosx_print.o
"_SDL_GL_GetDrawableSize", referenced from:
_setup in tuxpaint.o
"_SDL_main", referenced from:
-[SDLMain applicationDidFinishLaunching:] in SDLMain.o
"___CFConstantStringClassReference", referenced from:
CFString in SDLMain.o
CFString in SDLMain.o
CFString in SDLMain.o
CFString in SDLMain.o
CFString in SDLMain.o
CFString in SDLMain.o
CFString in SDLMain.o
...
"__objc_empty_cache", referenced from:
_OBJC_CLASS_$_SDLApplication in SDLMain.o
_OBJC_METACLASS_$_SDLApplication in SDLMain.o
_OBJC_METACLASS_$_CocoaToSDLBridge in SDLMain.o
_OBJC_CLASS_$_CocoaToSDLBridge in SDLMain.o
_OBJC_METACLASS_$_SDLMain in SDLMain.o
_OBJC_CLASS_$_SDLMain in SDLMain.o
_OBJC_METACLASS_$_ImageView in macosx_print.o
...
"_libiconv", referenced from:
_iconv in patch.o
"_libiconv_open", referenced from:
_iconv_open in patch.o
"_objc_msgSend", referenced from:
-[SDLApplication sendEvent:] in SDLMain.o
-[SDLApplication tuxpaintHelp:] in SDLMain.o
-[CocoaToSDLBridge dataPath:] in SDLMain.o
-[CocoaToSDLBridge preferencesPath] in SDLMain.o
-[CocoaToSDLBridge fontsPath] in SDLMain.o
-[SDLMain onAbout:] in SDLMain.o
-[SDLMain onNew:] in SDLMain.o
...
"_objc_msgSendSuper2", referenced from:
-[SDLApplication sendEvent:] in SDLMain.o
-[ModalDelegate init] in macosx_print.o
"_objc_msgSend_stret", referenced from:
_SurfacePrint in macosx_print.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation) |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-05-03 22:53:05
|
Hi all, There should be soon the 0.23 beta 8 of Tux Paint in the F-droid repository. Changes since 0.23 beta 7 Tux Paint no more loses data when killed in background. Should run fine when the user is not the primary user of the device, it crashed before. Please, test and enjoy :) Things to do Setting for keeping the screen alive, currently Tux Paint follows the device. Stamps, f-droid now supports Android expansion files, one idea to benefit from that could be to put all images plus translations and dat files into one expansion file, then only provide updates to it. Speaked descriptions could go into separate downloads. Config tool: translations, save/cancel buttons?,... x86 support: Currently Tux Paint is compiled for armeabi and armeabi-v7a. To compile for x86 in order to test it on a fastest emulator I had to temporary remove JPG support in SDL_Image. Must weight if it matters to add the x86 support to the apk(+5MB download for all vs more speed on x86 devices) or maybe deploy separate apks for each architecture. Thanks for any input Pere |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-04-29 15:44:03
|
El dj 27 de 04 de 2017 a les 16:30 -0500, en/na B.J. va escriure: > Done—thanks for the feedback! And I was referring to the Android tree being a successful SDL2 compile when I said I didn’t want to mess w/it; not > that I’d break anything, but I’d probably cause more problems than I’d fix if I made a habit of changing code that worked on another platform :) > > Anyway. Thread’s named now. I think I’m missing some libraries here (this looks like the link stage); see if you can tell what’s going on from the > lines below. I think a couple might relate to macosx_print.m in the platform-specific tree of the old SDL1 build, I don’t know. I’ll try to read > around too of course, but maybe one or more calls might be obvious to one of you: > > —— > > $ cc -O0 -g -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate- > return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/X11/include > -I/usr/local/include/fribidi -DVER_DATE=\"2017-04-27\" -DVER_VERSION=\"0.9.23\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" > -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" > -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSVG -DNO_SDLPANGO -o tuxpaint obj/tuxpaint.o > obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o > obj/onscreen_keyboard.o obj/postscript_print.o -L/usr/local/lib -lSDL2 -lSDL2_image -lSDL2_ttf -lz -lpng -lSDL2_mixer -lpaper -L/usr/local/lib > -lfribidi -lintl > > Undefined symbols for architecture x86_64: > "_DisplayPageSetup", referenced from: > _mainloop in tuxpaint.o > "_SDL_GL_GetDrawableSize", referenced from: > _setup in tuxpaint.o This one should be on SDL2, rather odd it is not found... What happens if you change the 2 calls to SDL_GetDrawableSize(window_screen,.... to SDL__GetRendererOutputSize(renderer,.... in tuxpaint.c? > "_SurfacePrint", referenced from: > _do_print in tuxpaint.o > "_macosx", referenced from: > _setup_config in tuxpaint.o > _do_print in tuxpaint.o > _load_locale_font in fonts.o > _load_user_fonts in fonts.o > "_patch_i18n", referenced from: > _setup_i18n in i18n.o > ld: symbol(s) not found for architecture x86_64 > clang: error: linker command failed with exit code 1 (use -v to see invocation) Looks as stuff that is under the macosx dir that for whatever reason doesn't get into the build. > > > On Apr 27, 2017, at 13:17, Bill Kendrick <nbs@...> wrote: > > > > > > Yeah it sounds like threads are nameable now, whereas in SDL 1.2 > > they were not. It makes no difference to Tux Paint (at this point), > > I don't think. So I recommend just naming it something like obvious > > like "TuxPaintLoadUserFonts" or somesuch...? > > > > Thanks! > > > > -bill! > > > > On Thu, Apr 27, 2017 at 09:36:54AM -0500, B.J. wrote: > > > I???m sorry if this is a double message, but I think I sent it from the wrong address earlier, so it may not have made it: > > > > > > Line 23989 in tuxpaint.c (SDL2 branch) calls ???SDL_CreateThread??? with 2 parameters instead of 3. SDL2/SDL_thread.h claims the function needs a > > > function, the name (char string), and a pointer to the data. Since line 23989 passes load_user_fonts_stub and NULL, maybe the thread name is the > > > only thing missing? I can come up with something like that, but I wanted to see if I was missing something else before I start changing code > > > that worked on the Android platform :) Hopefully someone has a better idea of what I could do w/this???thanks! > > > > > > bj > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > Tuxpaint-devel mailing list > > > Tuxpaint-devel@... > > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > > > -- > > -bill! > > Sent from my computer > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Tuxpaint-devel mailing list > > Tuxpaint-devel@... > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: B.J. <bj@ko...> - 2017-04-27 21:36:15
|
Done—thanks for the feedback! And I was referring to the Android tree being a successful SDL2 compile when I said I didn’t want to mess w/it; not that I’d break anything, but I’d probably cause more problems than I’d fix if I made a habit of changing code that worked on another platform :)
Anyway. Thread’s named now. I think I’m missing some libraries here (this looks like the link stage); see if you can tell what’s going on from the lines below. I think a couple might relate to macosx_print.m in the platform-specific tree of the old SDL1 build, I don’t know. I’ll try to read around too of course, but maybe one or more calls might be obvious to one of you:
——
$ cc -O0 -g -W -Wall -fno-common -ffloat-store -fvisibility=hidden -Wcast-align -Wredundant-decls -Wbad-function-cast -Wwrite-strings -Waggregate-return -Wstrict-prototypes -Wmissing-prototypes -Wstrict-aliasing=2 -D_THREAD_SAFE -I/usr/local/include/SDL2 -I/usr/X11/include -I/usr/local/include/fribidi -DVER_DATE=\"2017-04-27\" -DVER_VERSION=\"0.9.23\" -DDATA_PREFIX=\"/usr/local/share/tuxpaint/\" -DDOC_PREFIX=\"/usr/local/share/doc/tuxpaint/\" -DLOCALEDIR=\"/usr/local/share/locale/\" -DIMDIR=\"/usr/local/share/tuxpaint/im/\" -DCONFDIR=\"/usr/local/etc/tuxpaint/\" -DMAGIC_PREFIX=\"/usr/local/lib/tuxpaint/plugins/\" -DNOSVG -DNO_SDLPANGO -o tuxpaint obj/tuxpaint.o obj/i18n.o obj/im.o obj/cursor.o obj/pixels.o obj/rgblinear.o obj/playsound.o obj/fonts.o obj/parse.o obj/progressbar.o obj/dirwalk.o obj/get_fname.o obj/onscreen_keyboard.o obj/postscript_print.o -L/usr/local/lib -lSDL2 -lSDL2_image -lSDL2_ttf -lz -lpng -lSDL2_mixer -lpaper -L/usr/local/lib -lfribidi -lintl
Undefined symbols for architecture x86_64:
"_DisplayPageSetup", referenced from:
_mainloop in tuxpaint.o
"_SDL_GL_GetDrawableSize", referenced from:
_setup in tuxpaint.o
"_SurfacePrint", referenced from:
_do_print in tuxpaint.o
"_macosx", referenced from:
_setup_config in tuxpaint.o
_do_print in tuxpaint.o
_load_locale_font in fonts.o
_load_user_fonts in fonts.o
"_patch_i18n", referenced from:
_setup_i18n in i18n.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
> On Apr 27, 2017, at 13:17, Bill Kendrick <nbs@...> wrote:
>
>
> Yeah it sounds like threads are nameable now, whereas in SDL 1.2
> they were not. It makes no difference to Tux Paint (at this point),
> I don't think. So I recommend just naming it something like obvious
> like "TuxPaintLoadUserFonts" or somesuch...?
>
> Thanks!
>
> -bill!
>
> On Thu, Apr 27, 2017 at 09:36:54AM -0500, B.J. wrote:
>> I???m sorry if this is a double message, but I think I sent it from the wrong address earlier, so it may not have made it:
>>
>> Line 23989 in tuxpaint.c (SDL2 branch) calls ???SDL_CreateThread??? with 2 parameters instead of 3. SDL2/SDL_thread.h claims the function needs a function, the name (char string), and a pointer to the data. Since line 23989 passes load_user_fonts_stub and NULL, maybe the thread name is the only thing missing? I can come up with something like that, but I wanted to see if I was missing something else before I start changing code that worked on the Android platform :) Hopefully someone has a better idea of what I could do w/this???thanks!
>>
>> bj
>> ------------------------------------------------------------------------------
>> Check out the vibrant tech community on one of the world's most
>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
>> _______________________________________________
>> Tuxpaint-devel mailing list
>> Tuxpaint-devel@...
>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
>
> --
> -bill!
> Sent from my computer
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, Slashdot.org! http://sdm.link/slashdot
> _______________________________________________
> Tuxpaint-devel mailing list
> Tuxpaint-devel@...
> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel
|
|
From: Bill Kendrick <nbs@so...> - 2017-04-27 18:30:06
|
Yeah it sounds like threads are nameable now, whereas in SDL 1.2 they were not. It makes no difference to Tux Paint (at this point), I don't think. So I recommend just naming it something like obvious like "TuxPaintLoadUserFonts" or somesuch...? Thanks! -bill! On Thu, Apr 27, 2017 at 09:36:54AM -0500, B.J. wrote: > I???m sorry if this is a double message, but I think I sent it from the wrong address earlier, so it may not have made it: > > Line 23989 in tuxpaint.c (SDL2 branch) calls ???SDL_CreateThread??? with 2 parameters instead of 3. SDL2/SDL_thread.h claims the function needs a function, the name (char string), and a pointer to the data. Since line 23989 passes load_user_fonts_stub and NULL, maybe the thread name is the only thing missing? I can come up with something like that, but I wanted to see if I was missing something else before I start changing code that worked on the Android platform :) Hopefully someone has a better idea of what I could do w/this???thanks! > > bj > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel -- -bill! Sent from my computer |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-04-27 18:27:38
|
El dj 27 de 04 de 2017 a les 09:36 -0500, en/na B.J. va escriure: > I’m sorry if this is a double message, but I think I sent it from the wrong address earlier, so it may not have made it: > > Line 23989 in tuxpaint.c (SDL2 branch) calls “SDL_CreateThread” with 2 parameters instead of 3. SDL2/SDL_thread.h claims the function needs a > function, the name (char string), and a pointer to the data. Since line 23989 passes load_user_fonts_stub and NULL, maybe the thread name is the only > thing missing? I can come up with something like that, but I wanted to see if I was missing something else before I start changing code that worked > on the Android platform :) Hopefully someone has a better idea of what I could do w/this—thanks! Don't worry about Android ;) Since this code is called if not defined FORKED_FONTS you are the first hitting it in the SDL2 port :) Well, in fact it will be used by Windows, BeOS and Apple ports if they manage to compile, see fonts.h So I think it is OK to add the thread name. HTH Pere > > bj > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: B.J. <bj@ko...> - 2017-04-27 15:03:47
|
I’m sorry if this is a double message, but I think I sent it from the wrong address earlier, so it may not have made it: Line 23989 in tuxpaint.c (SDL2 branch) calls “SDL_CreateThread” with 2 parameters instead of 3. SDL2/SDL_thread.h claims the function needs a function, the name (char string), and a pointer to the data. Since line 23989 passes load_user_fonts_stub and NULL, maybe the thread name is the only thing missing? I can come up with something like that, but I wanted to see if I was missing something else before I start changing code that worked on the Android platform :) Hopefully someone has a better idea of what I could do w/this—thanks! bj |
|
From: B.J. <bj@ko...> - 2017-04-25 19:06:33
|
True, that was from a mail program. I’ll see if I can figure out what I’m doing wrong then—thanks for getting back though. > On Apr 25, 2017, at 12:34, Pere Pujal i Carabantes <perepujal@...> wrote: > > El dt 25 de 04 de 2017 a les 11:19 -0500, en/na B.J. va escriure: >> I just found out I did in fact grab the SDL1 branch from the SDL2 site :( I should have done the git-method as Pere had recommended. >> >> Anyway. I’ve never done this anonymously before, but this command didn’t work: >> >>> On Apr 11, 2017, at 17:30, Pere Pujal i Carabantes <perepujal@...> wrote: >>> >>>>> git clone git://git.code.sf.net/p/tuxpaint-sdl2/code <git://git.code.sf.net/p/tuxpaint-sdl2/code>; tuxpaint-sdl2-code > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > Not sure if this is a copy/paste error or something that the mail programs did, but definitely the above line doesn't work > Should be, in just one line > > git > clone > git://git.code.sf.net/p/tuxpaint-sdl2/code > tuxpaint-sdl2-code > > The "<git://git.code.sf.net/p/tuxpaint-sdl2/code>"; text should not be there > >> git responds that “clone git://…” is an invalid command. There’s definitely a space between the command and the URL though; anything look odd? I’ll >> keep trying to see if I can get the SDL2 tree downloaded. Thanks for any guidance anyone has... >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Tuxpaint-devel mailing list >> Tuxpaint-devel@... >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-04-25 17:34:22
|
El dt 25 de 04 de 2017 a les 11:19 -0500, en/na B.J. va escriure: > I just found out I did in fact grab the SDL1 branch from the SDL2 site :( I should have done the git-method as Pere had recommended. > > Anyway. I’ve never done this anonymously before, but this command didn’t work: > > > On Apr 11, 2017, at 17:30, Pere Pujal i Carabantes <perepujal@...> wrote: > > > > > > git clone git://git.code.sf.net/p/tuxpaint-sdl2/code <git://git.code.sf.net/p/tuxpaint-sdl2/code>; tuxpaint-sdl2-code ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ Not sure if this is a copy/paste error or something that the mail programs did, but definitely the above line doesn't work Should be, in just one line git clone git://git.code.sf.net/p/tuxpaint-sdl2/code tuxpaint-sdl2-code The "<git://git.code.sf.net/p/tuxpaint-sdl2/code>"; text should not be there > git responds that “clone git://…” is an invalid command. There’s definitely a space between the command and the URL though; anything look odd? I’ll > keep trying to see if I can get the SDL2 tree downloaded. Thanks for any guidance anyone has... > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: B.J. <bj@ko...> - 2017-04-25 16:41:10
|
I just found out I did in fact grab the SDL1 branch from the SDL2 site :( I should have done the git-method as Pere had recommended. Anyway. I’ve never done this anonymously before, but this command didn’t work: > On Apr 11, 2017, at 17:30, Pere Pujal i Carabantes <perepujal@...> wrote: > >>> git clone git://git.code.sf.net/p/tuxpaint-sdl2/code <git://git.code.sf.net/p/tuxpaint-sdl2/code>; tuxpaint-sdl2-code git responds that “clone git://…” is an invalid command. There’s definitely a space between the command and the URL though; anything look odd? I’ll keep trying to see if I can get the SDL2 tree downloaded. Thanks for any guidance anyone has... |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-04-21 14:34:45
|
On 21 d’abril de 2017 15.58.53 CEST, "B.J." <bj@...> wrote: >Hadn’t thought of this before for some reason, but after some clues >from the Makefile, I used this and it did generate a file: > > make src/tp_magic_api.h > >I haven’t tried a new build b/c I still need parse.c …anwyay. Was that >a good idea? If not, can anyone w/access to a linux system attach >parse.c and tp_magic_api.h for me? A “make src/parse.c” didn’t go as >well as the tp_magic_api did, but I’ll play around some more. No >access to a linux sys at the moment sadly (I kindof melted the hard >drive I think)…thanks! > > - bj > You can download it here https://github.com/tux4kids/Tuxpaint-Android/tree/master/jni/tuxpaint/src >> On Apr 20, 2017, at 13:44, Pere Pujal i Carabantes ><perepujal@...> wrote: >> >> El dj 20 de 04 de 2017 a les 08:17 -0500, en/na B.J. va escriure: >>> OK. I think the most recent hurdle (a linker thing, created b/c I >was compiling from both the command-line and the XCode IDE GUI, needed >a cleaning) >>> was cleared up. NOW I think I’m hopefully missing something pretty >basic: I need tp_magic_api.h — and of course I see tp_magic_api.h.in, >leading me >>> to wonder whether there’s a configure script somewhere I need to get >to? I see configure.in and lots of other .in files. Or is that more to >do with >>> pkg-config or autoconf or something? I’ve never used them from >scratch myself so I get them mixed up :-/ >>> >>> Anyway. What’s the correct way to convert .in files to the ones >they’re supposed to generate? Thanks! >> >> tp_magic_api.h is generated from the Makefile via a call to grep, I >didn't know before your mail ;) >> >> I bet the best way to generate it is the approach that toke Jianwei >to build for Android, that is compile >> Tux Paint for Linux and copy the needed files. >> >> Quoting from the android port: >> " >> Issue 2: Missing source file "parse.c" and header file >"tp_magic_api.h" >> >> Problem: NDK compilation failed with following error message. >> >> make: *** No rule to make target "jni/tuxpaint/src/parse.c", >needed by "obj/local/armeabi/objs/tuxpaint/src/parse.o". Stop. >> >> Solution: parse.c is generated from parse.gperf by Makefile (see line >1025). Here compile another Tux Paint in linux system with Makefile and >then copy >> generated parse.c to jni/tuxpaint/src folder. >> >> tp_magic_api.h is generated from tp_magic_api.h.in by Makefile. Here >compile another Tux Paint in linux system with Makefile and then copy >generated >> tp_magic_api.h to jni/tuxpaint/src folder. >> " >> >> HTH >> Pere >>> >>> - bj >>> >>>> On Apr 17, 2017, at 13:55, Pere Pujal i Carabantes ><perepujal@...> wrote: >>>> >>>> El dl 17 de 04 de 2017 a les 11:34 -0500, en/na B.J. va escriure: >>>>> I have SDL2 freshly compiled now w/the test programs running, and >I’ve begun to convert the TuxPaint project file to something that can >be >>>>> deployed >>>>> successfully on Sierra (OS 10.12.x). >>>> >>>> Nice:) >>>> >>>>> Here’re the first Q’s: >>>>> >>>>> What’s fontconfig? If I comment the include for >fontconfig/fontconfig.h then I can see it’s probably needed for >“FcBool” later on…I’ll look >>>>> around >>>>> to see if this is another required library. >>>> >>>> A library to deal with fonts, cache them... >>>> >>>> >>>>> Likewise, is png.h from libpng? >>>> >>>> Yes >>>> >>>> >>>>> If libintl.h is missing should I try to figure out how to set >NO_GETTEXT or should I try to see if there’s a libgettext I can >compile? Hoping >>>>> there’s a better answer than either of those 2 :-D >>>> >>>> If I recall correct, the windows and linux versions uses >libgettext, the android version uses libintl-lite >>>> >>>> >>>>> I still see calls in this source tree to headers like >“SDL_mixer.h” making me wonder whether I might have a tree that still >compiles for SDL1—is >>>>> there a mixer lib for SDL2? I thought those extra SDL pieces were >deprecated because they were all included with SDL2’s core. I could be >wrong >>>>> :) But I also want to make sure this source tree’s the right one >to use. >>>> >>>> I don't think they are deprecated, they are ported to SDL2 and are >available from the libsdl site >>>> https://www.libsdl.org/projects/SDL_image/ >>>> https://www.libsdl.org/projects/SDL_mixer/ >>>> https://www.libsdl.org/projects/SDL_ttf/ >>>> >>>>> >>>>> btw has anyone compiled TuxPaint sucessfully on SDL2 yet? Which >platforms? >>>> >>>> Linux and Android >>>> >>>> >>>>> Android and Linux looked like they were still SDL1 the last I >checked but that was some time ago… >>>> >>>> There has been an Android version distributed on Google Play that >the developer claimed it were >>>> compiled with an 1.2 version of SDL, the Pelya's one if I recall >correct. I never saw its source code though. >>>> The current beta Android version distributed on fdroid is based on >SDL2 (2.0.4 for the current build) >>>> You can find it's code at >>>> https://github.com/tux4kids/Tuxpaint-Android >>>> the code for tuxpaint itself and all the libraries are under the >jni dir. >>>> >>>> >>>>> I know the main project seems to point to SDL1 sources too. >>>> >>>> Yes, this is correct, there is not any official release of the SDL2 >based sources ATM >>>> >>>> >>>>> Anyway. I appreciate any feedback/guidance. Hoping to do more >soon! Thanks. >>>> >>>> HTH >>>> Pere >>>> >>>>> >>>>> - bj >>>>> >------------------------------------------------------------------------------ >>>>> Check out the vibrant tech community on one of the world's most >>>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>>> _______________________________________________ >>>>> Tuxpaint-devel mailing list >>>>> Tuxpaint-devel@... >>>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel >>>> >>>> >------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Tuxpaint-devel mailing list >>>> Tuxpaint-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel >>> >>> >>> >------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Tuxpaint-devel mailing list >>> Tuxpaint-devel@... >>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel >> >> >------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org <http://slashdot.org/>;! >http://sdm.link/slashdot <http://sdm.link/slashdot>; >> _______________________________________________ >> Tuxpaint-devel mailing list >> Tuxpaint-devel@... ><mailto:Tuxpaint-devel@...> >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel ><https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>; -- Sent from my Android device with K-9 Mail. Please excuse my brevity. |
|
From: B.J. <bj@ko...> - 2017-04-21 14:04:05
|
Hadn’t thought of this before for some reason, but after some clues from the Makefile, I used this and it did generate a file: make src/tp_magic_api.h I haven’t tried a new build b/c I still need parse.c …anwyay. Was that a good idea? If not, can anyone w/access to a linux system attach parse.c and tp_magic_api.h for me? A “make src/parse.c” didn’t go as well as the tp_magic_api did, but I’ll play around some more. No access to a linux sys at the moment sadly (I kindof melted the hard drive I think)…thanks! - bj > On Apr 20, 2017, at 13:44, Pere Pujal i Carabantes <perepujal@...> wrote: > > El dj 20 de 04 de 2017 a les 08:17 -0500, en/na B.J. va escriure: >> OK. I think the most recent hurdle (a linker thing, created b/c I was compiling from both the command-line and the XCode IDE GUI, needed a cleaning) >> was cleared up. NOW I think I’m hopefully missing something pretty basic: I need tp_magic_api.h — and of course I see tp_magic_api.h.in, leading me >> to wonder whether there’s a configure script somewhere I need to get to? I see configure.in and lots of other .in files. Or is that more to do with >> pkg-config or autoconf or something? I’ve never used them from scratch myself so I get them mixed up :-/ >> >> Anyway. What’s the correct way to convert .in files to the ones they’re supposed to generate? Thanks! > > tp_magic_api.h is generated from the Makefile via a call to grep, I didn't know before your mail ;) > > I bet the best way to generate it is the approach that toke Jianwei to build for Android, that is compile > Tux Paint for Linux and copy the needed files. > > Quoting from the android port: > " > Issue 2: Missing source file "parse.c" and header file "tp_magic_api.h" > > Problem: NDK compilation failed with following error message. > > make: *** No rule to make target "jni/tuxpaint/src/parse.c", needed by "obj/local/armeabi/objs/tuxpaint/src/parse.o". Stop. > > Solution: parse.c is generated from parse.gperf by Makefile (see line 1025). Here compile another Tux Paint in linux system with Makefile and then copy > generated parse.c to jni/tuxpaint/src folder. > > tp_magic_api.h is generated from tp_magic_api.h.in by Makefile. Here compile another Tux Paint in linux system with Makefile and then copy generated > tp_magic_api.h to jni/tuxpaint/src folder. > " > > HTH > Pere >> >> - bj >> >>> On Apr 17, 2017, at 13:55, Pere Pujal i Carabantes <perepujal@...> wrote: >>> >>> El dl 17 de 04 de 2017 a les 11:34 -0500, en/na B.J. va escriure: >>>> I have SDL2 freshly compiled now w/the test programs running, and I’ve begun to convert the TuxPaint project file to something that can be >>>> deployed >>>> successfully on Sierra (OS 10.12.x). >>> >>> Nice:) >>> >>>> Here’re the first Q’s: >>>> >>>> What’s fontconfig? If I comment the include for fontconfig/fontconfig.h then I can see it’s probably needed for “FcBool” later on…I’ll look >>>> around >>>> to see if this is another required library. >>> >>> A library to deal with fonts, cache them... >>> >>> >>>> Likewise, is png.h from libpng? >>> >>> Yes >>> >>> >>>> If libintl.h is missing should I try to figure out how to set NO_GETTEXT or should I try to see if there’s a libgettext I can compile? Hoping >>>> there’s a better answer than either of those 2 :-D >>> >>> If I recall correct, the windows and linux versions uses libgettext, the android version uses libintl-lite >>> >>> >>>> I still see calls in this source tree to headers like “SDL_mixer.h” making me wonder whether I might have a tree that still compiles for SDL1—is >>>> there a mixer lib for SDL2? I thought those extra SDL pieces were deprecated because they were all included with SDL2’s core. I could be wrong >>>> :) But I also want to make sure this source tree’s the right one to use. >>> >>> I don't think they are deprecated, they are ported to SDL2 and are available from the libsdl site >>> https://www.libsdl.org/projects/SDL_image/ >>> https://www.libsdl.org/projects/SDL_mixer/ >>> https://www.libsdl.org/projects/SDL_ttf/ >>> >>>> >>>> btw has anyone compiled TuxPaint sucessfully on SDL2 yet? Which platforms? >>> >>> Linux and Android >>> >>> >>>> Android and Linux looked like they were still SDL1 the last I checked but that was some time ago… >>> >>> There has been an Android version distributed on Google Play that the developer claimed it were >>> compiled with an 1.2 version of SDL, the Pelya's one if I recall correct. I never saw its source code though. >>> The current beta Android version distributed on fdroid is based on SDL2 (2.0.4 for the current build) >>> You can find it's code at >>> https://github.com/tux4kids/Tuxpaint-Android >>> the code for tuxpaint itself and all the libraries are under the jni dir. >>> >>> >>>> I know the main project seems to point to SDL1 sources too. >>> >>> Yes, this is correct, there is not any official release of the SDL2 based sources ATM >>> >>> >>>> Anyway. I appreciate any feedback/guidance. Hoping to do more soon! Thanks. >>> >>> HTH >>> Pere >>> >>>> >>>> - bj >>>> ------------------------------------------------------------------------------ >>>> Check out the vibrant tech community on one of the world's most >>>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>>> _______________________________________________ >>>> Tuxpaint-devel mailing list >>>> Tuxpaint-devel@... >>>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel >>> >>> ------------------------------------------------------------------------------ >>> Check out the vibrant tech community on one of the world's most >>> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >>> _______________________________________________ >>> Tuxpaint-devel mailing list >>> Tuxpaint-devel@... >>> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel >> >> >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Tuxpaint-devel mailing list >> Tuxpaint-devel@... >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org <http://slashdot.org/>;! http://sdm.link/slashdot <http://sdm.link/slashdot>; > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... <mailto:Tuxpaint-devel@...> > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel <https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel>; |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-04-20 18:44:39
|
El dj 20 de 04 de 2017 a les 08:17 -0500, en/na B.J. va escriure: > OK. I think the most recent hurdle (a linker thing, created b/c I was compiling from both the command-line and the XCode IDE GUI, needed a cleaning) > was cleared up. NOW I think I’m hopefully missing something pretty basic: I need tp_magic_api.h — and of course I see tp_magic_api.h.in, leading me > to wonder whether there’s a configure script somewhere I need to get to? I see configure.in and lots of other .in files. Or is that more to do with > pkg-config or autoconf or something? I’ve never used them from scratch myself so I get them mixed up :-/ > > Anyway. What’s the correct way to convert .in files to the ones they’re supposed to generate? Thanks! tp_magic_api.h is generated from the Makefile via a call to grep, I didn't know before your mail ;) I bet the best way to generate it is the approach that toke Jianwei to build for Android, that is compile Tux Paint for Linux and copy the needed files. Quoting from the android port: " Issue 2: Missing source file "parse.c" and header file "tp_magic_api.h" Problem: NDK compilation failed with following error message. make: *** No rule to make target "jni/tuxpaint/src/parse.c", needed by "obj/local/armeabi/objs/tuxpaint/src/parse.o". Stop. Solution: parse.c is generated from parse.gperf by Makefile (see line 1025). Here compile another Tux Paint in linux system with Makefile and then copy generated parse.c to jni/tuxpaint/src folder. tp_magic_api.h is generated from tp_magic_api.h.in by Makefile. Here compile another Tux Paint in linux system with Makefile and then copy generated tp_magic_api.h to jni/tuxpaint/src folder. " HTH Pere > > - bj > > > On Apr 17, 2017, at 13:55, Pere Pujal i Carabantes <perepujal@...> wrote: > > > > El dl 17 de 04 de 2017 a les 11:34 -0500, en/na B.J. va escriure: > > > I have SDL2 freshly compiled now w/the test programs running, and I’ve begun to convert the TuxPaint project file to something that can be > > > deployed > > > successfully on Sierra (OS 10.12.x). > > > > Nice:) > > > > > Here’re the first Q’s: > > > > > > What’s fontconfig? If I comment the include for fontconfig/fontconfig.h then I can see it’s probably needed for “FcBool” later on…I’ll look > > > around > > > to see if this is another required library. > > > > A library to deal with fonts, cache them... > > > > > > > Likewise, is png.h from libpng? > > > > Yes > > > > > > > If libintl.h is missing should I try to figure out how to set NO_GETTEXT or should I try to see if there’s a libgettext I can compile? Hoping > > > there’s a better answer than either of those 2 :-D > > > > If I recall correct, the windows and linux versions uses libgettext, the android version uses libintl-lite > > > > > > > I still see calls in this source tree to headers like “SDL_mixer.h” making me wonder whether I might have a tree that still compiles for SDL1—is > > > there a mixer lib for SDL2? I thought those extra SDL pieces were deprecated because they were all included with SDL2’s core. I could be wrong > > > :) But I also want to make sure this source tree’s the right one to use. > > > > I don't think they are deprecated, they are ported to SDL2 and are available from the libsdl site > > https://www.libsdl.org/projects/SDL_image/ > > https://www.libsdl.org/projects/SDL_mixer/ > > https://www.libsdl.org/projects/SDL_ttf/ > > > > > > > > btw has anyone compiled TuxPaint sucessfully on SDL2 yet? Which platforms? > > > > Linux and Android > > > > > > > Android and Linux looked like they were still SDL1 the last I checked but that was some time ago… > > > > There has been an Android version distributed on Google Play that the developer claimed it were > > compiled with an 1.2 version of SDL, the Pelya's one if I recall correct. I never saw its source code though. > > The current beta Android version distributed on fdroid is based on SDL2 (2.0.4 for the current build) > > You can find it's code at > > https://github.com/tux4kids/Tuxpaint-Android > > the code for tuxpaint itself and all the libraries are under the jni dir. > > > > > > > I know the main project seems to point to SDL1 sources too. > > > > Yes, this is correct, there is not any official release of the SDL2 based sources ATM > > > > > > > Anyway. I appreciate any feedback/guidance. Hoping to do more soon! Thanks. > > > > HTH > > Pere > > > > > > > > - bj > > > ------------------------------------------------------------------------------ > > > Check out the vibrant tech community on one of the world's most > > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > > _______________________________________________ > > > Tuxpaint-devel mailing list > > > Tuxpaint-devel@... > > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > > > ------------------------------------------------------------------------------ > > Check out the vibrant tech community on one of the world's most > > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > > _______________________________________________ > > Tuxpaint-devel mailing list > > Tuxpaint-devel@... > > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: B.J. <bj@ko...> - 2017-04-20 13:46:15
|
OK. I think the most recent hurdle (a linker thing, created b/c I was compiling from both the command-line and the XCode IDE GUI, needed a cleaning) was cleared up. NOW I think I’m hopefully missing something pretty basic: I need tp_magic_api.h — and of course I see tp_magic_api.h.in, leading me to wonder whether there’s a configure script somewhere I need to get to? I see configure.in and lots of other .in files. Or is that more to do with pkg-config or autoconf or something? I’ve never used them from scratch myself so I get them mixed up :-/ Anyway. What’s the correct way to convert .in files to the ones they’re supposed to generate? Thanks! - bj > On Apr 17, 2017, at 13:55, Pere Pujal i Carabantes <perepujal@...> wrote: > > El dl 17 de 04 de 2017 a les 11:34 -0500, en/na B.J. va escriure: >> I have SDL2 freshly compiled now w/the test programs running, and I’ve begun to convert the TuxPaint project file to something that can be deployed >> successfully on Sierra (OS 10.12.x). > > Nice:) > >> Here’re the first Q’s: >> >> What’s fontconfig? If I comment the include for fontconfig/fontconfig.h then I can see it’s probably needed for “FcBool” later on…I’ll look around >> to see if this is another required library. > > A library to deal with fonts, cache them... > > >> Likewise, is png.h from libpng? > > Yes > > >> If libintl.h is missing should I try to figure out how to set NO_GETTEXT or should I try to see if there’s a libgettext I can compile? Hoping >> there’s a better answer than either of those 2 :-D > > If I recall correct, the windows and linux versions uses libgettext, the android version uses libintl-lite > > >> I still see calls in this source tree to headers like “SDL_mixer.h” making me wonder whether I might have a tree that still compiles for SDL1—is >> there a mixer lib for SDL2? I thought those extra SDL pieces were deprecated because they were all included with SDL2’s core. I could be wrong >> :) But I also want to make sure this source tree’s the right one to use. > > I don't think they are deprecated, they are ported to SDL2 and are available from the libsdl site > https://www.libsdl.org/projects/SDL_image/ > https://www.libsdl.org/projects/SDL_mixer/ > https://www.libsdl.org/projects/SDL_ttf/ > >> >> btw has anyone compiled TuxPaint sucessfully on SDL2 yet? Which platforms? > > Linux and Android > > >> Android and Linux looked like they were still SDL1 the last I checked but that was some time ago… > > There has been an Android version distributed on Google Play that the developer claimed it were > compiled with an 1.2 version of SDL, the Pelya's one if I recall correct. I never saw its source code though. > The current beta Android version distributed on fdroid is based on SDL2 (2.0.4 for the current build) > You can find it's code at > https://github.com/tux4kids/Tuxpaint-Android > the code for tuxpaint itself and all the libraries are under the jni dir. > > >> I know the main project seems to point to SDL1 sources too. > > Yes, this is correct, there is not any official release of the SDL2 based sources ATM > > >> Anyway. I appreciate any feedback/guidance. Hoping to do more soon! Thanks. > > HTH > Pere > >> >> - bj >> ------------------------------------------------------------------------------ >> Check out the vibrant tech community on one of the world's most >> engaging tech sites, Slashdot.org! http://sdm.link/slashdot >> _______________________________________________ >> Tuxpaint-devel mailing list >> Tuxpaint-devel@... >> https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel > > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: Pere Pujal i Carabantes <perepujal@gm...> - 2017-04-17 18:55:18
|
El dl 17 de 04 de 2017 a les 11:34 -0500, en/na B.J. va escriure: > I have SDL2 freshly compiled now w/the test programs running, and I’ve begun to convert the TuxPaint project file to something that can be deployed > successfully on Sierra (OS 10.12.x). Nice:) > Here’re the first Q’s: > > What’s fontconfig? If I comment the include for fontconfig/fontconfig.h then I can see it’s probably needed for “FcBool” later on…I’ll look around > to see if this is another required library. A library to deal with fonts, cache them... > Likewise, is png.h from libpng? Yes > If libintl.h is missing should I try to figure out how to set NO_GETTEXT or should I try to see if there’s a libgettext I can compile? Hoping > there’s a better answer than either of those 2 :-D If I recall correct, the windows and linux versions uses libgettext, the android version uses libintl-lite > I still see calls in this source tree to headers like “SDL_mixer.h” making me wonder whether I might have a tree that still compiles for SDL1—is > there a mixer lib for SDL2? I thought those extra SDL pieces were deprecated because they were all included with SDL2’s core. I could be wrong > :) But I also want to make sure this source tree’s the right one to use. I don't think they are deprecated, they are ported to SDL2 and are available from the libsdl site https://www.libsdl.org/projects/SDL_image/ https://www.libsdl.org/projects/SDL_mixer/ https://www.libsdl.org/projects/SDL_ttf/ > > btw has anyone compiled TuxPaint sucessfully on SDL2 yet? Which platforms? Linux and Android > Android and Linux looked like they were still SDL1 the last I checked but that was some time ago… There has been an Android version distributed on Google Play that the developer claimed it were compiled with an 1.2 version of SDL, the Pelya's one if I recall correct. I never saw its source code though. The current beta Android version distributed on fdroid is based on SDL2 (2.0.4 for the current build) You can find it's code at https://github.com/tux4kids/Tuxpaint-Android the code for tuxpaint itself and all the libraries are under the jni dir. > I know the main project seems to point to SDL1 sources too. Yes, this is correct, there is not any official release of the SDL2 based sources ATM > Anyway. I appreciate any feedback/guidance. Hoping to do more soon! Thanks. HTH Pere > > - bj > ------------------------------------------------------------------------------ > Check out the vibrant tech community on one of the world's most > engaging tech sites, Slashdot.org! http://sdm.link/slashdot > _______________________________________________ > Tuxpaint-devel mailing list > Tuxpaint-devel@... > https://lists.sourceforge.net/lists/listinfo/tuxpaint-devel |
|
From: B.J. <bj@ko...> - 2017-04-17 16:56:08
|
I have SDL2 freshly compiled now w/the test programs running, and I’ve begun to convert the TuxPaint project file to something that can be deployed successfully on Sierra (OS 10.12.x). Here’re the first Q’s: What’s fontconfig? If I comment the include for fontconfig/fontconfig.h then I can see it’s probably needed for “FcBool” later on…I’ll look around to see if this is another required library. Likewise, is png.h from libpng? If libintl.h is missing should I try to figure out how to set NO_GETTEXT or should I try to see if there’s a libgettext I can compile? Hoping there’s a better answer than either of those 2 :-D I still see calls in this source tree to headers like “SDL_mixer.h” making me wonder whether I might have a tree that still compiles for SDL1—is there a mixer lib for SDL2? I thought those extra SDL pieces were deprecated because they were all included with SDL2’s core. I could be wrong :) But I also want to make sure this source tree’s the right one to use. btw has anyone compiled TuxPaint sucessfully on SDL2 yet? Which platforms? Android and Linux looked like they were still SDL1 the last I checked but that was some time ago…I know the main project seems to point to SDL1 sources too. Anyway. I appreciate any feedback/guidance. Hoping to do more soon! Thanks. - bj |