Re: [Tuxpaint-devel] Fwd: Please help us

[Pere Pujal i Carabantes <perepujal@gm...>]

El dg 20 de 08 de 2017 a les 17:06 +0100, en/na Caroline Ford va escriure:
> 
> Sent from a mobile device.
> 
> Begin forwarded message:
> 
> > From: Thanuja Dayasri <thanujadsri@...>
> > Date: 20 August 2017 at 16:56:05 BST
> > To: undisclosed-recipients:;
> > Subject: Please help us
> > 
> > We are 3rd year Undergraduate students of University of Jaffna in Sri Lanka .We suppose to develop Open souse software "Tux paint". We have a souse
> > code downloaded from https://sourceforge.net. We tried to run on  visual studio,code blocks etc.. But still we couldn't run through any application
> > this code.We hope to your support to do our development project. please inform us what would be the exact compiler software for this tux paint
> > software & how to do this.We hope your immediate response.  Thank you 

Hi all,

Tux Paint is developed mainly in Linux, as an example, for Debian and derivates you just run

# apt-get build-dep tuxpaint   to have all the dependencies needed to compile Tux Paint

then, to get the source code
cvs -d:pserver:anonymous@...:/cvsroot/tuxpaint  login 
Hit Enter as password

cvs -z3 -d:pserver:anonymous@...:/cvsroot/tuxpaint co -P tuxpaint

run
$ cd tuxpaint
$ make

$ su -c"make install"   or
$ sudo make install     depending on your configuration

$ tuxpaint


Close Tux Paint, edit any file of your choice with the editor of your choice, 
then recompile and install again and test your changes
$ make
$ su -c"make install"
$ tuxpaint

You will see all this better explained in the file docs/INSTALL.txt

For Windows, the latest instructions I know are at
http://www.johnnypops.co.uk/tuxpaint/index.html

Lately, I strongly suggest that if you are interested in developing/extending Tux Paint, subscribe 
to the tuxpaint-devel mailing list.
https://sourceforge.net/projects/tuxpaint/lists/tuxpaint-devel

Any hint on what area you plan to do/develop/improve?


HTH
Pere

[Tuxpaint-devel] Fwd: Please help us

[Caroline Ford <caroline.ford.work@gm...>]

Sent from a mobile device.

Begin forwarded message:

> From: Thanuja Dayasri <thanujadsri@...>
> Date: 20 August 2017 at 16:56:05 BST
> To: undisclosed-recipients:;
> Subject: Please help us
> 
> We are 3rd year Undergraduate students of University of Jaffna in Sri Lanka .We suppose to develop Open souse software "Tux paint". We have a souse code downloaded from https://sourceforge.net. We tried to run on  visual studio,code blocks etc.. But still we couldn't run through any application this code.We hope to your support to do our development project. please inform us what would be the exact compiler software for this tux paint software & how to do this.We hope your immediate response.  Thank you 

Re: [Tuxpaint-devel] extend tuxpaint

[Pere Pujal i Carabantes <perepujal@gm...>]

El dt 01 de 08 de 2017 a les 09:00 +0530, en/na Nalaka Senarathna va escriure:
> how can i edit and compile tuxpaint source code in windows 7

Hi, to compile the Tux Paint's cvs sources in Windows, follow these instructions
http://www.johnnypops.co.uk/tuxpaint/index.html

Take in account that SDL1.2 is already at the 1.2.15 version, which has fixes
for some bugs that impacts Tux Paint, so remember to update SDL in your build.

Editing is a matter of taste, some people prefer plain text editors, other 
prefers IDEs, just take in account that Tux Paint is mainly developed in Linux, 
so the "end of line" must follow the Linux style.


HTH
Pere

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Translating the config activity of the Android version

[tux paint <tuxpaintdev@gm...>]

how can i edit and compile the source code in windows or linux. ( imeant
what kind of software did u use for this).
thnk you...

On Sun, Jul 30, 2017 at 12:45 PM, Pere Pujal i Carabantes <
perepujal@...> wrote:

> El dg 30 de 07 de 2017 a les 13:12 +0200, en/na Karl Ove Hufthammer va
> escriure:
> > Pere Pujal i Carabantes skreiv 29. juli 2017 16:30:
> > > > Where can I find the source code for the Android version? I had a
> look
> > > > in the CVS repository (which I have commit access to), but couldn’t
> find
> > > > it there.
> > >
> > > Currently it is at github,  https://github.com/
> tux4kids/Tuxpaint-Android
> > > and the android strings are under res/values-xx dirs.
> > >
> > > […]
> > >
> > > If somebody wants to help with the android port in github, I will be
> > > very happy to provide commit access.
> >
> > I won’t be able to help with the actual port, but if it’s possible for
> > translators to have commit access, I would appreciate having access (my
> > username is ‘huftis’), to be able to commit updated translations.
>
> Sent an invite, if anybody else wants also commit access, please tell it.
>
>
> >
> > Regarding the translation process, I discovered that it’s possible to
> > generate normal POT/PO files for translating Android apps. This is much
> > easier (and less error-prone) for translators, as they can use their
> > usual PO editors instead of having to hand-edit (and keep up to date)
> > .xml files.
> >
>
> Nice, so we can make a couple of scripts that generates the POs<->strings
> most like the ones used for stamps.
>
> > I have tested this. Using the ‘android2po’ tools, running the following
> > command
> >
> >    a2po init --groups strings
> >
> > generates a ‘template.pot’ file POT based on the ‘strings.xml’ file in
> > the res/values folder, along with ‘xx.po’ PO files (where ‘xx’ is a
> > language code), based on the corresponding strings.xml files in the
> > res/values-xx folders. Whenever you add or strings, run
> >
> >    a2po export --groups strings
> >
> > to generate updated POT and PO files. When you receive updated PO files
> > from translators, run
> >
> >    a2po import --groups strings
> >
> > To generate PO files for new languages (e.g. xx, yy and zz), run
> >
> >    a2po init xx yy zz --groups strings
> >
> > (It’s important to do things this way to ensure that the PO files
> > contain the correct rules for plural strings.)
> >
> > The ‘--groups’ option is needed to avoid a2po also extracting the
> > ‘arrays.xml’ file. When there is only *one* file to translate
> > (strings.xml), a2po generates ‘template.pot’ and ‘xx.po’ files. If you
> > have several string files, you have to use this syntax:
> >
> >    a2po import --groups strings uistrings
> >
> > The tool will now instead generate ‘strings.pot’, ‘uistrings.pot’,
> > ‘strings-xx.po’, ‘uistrings-xx.po’ (and no ‘template.pot’ and ‘xx.po’
> > files). Use the ‘--layout’ option to choose a different directory or
> > filename layout for the POT and PO files.
> >
>
> ------------------------------------------------------------
> ------------------
> 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
>

[Tuxpaint-devel] extend tuxpaint

[Nalaka Senarathna <nalakasenarathna2@gm...>]

how can i edit and compile tuxpaint source code in windows 7

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Translating the config activity of the Android version

[Pere Pujal i Carabantes <perepujal@gm...>]

El dg 30 de 07 de 2017 a les 13:12 +0200, en/na Karl Ove Hufthammer va escriure:
> Pere Pujal i Carabantes skreiv 29. juli 2017 16:30:
> > > Where can I find the source code for the Android version? I had a look
> > > in the CVS repository (which I have commit access to), but couldn’t find
> > > it there.
> > 
> > Currently it is at github,  https://github.com/tux4kids/Tuxpaint-Android
> > and the android strings are under res/values-xx dirs.
> > 
> > […]
> > 
> > If somebody wants to help with the android port in github, I will be
> > very happy to provide commit access.
> 
> I won’t be able to help with the actual port, but if it’s possible for 
> translators to have commit access, I would appreciate having access (my 
> username is ‘huftis’), to be able to commit updated translations.

Sent an invite, if anybody else wants also commit access, please tell it.


> 
> Regarding the translation process, I discovered that it’s possible to 
> generate normal POT/PO files for translating Android apps. This is much 
> easier (and less error-prone) for translators, as they can use their 
> usual PO editors instead of having to hand-edit (and keep up to date) 
> .xml files.
> 

Nice, so we can make a couple of scripts that generates the POs<->strings
most like the ones used for stamps.

> I have tested this. Using the ‘android2po’ tools, running the following 
> command
> 
>    a2po init --groups strings
> 
> generates a ‘template.pot’ file POT based on the ‘strings.xml’ file in 
> the res/values folder, along with ‘xx.po’ PO files (where ‘xx’ is a 
> language code), based on the corresponding strings.xml files in the 
> res/values-xx folders. Whenever you add or strings, run
> 
>    a2po export --groups strings
> 
> to generate updated POT and PO files. When you receive updated PO files 
> from translators, run
> 
>    a2po import --groups strings
> 
> To generate PO files for new languages (e.g. xx, yy and zz), run
> 
>    a2po init xx yy zz --groups strings
> 
> (It’s important to do things this way to ensure that the PO files 
> contain the correct rules for plural strings.)
> 
> The ‘--groups’ option is needed to avoid a2po also extracting the 
> ‘arrays.xml’ file. When there is only *one* file to translate 
> (strings.xml), a2po generates ‘template.pot’ and ‘xx.po’ files. If you 
> have several string files, you have to use this syntax:
> 
>    a2po import --groups strings uistrings
> 
> The tool will now instead generate ‘strings.pot’, ‘uistrings.pot’, 
> ‘strings-xx.po’, ‘uistrings-xx.po’ (and no ‘template.pot’ and ‘xx.po’ 
> files). Use the ‘--layout’ option to choose a different directory or 
> filename layout for the POT and PO files.
> 

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Translating the config activity of the Android version

[Karl Ove Hufthammer <karl@hu...>]

Pere Pujal i Carabantes skreiv 29. juli 2017 16:30:
>> Where can I find the source code for the Android version? I had a look
>> in the CVS repository (which I have commit access to), but couldn’t find
>> it there.
> Currently it is at github,  https://github.com/tux4kids/Tuxpaint-Android
> and the android strings are under res/values-xx dirs.
>
> […]
>
> If somebody wants to help with the android port in github, I will be
> very happy to provide commit access.

I won’t be able to help with the actual port, but if it’s possible for 
translators to have commit access, I would appreciate having access (my 
username is ‘huftis’), to be able to commit updated translations.

Regarding the translation process, I discovered that it’s possible to 
generate normal POT/PO files for translating Android apps. This is much 
easier (and less error-prone) for translators, as they can use their 
usual PO editors instead of having to hand-edit (and keep up to date) 
.xml files.

I have tested this. Using the ‘android2po’ tools, running the following 
command

   a2po init --groups strings

generates a ‘template.pot’ file POT based on the ‘strings.xml’ file in 
the res/values folder, along with ‘xx.po’ PO files (where ‘xx’ is a 
language code), based on the corresponding strings.xml files in the 
res/values-xx folders. Whenever you add or strings, run

   a2po export --groups strings

to generate updated POT and PO files. When you receive updated PO files 
from translators, run

   a2po import --groups strings

To generate PO files for new languages (e.g. xx, yy and zz), run

   a2po init xx yy zz --groups strings

(It’s important to do things this way to ensure that the PO files 
contain the correct rules for plural strings.)

The ‘--groups’ option is needed to avoid a2po also extracting the 
‘arrays.xml’ file. When there is only *one* file to translate 
(strings.xml), a2po generates ‘template.pot’ and ‘xx.po’ files. If you 
have several string files, you have to use this syntax:

   a2po import --groups strings uistrings

The tool will now instead generate ‘strings.pot’, ‘uistrings.pot’, 
‘strings-xx.po’, ‘uistrings-xx.po’ (and no ‘template.pot’ and ‘xx.po’ 
files). Use the ‘--layout’ option to choose a different directory or 
filename layout for the POT and PO files.

-- 
Karl Ove Hufthammer

Re: [Tuxpaint-devel] [Tuxpaint-i18n] Translating the config activity of the Android version

[Pere Pujal i Carabantes <perepujal@gm...>]

El ds 29 de 07 de 2017 a les 15:57 +0200, en/na Karl Ove Hufthammer va escriure:
> Pere Pujal i Carabantes skreiv 01. juni 2017 00:49:
> > the Android version of Tux Paint is slowly becoming ready, now I've just made the config activity translatable, but before calling for
> > translations,
> 
> Where can I find the source code for the Android version? I had a look 
> in the CVS repository (which I have commit access to), but couldn’t find 
> it there.
> 
Currently it is at github,  https://github.com/tux4kids/Tuxpaint-Android
and the android strings are under res/values-xx dirs.

The original(SDL2 based *) tuxpaint's code is under the jni dir among all 
the libs needed to get it compiled for android.

Note that I am in the process of changing the android build process from 
ant to gradle https://github.com/perepujal/Tuxpaint-Android and thus the
dirs will be reorganized app/src/main/res app/src/main/jni and so on.

If somebody wants to help with the android port in github, I will be 
very happy to provide commit access.

Thanks
Pere


* https://sourceforge.net/projects/tuxpaint-sdl2/

[Tuxpaint-devel] [fwd] Tux Paint's turning 15!

[Bill Kendrick <nbs@so...>]

----- 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 -----

Re: [Tuxpaint-devel] tuxpaint-sdl2 on sourceforge

[Pere Pujal i Carabantes <perepujal@gm...>]

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

[Tuxpaint-devel] tuxpaint-sdl2 on sourceforge

[Jacques Chion <jacques.chion@or...>]

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

Re: [Tuxpaint-devel] New beta on f-droid.

[Pere Pujal i Carabantes <perepujal@gm...>]

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

Re: [Tuxpaint-devel] 5/15 updates to MacOS Sierra compile (SDL2)

[Pere Pujal i Carabantes <perepujal@gm...>]

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

Re: [Tuxpaint-devel] 5/15 updates to MacOS Sierra compile (SDL2)

[B.J. <bj@ko...>]

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

Re: [Tuxpaint-devel] 5/15 updates to MacOS Sierra compile (SDL2)

[Pere Pujal i Carabantes <perepujal@gm...>]

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

Re: [Tuxpaint-devel] 5/15 updates to MacOS Sierra compile (SDL2)

[B.J. <bj@ko...>]

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)
 

[Tuxpaint-devel] 5/15 updates to MacOS Sierra compile (SDL2)

[B.J. <bj@ko...>]

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.

[Tuxpaint-devel] more MacOS issues: checking for SDL1 calls

[B.J. <bj@ko...>]

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)

[Tuxpaint-devel] New beta on f-droid.

[Pere Pujal i Carabantes <perepujal@gm...>]

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

Re: [Tuxpaint-devel] SDL_CreateThread call

[Pere Pujal i Carabantes <perepujal@gm...>]

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

Re: [Tuxpaint-devel] SDL_CreateThread call

[B.J. <bj@ko...>]

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

Re: [Tuxpaint-devel] SDL_CreateThread call

[Bill Kendrick <nbs@so...>]

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

Re: [Tuxpaint-devel] SDL_CreateThread call

[Pere Pujal i Carabantes <perepujal@gm...>]

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

[Tuxpaint-devel] SDL_CreateThread call

[B.J. <bj@ko...>]

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

Re: [Tuxpaint-devel] Any Mac developers out here?

[B.J. <bj@ko...>]

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