Add signal GimpTextBuffer::color-applied which is emitted when text is
inserted or when color is applied to a span of text.
In GimpTextTool, connect to the signal and update the global color
history.
Unrelated: rename gimp_text_tag_get_color() to get_fg_color() and add
boolean return values to get_fg_color() and get_fg_color() which
indicates if a color is set on the tag at all. This ended up unneeded
in the fix but is an improvement regardless.
Since commit d916fedf92, GIMP has had the hidden feature to salvage
images (if possible) during a crash into a backup folder. This commit
finishes the feature by opening a dialog proposing to try and recover
the salvaged images.
This is not perfect yet since it doesn't "remember" the XCF path (in
case it was a previously saved image). The images open as new unsaved
and dirty images, but directly from the contents at crash time. For now,
it is up to people to figure out what they correspond to, if relevant.
In gimp_gegl_apply_scale(), use a CLAMP abyss policy for the scale
op, to avoid leaking transparency into the image when scaling
drawables.
Note that this (intentionally) only affects whole-image/layer
scaling, and not scaling done using any of the transform tools.
In gimp_gegl_apply_{border,grow,shrink,flood}(), which are used
by the corresponding channel functions, pass crop_input = TRUE to
gimp_gegl_apply_operation(), to clip the input to the output rect.
These operations process the entire input in one go, regardless of
the requested output region; however, the channel functions
calculate the output region according to the known channel bounds,
hence clipping the input to these bounds doesn't affect discard any
information, while avoiding unnecessary work. In particular, this
makes the corresponding operations on small selections in big images
much faster.
Add a crop_input parameter to gimp_gegl_apply_[cached_]operation().
When TRUE, the functions crop the op's input to the destination
rect. This is particularly useful for functions that process the
entire input in one go (by means of get_cached_region()). See the
next commit.
Pass crop_input = FALSE at all call sites for now, to keep the
current behavior.
After many discussions, it has been decided to export the metadata by
default since it seems to be what many people would expect and they
would consider they "lost" metadata (especially if they overwrite their
original). I don't entirely agree since privacy (particularly if you are
not aware of metadata and information they may contain) is also an issue
but not many seem to agree with me.
So here it is! All metadata now exported as a default!
The debug dialog is awesome and extremely helpful, but I realize it may
be a better default experience on *stable* to raise it only in case of
crashes. CRITICAL are bad and should be fixed, but sometimes their
consequence is actually not visible except for this dialog, and people
on stable builds may prefer not to see this dialog. Also we will likely
get a lot of duplicates for the same bugs once everybody has this by
default, which will be very annoying to attend to, unless we had
automation (which we don't right now).
The option is still available in preferences anyway so people really
interested in helping can activate the option for CRITICAL and even
WARNING anyway, even on stable releases.
Exchanging with OpenJPEG developers and searching more on the topic, it
seems that YUV is more often refered to as YCbCr. Wikipedia says:
> typically the terms YCbCr and YUV are used interchangeably, leading to
> some confusion. The main difference is that YUV is analog and YCbCr is
> digital
As for eYCC, I am told this is extended YCC. It seems this is refered as
xvYCC (I really can't find much under "eYCC"). So let's rename it too.
Hopefully I made no mistakes!
JPEG 2000 codestream doesn't have a header and guessing the color space
in particular is not foolproof (especially when 3 or 4 components, which
can be many spaces). Therefore the need of a parameter on the API.
Note that JP2 images should always have the color space information. In
interactive mode, I try to be a bit flexible to salvage broken JP2 with
no color space information in the header, but I am not adding a
parameter in file-jp2-load() (on purpose, since we are not going to add
in the API a parameter for a case not supposed to happen with properly
encoded files).
JPEG 2000 codestream (.j2k/.j2c) are only compressed code stream data,
without header. In particular we don't have color information, such as
the color space. So we need to open a dialog asking to set the color
space in interactive mode.
Note: according to OpenJPEG developers, a JP2 image (not codestream)
should always have a color space defined in its header. But just to be
flexible, the same dialog may get raised as well if we try to load a JP2
with no valid color space defined in header and no ICC profile embedded.
Maybe if such a thing happened, it means the image is corrupt, yet we
may as well try and salvage it anyway.
Note 2: I also removed a weird test which was setting some images as
being YUV color space by mistake. This actually fixes bug 794413 as a
side effect.
Even though I haven't seen working samples with this extension,
according to some references, this is a common extension for compressed
JPEG 2000 code stream. Also our old plug-in was listing this extension,
so let's do so now as well.
To this day, the only 2 extensions we used to list in the JasPer-based
plug-in and not in the OpenJPEG one are .jpf and .jpx (JPEG 2000 Part-2)
since OpenJPEG does not have support yet. But actually I think the old
plug-in may have simply been "lying" since JasPer website says the
library is meant to implement JPEG-2000 Part-1 standard.
So I believe we are now on par (and even better on many aspects) with
the former plug-in implementation based on libjasper.
Redo the entire thing again:
- Rename the values of enum GimpColorSelectorModel to include "MODEL"
- Change GimpColorSelector API from set_model() to set_model_visible()
so visibility of each model can be toggled individually and is not
exclusive any longer
- The GUI is back to what it was before, except that the "GIMP" page
now honors the model visibility and has a resonable minimum height
Focus change events were expecting the current tool control to be
inactive, which was the case most of the time. Yet with stylus, the
canvas was sometimes receiving GDK_BUTTON_PRESS events before
GDK_FOCUS_CHANGE. In particular the canvas was receiving a button press
before the focus out, then button release and focus in. Therefore by the
time the focus out event happens, the tool control is active, which
broke a few calls.
Therefore I add a few checks and returns immediately when
gimp_tool_control_is_active() return TRUE, especially since we also run
gimp_display_shell_update_focus() calls after a button press anyway so
the state should already be consistent.
Add a gimp_filter_tool_reset_widget() function, which resets the
tool widget associated with the filter's controller -- i.e., it
resets those properties of the widget that aren't controlled by the
op's properties to some "default" state. For most controller types
this is a NOP; for transform-grid controllers, we move the pivot
back to the center of the drawable, w.r.t. the current transform.
Call gimp_filter_tool_reset_widget() after resetting or reloading
the tool's config.
...only remembers horizontal radius, duplicates it for vertical
Keep a list of the GUI's chain buttons around. When changing the
entire config object like on reset or selecting saved settings, unlik
them all after remembering their "active" state, and after changing
the settings activate the ones that were active before, but only if
the values they link are still the same.
... (gimp-context-set-paint-method...) is called.
GimpContext initialized with standard paint info at constructed() time
to ensure there is always a paint_info even if none were set manually.
This property is currently only used for gimp_edit_blend() to control
how are computed distances. In the future, it could be used for more
functions making use of "gegl:distance-transform" operation, or even for
other algorithms, if relevant.
This new property obviously comes with 2 new PDB calls:
gimp_context_get_distance_metric() & gimp_context_set_distance_metric()
The enums have to be menually registered in pdb/enums-external.pl.
Currently supports enums from GEGL only.
Add enum GeglDistanceMetric as first external enum.
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.
Jehan