Some tag data is hold in GtkEntry, other in GtkTextView, which are not
parent to each other. Previous checks were wrong and resulted in
"invalid cast from 'GtkEntry' to 'GtkTextView'" WARNINGs (followed by
many CRITICALs because of this first error).
Also properly free the data returned by gtk_text_buffer_get_text() which
is allocated (unlike strings returned by gtk_entry_get_text() which must
not be freed).
... scrolling in progress.
In particular, this could happen while panning with mouse middle click
and hitting space. This space should simply be ignored.
Quartz/macOS implementation for the color picker.
This is untested but I am trying to advance our 2.10 blockers by
implementing the base code for this feature. Please anyone with macOS
machine access, review and fix if needed!
The bug was affecting actually both canvas rotation and panning when
done with space key. If the first mouse button was also clicked, then
released after the space key, we ended up in some stuck action. It could
only be unstuck by hitting/releasing space again.
I am actually unsure that this was not originally done on purpose,
especially since the code has these 2 status variables space_pressed and
space_release_pending, but really apart from looking at this code, the
behavior just looks very buggy and impracticable.
The new behavior is to just stop the canvas panning/rotation as soon as
space is released (which is also how it is documented in our manual, and
how everyone seems to use the feature). I only kept the variable
space_release_pending, which I use as was used space_pressed before.
Avoid redrawing GimpCanvasProgress items upon
GimpProgress::set_value() if a minimal amount of time hasn't passed
since the last call. This notably improves performance of
frequently-updated GimpCanvasProgress items.
... when gradient_type >= GIMP_GRADIENT_SHAPEBURST_ANGULAR.
Our current GUI code for the Blend tool options disables the "Repeat"
widget with any of the shaped and spiral gradient types, which means (I
assume) no repeat mode is allowed on these gradients. Nevertheless it
was possible to change the repeat mode in another gradient type, then
switch to one of these and get the repeat processed even though the GUI
shows insensitive.
I could simply reset the repeat mode to GIMP_REPEAT_NONE when setting
one of these gradient types, but I think you'd want the repeat to stay
at its value (being insensitive is enough to mean whatever value is set
is not taken into account). So instead, I just unsync this specific
property when appropriate.
Note also I don't do this in the gimp:blend operation code because I am
not sure this specific behavior is meant to be a generic blend behavior
or just relative to the tool (render of the shaped gradients is barely
different with a repeat, but there is still a difference).
It seems old blend tool (from GIMP 2.8) was using manhattan distance,
whereas the new one uses euclidean. I guess there must be use cases for
both. In any case, it is a good idea to simply propose the option since
the property exists in the "gegl:distance-transform" operation.
See also bug 781621.
Our composite modes don't correspond directly to the Porter-Duff
operators after which they're named, and these names aren't too
descriptive anyway.
Rename the composite modes as follows:
Source Over => Union
Source Atop => Clip to Backdrop
Destination Atop => Clip to Layer
Source In => Intersection
Update relevant code, including UI text, enumerator names, function
names, and action names.
When starting the tool with one of the gradient types for which the
repeat option should be deactivated, it is not. Run the handler function
once at GUI creation.
Also compare the gradient type with an enum value, which makes the test
clearer than using an int.
PDB function gimp_edit_blend() was based on "gimp:shapeburst" operation
whereas the rest of GIMP (in particular, the Blend tool) used
"gegl:distance-transform" which is much faster.
Setting the operation to "manhattan" metric ensures that it still
renders the same way as in 2.8 while being a lot faster.
There was still a problem regarding as how it renders differently from
the Blend tool, but it turns out that the Blend tool is the one
rendering differently from how it used to in 2.8. We should discuss
adding the "metric" property in the tool options.
This operation is currently broken on multi-thread. So disable
multi-threading, at least temporarily (if not forever since apparently
we can get similar output with "gegl:distance-transform", but much
faster and nicer). See bug 781621.
Move gimp-debug-tools.c from tools/ to a new app-tools/ subdir,
which should contain external tools needed by app/, and which is
built *after* app/ (unlinke tools/). This allows gimp-debug-tool
to depend on libapp and libappwidgets, instead of on actual source
files from app/. Building sources from app/ in another subdir
screws with the distclean rules, and breaks distcheck.
After moving up the profile extraction, I was running
gimp_image_set_color_profile() with a non-existing image id, which was
obviously wrong. Reorder a bit the operations.
Also try to guess the color space from the profile not only with
OPJ_CLRSPC_UNSPECIFIED but also OPJ_CLRSPC_UNKNOWN images. Indeed I
encountered a case of .jp2 image with no color space in the header, but
with an embedded profile. And unlike the .j2c files I encountered
earlier, the color space was now *_UNKNOWN.
See https://github.com/uclouvain/openjpeg/issues/1103
Current OpenJPEG code only supported the base JP2 container. It now
supports also the JPEG 2000 codestream (which is usually contained
inside other formats, like the JP2 container format, but can also
sometimes be on its own).
The current magics and extension strings were also mixing all kind of
formats. This is now cleaned up a bit.
As explained in the previous commit, the color space is not always
properly declared, in particular with J2K files. If a profile is present
in such a case, try to deduct the color space from this information.
It seems that the color space is not necessarily declared for a JPEG2000
image. From tests, it looks like it especially happens with JPEG2000
codestream (.j2c or .j2k). This variant is apparently mostly designed to
be embedded (from what I read), which may explain why the color space is
not always set (I assume the embedding format would have the color space
information). Mostly a guess.
If running for instance in a cross-compilation, I need to make clearer
the fact we are looking for a native GEGL and also that we are looking
for the executable (used during the build), not the library. This is a
different test as the one for the library with PKG_CHECK_MODULES (which
looks for the target platform's library).
Move the button-highlight update to its own function, and call it
when the active image changes, as well as when its floating
selection changes.
Call the floating-selection-changed signal handler when the active
image changes, so that we correctly update its row's attributes.
We disallow creating a new layer from a floating selection when its
associated drawable is a channel, so there's no point in
highlighting the "new layer" button in this case. Note that the
"layers-new" action remains sensitive, showing an error message if
activated. Not sure if it's a good thing or not, but whatever.
Darshan kadu