We run shell expansion on configuration arguments,
e.g. `printcommand`, but it would crash if the config
file's input was not quoted, e.g.
printcommand=pstopdf - - > $HOME/print.pdf
Now echo'ing an error to stderr and moving on.
Be sure to quote, e.g.
printcommand="pstopdf - - > $HOME/print.pdf"
The requested font & actual font loaded will be echo'd to STDOUT
when specifying the `uifont` option.
This uses Pango library directly (I was unable to convice SDL2_Pango.h
to actually notice that pango.h was #include'd before it, and expose
its SDLPango_GetPangoFontDescription() function!). This is okay,
since we want to also add a "--uifont list" option (or similar),
that will list all of the available fonts, if a user wishes to
query them. (And similar code will be added to tuxpaint-config to make
the setting available as a pull-down, rather than (or as well as) a
freeform type-in field.)
If not specified, or "default" is specified (e.g., to override
a higher-up config file setting), it will fallback to what we
have #define'd in fonts.h as PANGO_DEFAULT_FONT, "DejaVu Sans".
It appears to fallback to this (or a reasonable fascimile) if
the font specified by the "uifont" option doesn't exist
(e.g., "tuxpaint --uifont=ABCD1234").
For https://sourceforge.net/p/tuxpaint/feature-requests/146/
Final couple of tests to let us avoid creating a template that's
identical to one that already exists. All told, we test the
following (and the first thing that matches causes us to stop
testing that template, and move on to the next, as it appears
to not be identical to the saved image, in its current state)
+ filename prefix (based on saved image's filename)
+ file size
+ image dimensions
+ image contents (via CRC)
Avoid exporting a saved picture to a new template if one already
exists with both the same filename prefix, and now also identical
file sizes (in bytes).
Bugfix - The export function was always dumping chunks that
were the size of the input buffer, which means the final chunk
(which will frequently be smaller) will contain garbage data
beyond the end.
...based on saved files. So far, only looking for identical
template prefix (which is based on the save file's filename).
Next will be to check other fingerprints, in case the saved file
changed after an earlier template was created.
Example
mkdir /tmp/tp
tuxpaint --datadir /tmp/tp
without this fix, choosing "Template" (make a new templat)
from "Open" dialog would result in an error, since
`/tmp/tp/templates` did not exist.
We now `mkdir()` it. This requires, of course, that the
directory specified by `--datadir` _itself_ exists. (We will
not attempt to create anything higher up.)
Places where we attempt to save thumbnails of starters & templates
was trying to `mkdir()` a `.thumbs/` subdirectory in non-existent
`starters/` and `templates/` subdirectories of the "savedir"
location; should be the "datadir" one.
To replicate
mkdir -p /tmp/tp/starters
cp SOMEFILE.png /tmp/tp/starters
tuxpaint --datadir /tmp/tp
then click "New"; observer the warning
Error: Couldn't save thumbnail of saved image!
/tmp/tp/starters/.thumbs/SOMEFILE.png
The error that occurred was:
No such file or directory
When specifying "datadir", Tux Paint's "New" dialog
was able to present templates found in that directory,
but would attempt to load from whatever the user's
"savedir" was, instead.
h/t Giancarlo Orru for reporting the bug.
