This is to be used as self-documentation code, so that people know
how to hack the font size since I am not sure GIMP will always provide
reasonable font display on every platform.
Otherwise the file won't be included in the tarball (another consequence
is that `make distcheck` will fail) since this binary is not made the
common automake way on purpose.
Partially reverts commit 84439a8748.
The fact that tools/invert-svg was kind of manually compiled was on
purpose. Using the automake syntax with any of the *_PROGRAMS compiles
for the host OS, but this tool is only for compile-time.
This fixes cross-compilation.
As for compute_svg_viewbox, let's not build it for now because its
purpose was to help proper extraction of SVG icons from a single SVG
file. Unfortunately librsvg was not providing acceptable results anyway
so right now all SVG icons are manually exported. We keep the code for
future use when the library will improve.
Filters settings used to be serialized and deserialized only
when a filter tool's GUI was shown, too late for the code that
re-runs/re-shows filters with previous values.
Move the entire loading/saving code to gimp-operation-config.c, even
adding/removing the dummy separator item between timestamped automatic
history and manually saved settings. Load the settings automatically
when a settings container is requested, but still trigger saving from
the few places the container is changed in the GUI; could also
automate that later.
This commit also moves all settings of filters that have their own
tools from gimpdir/tool-options/ to gimpdir/filters/. Add compat code
to try the old filename if the new doesn't exist, so files are
migrated automatically.
WIP, but this step already fixes the bug.
Both in the GimpImage API and in the GUI. The toggle in the save
dialog now controls ZLIB compression directly. Changed the various
info labels accordingly. Ditch the XCF parasite that saved the XCF
compat mode.
This reverts commit 2226fb1dc8.
It doesn't make much difference right now, will work the same on
native builds and be broken on cross-builds.
I need to fix how invert-svg is built (broken on commit 84439a8),
so that it is a build executable again. Work in progress.
But since it makes no difference right now, let's just revert this
one already.
Commit 4beff2f was basing it on the screen y PPI but that is not really
consistent or logical actually. Since the actual stroke dialog uses the
y resolution of the current image, it makes sense that the generic
stroke defaults in the preferences should use the y resolution of the
default image.
BUILD_EXEEXT was not properly set (config macro AX_PROG_CC_FOR_BUILD).
Apparently we need aclocal/automake version 1.13 or higher and to
distribute ax_prog_cc_for_build.m4 ourselves to benefit from a fix
released only in autoconf 2.69.
Thanks to Éric Hoffman for reporting and investigating on this.
Automake 1.13 apparently dates from 2012 and debian testing provides
a newer version (automake 1.15) so it should be ok to update it. Also
that's only a build dependency.
Enable 64 bit file offsets in XCF files, starting with newly added XCF
version 11.
We use at least version 11 if:
- we would use the previous version 10 (essentially skipping 10)
- the in-memory size of the image is larger than 4 Gig
Change the xcf_read_foo() functions to take the XcfInfo* instead of
a GInputStream*, and make them advance the info->cp offset by
themselves. Makes xcf-load.c a lot more readable.
Step one, without changing anything in the saved XCFs yet:
Abstract reading and writing of file offsets away into their own
xcf_read_offset() and xcf_write_offset() functions, which take
"goffset" instead of "guint32". Also change xcf_seek_pos() to take a
goffset argument.
Change all file offset variables in xcf-load.c, xcf-write.c and struct
XcfInfo to goffset, and add new member "bytes_per_offset" to XcfInfo,
which is currently always 4.
One cannot just use the min/max values since the precision digits must
also be accounted for (as well as one additional character for the
decimal separator).
Current implementation is not perfect yet because GimpSizeEntry code
itself does not yet use gimp_unit_get_scaled_digits(). Moreover the
entry size could be updated when changing units (or the original size
be actually based of the bigger width considering every possible unit).
This value could be based on either the x or y resolution, or maybe some
kind of mean values. It could also be based off the print resolution of
any image (if the user sets a physical dimension, the actual pixel width
will vary depending on the print resolution). There is no actual "good"
answer here. But any of these values will be better than a default 96.0.
The abbreviated commit hash we show in the shell and the about
dialog is currently just the last 7 characters of 'git describe',
based on the assumption that abbreviated hashes are always 7-digits
long. When the hash is longer than that, we're just showing a
nonsense commit.
This was never a good idea, since users can override this, and
since disambiguation can result in longer hashes, but since git
2.11, the default abbreviated hash length is determined based on
the size of the repository, which currently results in 10 digits
for us.
Let's just do it right.
It is a little fuzzy whether expected or not, architecturally-wise. On
one hand, I can see some core/ header includes under config/. Though on
the other hand, app/Makefile.am explicitly sorts config/ below core/.
Anyway let's just use g_cclosure_marshal_VOID__VOID which is the same as
gimp_marshal_VOID__VOID and get rid of the include.
This fixes builds from scratch.
It was agreed that we should write "plug-in" consistently. Only possibly
user-visible strings were updated.
Thanks to scootergrisen for a first patch which could not make it
after changing decision on the canonical writing.
Current code only guess resolution for a single monitor. Ideally
the widget sizes could be different depending on the window where a
given widget is on. But that's a start.
In particular all rotate/flip actions can apply to an image or drawable.
Let's make it clear, especially when it is run out of the menu context,
for instance in the action search.
This is a bad hack that hardcodes a special case for
GIMP_TYPE_DESATURATE_MODE right into gimp_prop_enum_combo_box_new(),
we should think of something better if we get more special cases.
which unlike HSL Lightness is actually physically meaningful and
also generally speaking much more useful than HSL Lightness.
Change "Lightness" to "Lightness (HSL)" to make it clear that
the "Lightness" in the Colors/Desaturate/Desaturate menu is not the
same as "Lightness" in LAB/LCH.
For completeness add the option to desaturate to "Value (HSV)".
Add links in app/operations/gimpoperationdesaturate.c
to the Wikipedia article with definitions of L/I/V in HSL/HSI/HSV.
Use gimp_item_translate() instead of gimp_item_set_offset() to set
a pasted item's position, so that the offsets of pasted layer group
children are updated correctly. Otherwise, only the group itself
moves, while its children remain positioned relative to the top-left
corner of the image.
... since that's the color space it actually works in.
Keep the legacy "Color (HSV)" mode's name as is, wrong as it is,
since, well, that's what it used to be called...
No need to do full back and forth RGB/HSV conversions.
Change the behavior such that fully desaturated values remain
desaturated, instead of saturating towards red.
Jehan