The value descriptions of GimpGradientColor,
GimpGradientSegmentColor, and GimpGradientSegmentType enums appear
in the on-canvas gradient editor UI, as combo-box items in the tool
GUI overlay. Since we want to keep the overlay as small as
possible, we previously used abbreviations for these descriptions
(e.g., "FG (t)", instead of "Foreground (transparent)").
Replace the abbreviated descriptions with unabbreviated ones, and
move the abbreviations to the "abbrev" parameter. This way we get
the abbreviated version in the combo-box, and the full version in
the combo-box's menu.
Update the dprod production of generated enum files to include
abbreviated value descriptions, as per the previous commits.
Add a comment for translators above the abbreviated descriptions,
specifying the full description they abbreviate.
Add support for specifying an abbreviated description for enum/
flags values, which can be used in contexts where the full
description is too long.
Since the exact layout and size of Gimp{Enum,Flags}Desc is part of
the ABI, we can't simply add a field to these structs to hold the
abbreviated description. Instead, we use the fact that entries
with a repeated value in the value descriptions array are ignored,
and that the array is NULL terminated (in particular, that all non-
NULL entries are followed by at least one additional entry), and
specify the abbreviation in the "value_desc" field of the entry
that immediately follows the initial entry for a given value,
setting the "value" field of both entries to the same value.
Right now this behavior is undocumented, so there is no proper way
to specify abbreviated descriptions in the API, and is only meant
to be used in generated enum files.
to gimp_base_compat_enums_init() and move its prototype from
gimputils.h to gimpbase-private.h; it's not supposed to be
public API even though it's callable from the outside.
Allows setting the midpoint's position, blending function, and
coloring type.
The midpoint can be converted to a stop, and centered, through
editor buttons.
...protocol calls.
Some calls are waiting for answers, for instance plugin procedures, and
tiles which expects data and acknoledgement.
This would result in error messages such as:
"expected tile ack and received: 5" (5 is GP_PROC_RUN)
Typically because a thread would run a procedure while another would
receive tiles.
...on macOS (with macports)
Changed gimp_metadata_get_guid() to use a GRand that automatically
seeds itself from /dev/urandom (if available) or the current time.
...resources to be loaded and shown multiple times
Change gimp_path_parse() to filter out duplicate paths. This is the
function at the bottom which is used by everything else, so should
generically catch all duplicates.
Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
Add the additional enum values to enum GimpSelectCriterion, and
the few needed lines to gimppickable-contiguous-region.c.
It's horribly slow, but works.
We check them into git, so this makes it easier to keep them in
sync when using a separate build directory.
Case in point -- this commit also syncs a few enum files that went
out-of-sync with their headers.
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.
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.
being exported to libgimp, and having a non-exported value, this is a
horrible mess like with GimpLayerMode, but at least the cruft value
names are deprecated now.
C++ won't allow us to use GimpLayerMode in the API where we used to
have GimpLayerModeEffects.
Move GimpLayerModeEffects to libgimpbase/gimpcompatenums.h so it's
not in the API any longer, and instead typedef and define stuff in
libgimp/gimptypes.h, and adapt the compat enum registering code
accordingly.
Which are entirely private (not installed). They contain compat values
for enums where values have been renamed in gimpbaseenums.h. The old
names get the old nicks generated so the new values in gimpbaseenums.h
can have proper new nicks. Register them as compat enums using
mechanism introduced for the GimpLayerMode change.
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
Ell