I had added an assert in commit 98ebe96c1f specifically to catch other
cases where we may have run gimp_ui_manager_update() with inconsistent
user context, and I failed to catch the obvious CRITICAL (the damn Error
Console was catching it!).
Anyway we had this other obvious case when creating new displays in
gui_display_create() which would trigger the ui update with still
inconsistent context.
Now I'm in fact wondering why GimpContext is simply not returning the
active GimpDisplay's image and connecting to the "image" property of set
display so that it's always synchronized. But since we are so close to
GIMP 3, and I don't want to do too important restructuration of code
(why did we do this complicated update in 2 parts? Maybe there was a
good reason…) at this point, I'll just do the simple skip for now and
look more closely at GimpContext implementation after the release.
As Cheesequake noted in !1673, there may be cases where one would want
to run gimp_help_connect() while also setting a tooltip. So they also
run gimp_help_set_help_data(), even though the latter is implied by the
former. Worse, it makes the order matter too much because if you call
gimp_help_connect() after gimp_help_set_help_data(), the tooltip would
be removed.
Now the reason is that gimp_help_connect() was clearly made to be run on
windows whereas gimp_help_set_help_data() was for other widgets, which
usually don't need to react to F1. Yet the previous commit does add
F1-connect for the lock buttons, which kind of makes sense. So why not
just add this tooltip argument.
As a side fix, I am removing a bunch of gimp_help_connect() on each
button in the layers effect popover. Just run it once on the top
container.
Copying filters over from one image to a partial copy was broken on
multiple level by doing it on an additional loop, and assuming that the
originally selected layers and the newly created ones had the same
structure:
1. First the actually copied layers may be more numerous. For instance,
we'd also copy parent layers. Typically copying a layer under a layer
group, both the layer and its parent layer group would be in the clip
image.
2. Second, because this structure may change, the assumptions made so
that filters were not copied to the right image.
3. And as a last consequence, sometimes we could have crashes, assuming
the same structure and therefore directly dereferencing a NULL
pointer. I had such a crash when copy-pasting a layer group, while
also selecting its children layers (though this crash also got hidden
by my previous commit, but just by chance).
Instead just copy filters in the same time as layers are copied, so that
we can easily associate the filter from the correct original layer we
copied from.
layers-select-next/layers-select-previous don't work well as up/down
arrow behavior because they only work within each selected layer's
level. But historically (and that's what makes the most sense IMO, and
is the most expected behavior), up/down arrows would walk through the
layer list visually. I.e. that it would select next whatever is the next
layer displayed in the Layers dockable, even if it means selecting
children or going down one layer group level.
The 2 new actions "layers-select-flattened-previous" and
"layers-select-flattened-next" do this. Say you have this tree:
Layer 1
Layer 2
| - Layer 3
| - Layer 4
Layer 5
With the "flattened" actions, after Layer 2, there is Layer 3, and after
Layer 4, there is Layer 5… unless… Layer 2 (layer group) is collapsed.
In which case, after Layer 2 is Layer 5. This selection movement indeed
takes into account the state of the layer group expanders.
This makes the Up/Down arrows work similarly to how they used to work
with default GtkTreeView implementation, except that the logic now also
works well with multiple selected items.
This reverts commit 31df873d4c.
My commit was not wrong per-se (it didn't add any bug), but it was in
fact not useful either, and only adding a useless list copy for no good
reason.
I thought that action_select_object() was actually selecting objects,
but looking at implementation, it in fact doesn't. It only returns a
pointer to the object to select.
Somehow it works fine on my machine, but this is very likely the
culprit. gimp_image_get_selected_layers() returning directly the pointer
to selected layers, we should always make a copy before doing anything
which would change this selection!
This fixes 2 issues:
1. Since gimp_edit_cut() uses gimp_edit_copy(), it had the same error
message when no selected drawables were within the selection.
2. When there was a previously existing clipboard image, gimp_edit_cut()
could return it as though the cut succeded, even when it did not.
Though these are not as user-facing as other strings, the action names
still are somewhat user-facing. Let's rename them consistently with the
GUI and the API.
This commit also handles user config migration so that custom shortcuts
are not lost.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes#10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
...to path.
Changes the names of
gimp_vectors_* () API to
gimp_path[s]_* (). Renames related files
to [path] instead of [vectors], along with
relevant enums and functions.
This commit renames the GimpVectors
object to GimpPath in both app/core and
in libgimp. It also renames the files
to gimppath.[ch] and updates the relevant
build and translation files.
There are still outstanding gimp_vectors_* ()
functions on the app side that need to be renamed
in a subsequent commit.
...to paths.
Similar to d0bdbdfd, but covering the
app/core versions of the API instead of
libgimp. Changes the names of
gimp_image_*_vectors () API to
gimp_image_*_path[s] ().
Also renames some related functions such
as gimp_image_pick_path (). The next step
will be to rename the gimp_vectors_* () to
gimp_path_* ().
commands that work on multiple layers:
Raise Layer -> Raise Layers
Layer to Top -> Layers to Top
Lower Layer -> Lower Layers
Layer to Bottom -> Layers to Bottom
Also update the hint strings.
In the main menu and layers dialog context menu it is called
`Text to Path`, let's use that same name in the text tool actions
instead of `Path from Text`.
Not all layer mask menu commands and help texts were updated to reflect
that they work on multiple masks.
Updates
- Apply Layer Mask -> Apply Layer Masks
- Delete Layer Mask -> Delete Layer Masks
- Their text hints and the one for Disable Layer Masks
Updates the undo strings, even though these don't seem to be used
anymore? Looks like undo always picks the menu command now.
I'm moving the logic of choosing a correct default for width/height by adding an
"extract dimensions" callback in the procedure. The logic is that every vector
format out there should likely have metadata either for pixel dimensions or
physical dimensions, or at the very least for no-unit dimensions (ratio only).
Vector load procedures will have to implement only the extraction of such data
in a callback called by GIMP but not how to act upon them, so that we have a
common logic for all vector images.
I am implementing this callback first in the SVG plug-in, moving all the code
to extract dimensions (and improving it) in this callback.
Also I am deleting "file-svg-load-thumb" procedure. I could simply reimplement
it using the same code, but it looks to me like this is very useless for vector
formats to have a specific thumbnail procedure (unless it were to use very
specific metadata for faster result). This is vector data, just ask it directly
at the proper bounding box size.
*In file-pnm, format_name is no longer
used due to changes in exporting
functions. This was creating a warning
about an unused variable.
*In 519f301c, an attempt to add a
short-key for MacOS Settings was left in.
It did not work because "comma" should
be spelled out rather than using ",". This
patch removes the accelerator.
For now, we can't keep certain GEGL ops
like Gradient as NDE filters, since they are
connected to tools. If the layer is copied
or saved as an .XCF while the tool is still
active, it attempts to save it and causes a
crash.
This patch adds a check to make sure the
copied filter has been commited and that
it's not a tool-based NDE filter before
being copied. It also adds some NULL
checks where gimp_drawable_filter_duplicate
is used to prevent NULL from being
added to the filter stack.
Resolves#10914
Some dockables such as "gimp-pattern-editor" and
"gimp-mybrush-editor" are listed as Editors even though
we don't yet have dedicated GimpDataEditors for them.
This causes problems when using certain features like
duplicating. To resolve for now, we check if
gimp_window_strategy_show_dockable_dialog () returns a
valid GimpDataEditor before trying to use it.
Per Jehan, we also verify that an edit button exists
and is visible before we try to call the edit command.
Per Pippin, the only color model that can
have double precision is RGB/A.
Therefore, we need to switch all others to
use float instead. This patch converts the
HSV and HSVA double babl formats.
Previously, filters were lost when copying
individual layers. This patch copies them
to the clipboard image on cut or copy,
then copies them back to the pasted
image.
It also fixes an issue where filters would
be merged down if a selection was
copied instead of the entire layer.
Resolves#11250
In 2.10, we explicitly hid "dockable-preview-size-menu", the submenu
for Preview Size, if there were no previews to set sizes for in the
dockable dialogue. In 2.99, this code was removed as part of the
GAction port and code clean-up.
As a result, the Preview Size submenu is always visible even if the
options have no effect on the display. To restore the 2.10 behavior,
we set each Preview Size option's visibility. If all options are hidden,
the submenu does not appear.
...to accept GeglColor paramaters instead
of GimpRGB. This function is used to draw
the layer/channel color tags.
Note that a temporary GimpRGB was left
to use with gimp_rgb_composite ().
It will be replaced once that function is
also converted to use GeglColor.
Resolves#10848.
In cc62f2b0, we moved the filter property loading code
earlier in the process. However, the opacity, mode, and
region options for GimpFilterTool were not included in
this move, so they reset back to defaults each time.
This fixes that problem so settings are retained when
editing.
We historically have both the colormap and palette concept in core GIMP,
though they are actually kinda the same concept, except that with
"colormap" we work with an array of raw data and it's a lot less
color-aware. It is still much more efficient in some specific cases,
such as when converting the image (we can then convert the whole palette
as a single buffer, because the image palette is space-restricted
anyway), when storing undo data or when storing/loading in XCF.
But for all the rest, let's use gimp_image_get_colormap_palette() and
work with the GimpPalette API.
I still see some limitations in GimpGradient, and in particular, they are still
always stored as RGB in GGR files. It would be nice if we could store the actual
color format. This way, if someone chooses a gradient stop as Lab or CMYK color,
that's what the gradient file would keep track of. But also even storing the
space of a color (instead of storing/loading always in sRGB, even though this
may still work fine as we store unbounded double values). This might warrant for
a v2 of GGR file format.
This commit also fixes loading of SVG gradient which was apparently broken
regarding hexadecimal color parsing.
Finally I improve gegl_color_set_alpha() by adding an alpha channel when the
initial format had none.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
Jehan