Motivation - Without SDL2_Pango, languages like Japanese,
Arabic, and Thai do not render properly. Currently, Debian
(and hence Ubuntu) do not have SDL2_Pango, so Tux Paint 0.9.28
is adversely affected. Fedora DOES have SDL2_Pango, so works well.
This also allows us to delete a lot of ancient cruft code.
Closes https://sourceforge.net/p/tuxpaint/bugs/268/
h/t Pere
(INSTALL docs to be updated momentarily)
Also, add other social media accounts to list of places to
announce Tux Paint in RELEASE docs.
Also, list a ton more options missing from default example config file
"src/tuxpaint.conf"
Previously Pango loaded system-supplied fonts instead, which could lead
to fonts not rendering in a human-readable text. This change fixes
https://sourceforge.net/p/tuxpaint/bugs/265/
Like so --
find . -name "*.c" -or -name "*.h" -exec indent -nbfda -npcs -npsl -bli0 --no-tabs {} \;
The `indent` invocation differs from the last one noted in
CHANGES.txt (from 2006!?), in that I've added "--no-tabs",
to ensure indents are all space-based.
Catching up with latest devel
Still things to solve/do:
Apply label seems to not work, neither in master
Onscreen keyboard size doesn't perform as in master
Test on other OSs, Windows, Android, ...
* macOS language detection has been updated to be backward compatible to macOS
10.10 Yosemite.
It appears older version(s?) of macOS can just return "en" instead of "en-US"
when queried for the preferred locale. Updated code to account for this.
It appears the system language detection doesn't work on [some versions
of?] macOS. Fixed.
Strangely, querying the Cocoa API for the system locale on a system in
US with the preferred language set to Korean produces the invalid locale
"ko-US" instead of the expected "ko-KR". This behavior of returning the
language with a invalid region qualifier for the language appears to
happen only with languages where macOS does not have regional variants
(this issue does not seem to occur with Canadian English, en-CA, for
example.) A fuzzy matching locale function has been added to handle
this issue.
...such as those we seem to be receiving from _nl_locale_name()
on 64-bit Windows under newer MinGW/MSYS (see big thread on
tuxpaint-devel with reports from Shin-ichi).
i18n code was checking for local-related environment variables
(e.g., "getenv("LANGUAGE")") coming back as a NULL if unset.
However, on my laptop, under Kubuntu 20.04 with GLIBC 2.31, a
"LANGUAGE" env. var. is set, but it's blank.
Tux Paint failed to attempt any fallback (e.g., checking "LANG")
in that situation, which was causing the description text corruption
that was corrected in a previous commit.
That commit also mistakenly suggested that the issue might've been a
difference with GCC versions, but the problem was deeper in Tux Paint's
code (in i18n.c), and was triggered by an unexpected environment.
WORK IN PROGRESS -- Attempting to mend an issue where stamp descriptions
are not loading.
Also, making things safer when a problem occurs.
Using gcc 9.3.0 compiler, this was happening in 0.9.25 during
development, but also affected 0.9.24 and 0.9.23, which worked
fine under earlier versions of gcc.
Wrapped some debug output in "#ifdef DEBUG" tests,
and made sure some warnings and errors were going to
STDERR, rather than STDOUT.
Motivation: Less noise while launching/using Tux Paint,
unless it matters.
