Also fix a bit of "Since:" annotations, some minor spacing fixing and
remove one useless test (if we test if a type is an item, we don't need
to test the children drawable type).
This patch adds a GimpItemChooser widget
for use in GimpProcedureDialog Item parameter
GUI creation.
This will deprecate the existing
GimpDrawableChooser, as it covers all the
same cases plus others such as GimpPath.
In 85d381bd, we fixed pass through layer groups to match
the size of the group render, allowing for filter effects to
be applied on all layers below.
This patch extends that fix to layer masks created on pass
through layer groups. This allows you to create a mask and
then selectively hide/show effects on the layer below,
like a maskable adjustment layer.
Previously, changing the color via the GimpFillEditor color button
immediately pushed each intermediate value into the color history,
polluting it with transient previews. Only the final choice
confirmed by the user should be recorded.
Now the color is recorded in the history only when the user explicitly
confirms the selection (e.g. OK/Apply), preventing noisy
history entries while preserving the expected behavior when a color
is accepted.
core: add spaces to fix alignment
As of GLib 2.86.1-1, GFileMonitors created with the
G_FILE_MONITOR_WATCH_HARD_LINKS
flag are not monitored on Windows.
This means that link layers will not
automatically update when the external
source is edited.
We will temporarily use the
G_FILE_MONITOR_NONE flag on Windows
until this is resolved
Per review, let's avoid having all the tools history in every
GimpContext.
Also a further commit will work on special-casing filter tools, which is
why we are storing up to 3 tool infos, instead of only 2.
New action "Last Tool" ("context-tools-swap"), defaulted to <shift>X.
Thanks to Damien de Lemeny for the original patch and Alexander Hämmerle
for the test case in test-ui.c.
This reverts commit 7b023177a8 and reimplement it as a CRITICAL because
if this happens, a bug has occured. If so, we don't want to hide the
bug, we want to be warned of it so that we can investigate further.
Clearly it should simply not be possible to create a parasite with a
NULL name. First if we look at xcf_load_parasite(), we were already
returning early when the name was NULL. Also even the constructor
gimp_parasite_new() has an early check and will return NULL on a NULL or
empty name.
So the question is: how come we had a parasite with NULL name (if that
is really the problem)? I don't have the answer to this and it's
possible that this bug had already been fixed somehow. But in any case,
if it happens again, we'll want this CRITICAL to run.
Sometimes, probably due to a metadata corruption, a pasarite with a NULL
name can be present in the parasite list. This causes a crash when
trying to remove it, because `gimp_parasite_list_find` does not accept NULL
keys. This commit adds a check for NULL names in `gimp_parasite_list_remove`.
This one was happening very rarely, which made it hard to track, though
I think it would happen more frequently to people with a lot of fonts
(and therefore font loading would take a lot of time) since the
problematic situation occured when the thread callback
gimp_font_factory_load_async_callback() would run after the
corresponding tagged container was created in constructor
gimp_data_factory_view_constructor().
When this happened, the source and filtered containers were not
synchronized regarding their freeze count. And in particular, the
filtered container would have one less freeze and would try to thaw once
the thread callback ran and thaw the source container, which was
provoking the CRITICAL.
As said in previous commit, this controller was removed as commit
76ddf4421c. Unfortunately we can't easily remove the full
(GimpControllerInfo) record, unless we were to redo or enhance the
migration code, because current code works line by line.
Nevertheless this change is enough to render the GimpControllerInfo
object invalid in a way where we can detect and clean it out (cf.
previous commit).
- Merging down a pass-through group onto a layer below does not make any
sense, considering how the below layer is the input to the
pass-through.
- Adding ability to blink problematic items when merge down fails. This
will help people to figure out what is the problem.
Rasterizable objects are all created from some side data and can be
renamed automatically based on this data (from the link file for link
layers; from the path for vector layers; from the text for text layers).
So let's share code.
Per Reju, NDE filters are not factored into the selection
created when turning off the Quick Mask.
This patch adds a call to gimp_drawable_merge_filters ()
on exit so that all active filters are merged down before
the selection is made.
Share the whole rasterize logic of the text, link and vector layer into
an interface. I didn't write it as an abstract parent class, because we
might have more rasterizable items in the future, which may not be
layers (e.g. there were discussions of vector masks).
New libgimpwidgets icon macros: GIMP_ICON_LAYER_LINK_LAYER and
GIMP_ICON_LAYER_VECTOR_LAYER. Note that the actual icons still need to
be done so I use temporary actual icon designs for now.
Also adding some TODOs for these.
Fix run warning:
> WARNING: icon theme has no icon 'gimp-vector-layer'.
While "gimp-vectors-list" migration to newer name "gimp-path-list" was
correctly happening from GIMP 3.0 to 3.2, there is a different code path
from 2.x to 3.2 (because the scale factor update can only happen in this
latter codepath). So this part of the migration needs to be duplicated
in both update functions.
While the migration code did exist from 3.0 shortcutsrc, we need to
duplicate this for the menurc migration, in case someone were to migrate
from 2.10, 2.8 or older (i.e. installing 3.2 after GIMP 2 without having
ever installed 3.0 in-between).
The following actions are removed: layers-link-discard,
layers-text-discard and layers-vector-discard. The new action
"layers-rasterize" introduced previously will handle all of these.
Since layers-text-discard is the only one which existed until GIMP 3.0,
we are migrating any custom shortcut which may have been set to
layers-rasterize (both from 3.0 shortcutsrc or older menurc).
Action layers-link-monitor is also removed (in favor of layers-retrieve)
but no migration code is added, since this didn't exist in 3.0.
These 2 new actions are meant to be usable on all 3 types of non-raster
(and non-group) layers, i.e. link, text and vector layers, to
respectively rasterize and un-rasterize them.
This will also work with multiple selected layers, and is not specific
to one type of layers.
I also change how gimp_text_layer_discard() used to work, by marking the
text layer as modified instead of actually discarding all text
information. The main consequence of this was that a layer rasterized
this way was forever lost. Now it can actually be revived as a text
layer, not only through the new layers-retrieve action, but also by
trying to edit it with the Text tool, which will trigger the same dialog
as when a text layer had been rasterized by editing it with a paint
tool.
Whereas the label of "layers-rasterize" seem to be quite straightforward
(simply "Rasterize" per discussions in gimp-ux#252), I am really unsure
of the label for "layers-retrieve". Further UX discussions should help
on this front.
… pass-through group layer.
Because of the strength-reduce pass-through to normal mode, we had case
when the effective layer mode of a pass-through group ended up to
Normal, which may shrink the effective bounding box.
Note that getting rid of the GimpGroupLayer's get_effective_mode()
(gimp_group_layer_get_effective_mode()) implementation was also fixing
this issue. I did hesitate a lot because it is also simplifying the code
a lot. But I was also wary about getting rid of the optimization
previously made by Ell (see commit fa9a023c270; note that I haven't
actually tested how efficient this optimization is).
This seems like a good compromise.
… impossible to use them like adjustment layers without additional step.
Even without the "adjustment layer" look-alike use case, this is wrong,
because an effect on an adjustment layer will be only applied on the
area contained in child layers, whereas by definition, a pass-through
layer would use the below render as input, and therefore its output
could be bigger than its child layers box.
I could find commit aa9ae1c65c as a culprit commit, and reverting it
would in fact also fix this issue, though by doing this, we'd regress on
the issue #4634 (I tested with one of the contributed XCF and can indeed
reproduce the bug).
Instead I return the unioned bounding box of the node, and of the
computed one. I do not feel like it's optimal, but this feels like a
complicated issue. It looks to me like there might be another deeper
issue in how both these bounding boxes are computed (not optimally!).
In any case, it also makes empty pass-through groups now usable to apply
directly an effect on the whole below render, as a side effect.
As discussed with NikcDC, this will be useful, for instance for the SVG
export to know the mime type of the linked file. If not PNG, JPG or SVG,
we may want to output a small warning that some viewers may not be able
to read such files, since the SVG spec makes the support of these 3
formats only as mandatory.
While there are cases when you want to edit the mask straight away (this is
often the case when starting with a white or black mask), in many other cases,
the mask may be already as you want it per its initialization (e.g. when
initializing with a channel, selection, the alpha channel, etc.).
Until now, the Add Mask dialog was always switching to the "Edit Layer Mask"
mode by default, which forced an additional unneeded click each time you created
a mask (and were in a case where you initialize the mask as you want it
directly).
Now adding "Edit mask immediately" feature in the "Add Layer Mask dialog":
* It's checked by default to keep historical behavior.
* As most other dialogs, the last value is remembered, allowing people with
repetitive workflow not to have to repeatedly set the settings each and every
time.
* This default is also visible and settable in Preferences > Interface > Dialog
Defaults.
This really feels like internal API which we'd want to keep private (and
used by core plug-ins only).
Also as Jacob noticed, it's not even included in libgimpbase/gimpbase.h
so plug-ins wishing to use this API need to include this file
specifically anyway (but the header is still installed and the API is
introspected).
Since we cannot remove these functions now that GIMP 3 was published,
for API stability, I am only deprecating them both in the C API with
macros and in the bindings with GObject Introspection annotations.
Therefore any third-party plug-in developer trying to use these
functions in a plug-in will get build-time or run-time warnings.
Then when we'll move on to GIMP 4 development, we can remove the
deprecation and simply make this file private-only use instead.
Converts the babl formats for Adobe Color Book
Lab and CMYK formats to "float", to prevent a crash
when accessing u8 Lab colors that have negative values
and CMYK colors that are too dark.
… the whole canvas while keeping aspect ratio of the source image.
The previous dimensions were not entirely "out of the blue" since they
were taken from the file, but very often dimensions from vector images
are kinda bogus (apart from aspect ratio, they don't mean much) anyway.
Now we will just fill the canvas box by default.
When changing the source file of an existing link layer though (through
Link Layer properties), the dimensions will be within the current layer
bounding box.
Also I realized that we need to also store the link width/height in the
XCF because the buffer width/height may not be right (in case a
transform matrix was applied). This commit therefore breaks XCF file
with link layers made in the last 2 days. Since we have not made even a
dev release, it's probably fine to do this and not bump the XCF version.
