A crosshair appears when you first click, to show the source
position. It then moves along with the source, as you drag
after the second click (moving relative to the mouse).
Usefull for people with coarse input devices that need bigger buttons but got color buttons too narrow.
Just added the option, all the support code where already in place.
Some already-translated (but very out-of-date) content
has been replaced with not-yet-translated (i.e., English) content.
Translators may want to look at the previous revisions of these
files when translating the new 'tuxpaint-docs' gettext catalog.
Sorry to cause extra work here, if I've done so.
For simplicity, sticking to English in the filenames for now,
sorry! (e.g., "LEEME" -> "README", and "OPCIONES" -> "OPTIONS")
We can consider a method of localizing the _filenames_ again,
if there's demand.
Some already-translated (but very out-of-date) content
has been replaced with not-yet-translated (i.e., English) content.
Translators may want to look at the previous revisions of these
files when translating the new 'tuxpaint-docs' gettext catalog.
Sorry to cause extra work here, if I've done so.
Documentation is now maintained in a separate source repository,
'tuxpaint-docs', which allows for easier and more consisten
translation of the documentation. Pulling in initial version of
these docs, which contain a variety of minor updates (and also a
few which had previously only been available as plain TXT are now
available as HTML).
Pulling in the English stuff.
About to drop in generated docs from the new 'tuxpaint-docs' repository.
As the directories will have more explicit names (e.g., "fr_FR.UTF-8"
rather than just "fr") and Spanish ("es") and French ("fr") already
exist (though they are very basic samples, 99+% untranslated so far),
renaming the current directories to match.
They were rendering very large, and shorter strings were
being shrunk down less horizontally, so appearing stretched out
(and touching the edges of the button needlessly).
We received a report of Tux Paint generating too much heat on a MacBook
Pro (15-inch, 2017 running macOS Mojave 10.14.6). The bug report
included a screenshot of Activity Monitor's Energy Tab showing Tux Paint
having an Enegy Impact of "23.4" and Avg Energy Impact of "3.94".
Although we weren't able to reproduce the same conditions exactly, we
did observe Tux Paint having an Energy Impact level of around ~15 even
when idle on both macOS Yosemite 10.10.5 and Big Sur 11.1. Energy
Impact leve of ~25 when in use was not uncommon, and spiked to ~55. The
MacBook Air used for testing (11-inch, Early 2014) did not become hot
"to the touch" as was originally reported, but it did become noticibly
warm.
An investigation found the cause to be in two places:
1. Tux Paint's main loop runs fairly tightly, yielding only a minimum
time slice to the kernel after each iteration using SDL_Delay(1)
(1 millisecond). This has been increasd to 10 millisecond to give
more slice back to the kernel. Increasing the 1ms yield to 10ms
should be only minimally noticible as Tux Paint is primarily a human
interaction software and human eyes perceive responses < ~100ms as
immediate, giving us over 90ms to accomplish what we need to after
each iteration as opposed to the previous 99ms.
2. Enabling SDL's timer subsystem (SDL_INIT_TIMER), even when not used
actively, has a high impact on the energy impact. Some testing
showed the timer subsystem, though supposedly a part of SDL_Delay() and
SDL_GetTicks(), is not required to be enabled to use those functions.
It does require to be enabled, however, to use SDL_AddTimer() which
is only used in Tux Paint when scrolling. Tux Paint therefore has
been modified to enable the timer subsystem only when scrolling
starts and disable it when not scrolling.
The solution to #2 is not an ideal approach but it did provide a quick
solution to the user having the problem. Issue #2 should get resolved
naturally when we upgrade to SDL2 where the timer subsystem does not
appear to have the energy impact issue.
Tux Paint's export features will fail if the parent
of the export directory didn't exist. e.g., using the
default (either via XDG or hard-coded fallback) of
"~/Pictures/TuxPaint/", Tux Paint could not export if
"~/Pictures/" didn't exist yet. It will now try to
mkdir it as well. h/t Tim Dickson
Updated OPTIONS documents to explain this.
Also, documenting --exportdir in manpage (was missing!)
