GitLab

Copy and paste coding made the default value the selected one in the
"Color Profile" frame, not the value from ScreenshotValues.

Return only the config object's GType and do the g_object_new() in the
caller (one caller only needs the type, there is no need to create a
dummy object just to get to its type).

around calling the actual execute vfuncs, Seen a crash when quitting
GIMP while a script-fu window was open, the progress was already
finalized. Now it simply prints the error message about the failing
script on the concole.

it didn't even remember its GimpColorConfig, so had no chance of
setting it on the dialog's GimpColorSelection.

libgimpwidgets now needs an initialized babl if color selectors are
used, call babl_init() in gimp_widgets_init(). It can be safely called
redundantly.

Handled internally by gimp_scanner_parse_float(), since last commit.

so they show up in recent filters, and don't need their own callbacks.

This has the problem that they now show a GUI with no options, but
that simply puts on more pressure to fix this general uglyness of ops
without editable properties.

by removing one if() level each from the nested loops. Instead,
continue the loop early if the file is hidden. And plug a memory leak.

This reverts commit 2aa246f5.
As per Mitch request since painting is already too slow.
This may come back when we make painting fast again, I guess.

Committed with minor fixes by the reviewer (Jehan).

As a consequence of commit efae55a7, plug-ins should not install
data/library files alongside on the root plug-ins/ directory. If they
have such files, they should create a subdirectory named as the entry
point file. Obviously we should be the first to follow this guideline.
We had one such plug-in: python-console.py, which is importing
pyconsole.py. Let's have both these files under
plug-ins/python-console/.

We don't search recursively but only at the first level. If a plugin is
in its own subdirectory, the entry point has to be named the same (minus
extension) as the directory. For instance my-plugin/my-plugin for a
binary, or my-plugin/my-plugin.(py|exe|…).
This way, a plugin can load shared objects (libraries, other script
files, etc.) without polluting the main plug-ins directories, and in
particular without interfering with other plug-ins.
This is a first step to fix bug 757057 (DLL files which were used in
various plugins).

This way we can be warned quickly about any AppStream issue (cf. bug
782759). This test requires web access for screenshot verification.
Packagers are invited to use --without-appdata-test option if they want
to skip the test (for instance if build environment has restricted
network access).

Even though there is automatic redirection anyway, better to explicitly
set https. :-)

Commit 1e6acbd4 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).

Adding a second screenshot showing painting capabilities.

just to keep the diff small for an hack on the gtk3-port branch.

only the GtkObjects in the public API left now, can't change these until 3.x

Thanks to a new photo-editing screenshot from Patrick David.
A second screenshot for painting coming up soon as well.

The layer blend space, composite space, and composite mode
properties have a special AUTO value, which may map to different
concrete values based on the layer mode.  Make sure we can change
this mapping in the future, without affecting existing XCFs (saved
after this commit), by encoding these properties as follows:

When saving an XCF, if the property has a concrete (non-AUTO)
value, which is always positive, encode it as is.  If the property
is AUTO, which is always 0, encode it as the negative of the value
it actually maps to at the time of saving (note that in some cases
AUTO may map to AUTO, in which case it's encoded as 0).

When loading an XCF, if the encoded property (stored in the file)
is nonnegative, use it as is.  Otherwise, compare the negative of
the encoded property to the value AUTO maps to at the time of
loading.  If the values are equal, set the property to AUTO;
otherwise, use the concrete value (i.e., the negative of the value
stored in the XCF).

Note that XCFs saved prior to this commit still load fine, it's
simply that if we change the AUTO mapping in the future, all their
AUTO properties will keep being loaded as AUTO, even if the
resulting concrete values will have changed.

... to the warp tool

The interpolation and abyss policy options control the sampler type
and abyss policy of the map-relative node.  The high quality preview
option determines whether to use the same sampler for map-relative
during preview as the one used during commit, or whether to use a
fast nearest-neighbor sampler.

A bit too much?  Maybe :)

When converting from CMYK to RGB, it's perhaps better to use the
CMYK->RGB transform, rather than the RGB->CMYK transform...

it doesn't need a visible GdkWindow.

and reduce the indicator to 2/3 of the area's shorter side.

... to be more similar to the paint options.

... and to disable/control the rate of the periodic stroke.

The warp tool is now fast enough to enable stroking directly in
the motion handler, which gives better-quality response to motion
than stroking periodically.  It's not quite fast enough to enable
exact motion, though :/

Allow individually enabling/disabling stroking during motion and
periodically, and allow controlling the rate of the periodical
stroke.