[Tuxpaint-devel] Tux Paint 'indent'-ified!

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

Tux Paint's source code has been in terrible shape, formatting-wise,
for many years.  Combinations of tabs and spaces, along with various
people's styles (or lack thereof) caused things to look fairly
terrible and no doubt would scare off any newcomers who might want
to contribute to the project.

So, I've just run `indent` on basically the whole codebase (some
Mac-specific Objective C stuff was untouched, but a few header .h
files were).

The main source code directories (src/, magic/src/, and macosx/)
have an `indent` config file (`.indent.pro`), so it should be
simply a matter of running

  indent SOMEFILE.c

after adding or modifying a file, to keep the formatting consistent.

Note that, at least the way I _intended_ it to work, is for
`.indent.pro` to live in src/, while the other two copies are
symbolic links to that file.  Seems to have worked, in Git, but
YMMV depending on what platform you're checking things out on.
(e.g. https://sourceforge.net/p/tuxpaint/tuxpaint/ci/master/tree/macosx/.indent.pro)

FYI, the options I preferred were:

--blank-lines-after-declarations
--blank-lines-after-procedures
--break-before-boolean-operator
--continue-at-parentheses
--declaration-indentation1
--dont-break-function-decl-args
--dont-break-procedure-type
--line-length120
--no-blank-lines-after-commas
--no-space-after-casts
--no-space-after-function-call-names
--no-space-after-parentheses
--no-tabs


FWIW, things still seem to run for me. :)  Let me know if you have any issues.
And of course, be sure to `git pull --all` ASAP, before making any code changes,
so that you're also working off the latest, nicely-formatted codebase!

Thanks,

-- 
-bill!
Sent from my computer

Re: [Tuxpaint-devel] Creatng Git repo at SF.net for Tux Paint! [Fwd: CVS support at SourceForge and Nov. 30]

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

On Mon, Oct 09, 2017 at 12:23:06PM -0700, Bill Kendrick wrote:
> 
> I am currently following the steps to create a Git repository
> under the main "tuxpaint" project, and importing the various
> important modules (tuxpaint, tuxpaint-stamps, tuxpaint-config, tuxpaint-website).
> 
> I'll see about updating the tuxpaint.org website to reflect the new
> reality (fetch from Git, not CVS), when I have some time.

I've updated the website.  Please consider CVS deprecated!

For info on Git, see:

  http://tuxpaint.org/download/source/git/

Or just go to the Git page for the Tux Paint project:

  https://sourceforge.net/p/tuxpaint/_list/git

-bill!

[Tuxpaint-devel] Creatng Git repo at SF.net for Tux Paint! [Fwd: CVS support at SourceForge and Nov. 30]

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

I am currently following the steps to create a Git repository
under the main "tuxpaint" project, and importing the various
important modules (tuxpaint, tuxpaint-stamps, tuxpaint-config, tuxpaint-website).

I'll see about updating the tuxpaint.org website to reflect the new
reality (fetch from Git, not CVS), when I have some time.

-bill!


----- Forwarded message from SourceForge Support <cvsdecomm@...> -----

Date: Sat, 07 Oct 2017 16:22:38 +0000
From: "SourceForge Support" <cvsdecomm@...>
Subject: CVS support at SourceForge and Nov. 30
To: nbs@...

Greetings project admin,

We have been planning to discontinue CVS support here at SourceForge for several years now, and that time has finally arrived. Since your project is making use of CVS for your source version control, you should now convert your repository over to another version control system.

The current plan is to stop allowing CVS commits by November 30th. To be able to continue making source code changes you???ll need to have your CVS repo converted by then. The ssh access method will stop working, but read-only access via both pserver, rsync, and interactive shell will continue to be available past the cutoff date (we haven???t determined if or when the read-only support will end). This means that you will have plenty of time to convert your data to a new SCM format, even well past the cutoff date.

If you don???t have a particular SCM choice in mind, we recommend choosing Subversion (SVN) since it has a workflow that is most similar to that of CVS. You might also want to choose Git, which is very popular these days, though it does have a steeper learning curve compared to switching to Subversion. You can even give each one a try and keep the one you like best. Don???t be afraid to experiment.

For information on how to convert your repository from CVS to SVN or Git, visit the following web page: https://sourceforge.net/p/forge/documentation/CVS/

The page also documents the rsync backup method.

We hope that your conversion goes smoothly. You can let us know if you run into any issues by replying to this email.

Sincerely,

SourceForge Support



----- End forwarded message -----

-- 
-bill!
Sent from my computer

[Tuxpaint-devel] New Android version in f-droid, 0.9.23 beta 10

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

Hi all,

Finally I could get another update in fdroid
You could download it from https://f-droid.org/packages/org.tuxpaint/ or just from your fdroid app


Changes from beta 8 to beta 10:

Keep the screen alive setting in the config activity.

It now builds with gradle, I had to change from ant due to some problems with fdroid and ant deprecation.
The build process of Tux Paint for Android is documented in the README.md at github

Glib, SDL2,... updates to the latest version. As a side effect it now only runs from Android 3.1 onwards, SDL2 needs it for joystick support.

The config activity is now translatable.


Things to do:

change the language on the air in the config activity

change the "locale" selector to "language" selector
i.e. people should see "Français" or "French" or whatever it is called in the currently used language instead of fr_FR 

Tools to convert translations from/to Android xml format from/to .po format so we can use the usual gettext tools

More translations :)

Tests, lots of testings :)

Stamps downloader



I don't know when I will get time to dedicate to Tux Paint again, things are really exciting those days in Catalonia, both for the best and for the
worst, wish us luck

Pere

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