- Though GimpDrawableChooser itself is deprecated, make it call the
new items popup API, which will work just as well.
- gimp_procedure_dialog_get_widget() will now return a GimpItemChooser
widget by default. I did hesitate if for API behavior stability, it
should not still return a GimpDrawableChooser, but considered that if
someone set G_TYPE_NONE, they want our "best choice" and are not
considering tweaking it. If someone wants to make sure this function
always returns a specific widget type, they should specify said type.
So I also added a note in the function docs related to this
assumption.
- Van Gogh plug-in must now use the GimpItemChooser API to set the item
to show. Also I am specifying the widget type, even though it is now
the new default, because of the previous point. Since we tweak further
the widget with its API, let's specify so that any further defaults
update doesn't break this code.
- Adding some pragma to ignore warnings on the few pieces of code where
we have to call deprecated functions (because inside other deprecated
functions themselves).
- gui_pdb_dialog_*() API should just always create GimpItemSelect
dialogs now. Also I ref rather than peek the class, because even if
the class has not been instanciated yet (a case I ran into), we still
want to obtain the class structure.
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.
This patch swaps out the GtkBox in
gimp_enum_icon_box_new_with_toggle ()
with a GtkButtonBox and sets it to EXPAND
so that the buttons are pressed together.
It also adds some CSS style to complete
the effect.
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.
The previous commit was not taking into account usages of
gimp_cairo_surface_create_buffer(), other than the text layer rendering
usage, as it was focused on fixing #14970.
In particular, in other pieces of code, we were using a temporary
GeglBuffer as a way to edit the original Cairo surface but the syncing
back was not happening anymore. So previous commit was breaking all
thumbnails of layers or images, as well as PDF export for all raster
layers.
After some thought, I decided to implement a new function
gimp_cairo_surface_get_buffer() which would do what
gimp_cairo_surface_create_buffer() was doing, but adding a boolean flag
to declare whether or not we were expecting to sync back into the Cairo
surface's data. After all, when we don't need to sync back, better avoid
the useless work of copying possibly huge data.
I also added back the possibility of returning a linear-memory backed
buffer, after some discussion with pippin. Because for very small
surfaces, and if we are indeed looking to sync back into the source
Cairo surface, the advantages of using a linear buffer may still be
worth it, even though it's not true for the general case (where tiled
buffers will be much more efficient). I used 4096 (64^2 because our
current tile dimensions are 64 right now in GIMP), though this number is
kinda random and doesn't matter too much (it doesn't have to be the
square of the tile's width or height). I don't put any info about this
in the new function's documentation because developers should not have
any expectations on the type of buffer they get (only whether or not it
will sync back to the source).
As a consequence of all this, gimp_cairo_surface_create_buffer() has
been deprecated as of GIMP 3.2, though it will still work the same. The
new function will be recommended as a replacement.
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
Instead of deleting all selected paths except
for those attached to vector layers, we
stop the action and notify the user that
they can not delete paths attached to
vector layers.
In gimp_item_tree_view_blink_item (), we
originally used "3" because that is the
item column in the layer and channel
dockables. However, the path dockable
item column is at "2" since it lacks a
filter column.
To make this more general, Jehan
suggested we create a
gimp_container_tree_view_get_main_column_position ()
function in GimpContainerTreeView that
finds and returns the column index of
the main item. Then, we use that function
in gimp_item_tree_view_blink_item ().
Signature for "match-selected" signal on GtkEntryCompletion was wrong,
and code didn't handle the case of multiple resouces sharing the same
name. (e.g. 2 different fonts both named "Holiday").
Resolves#4275
Text layers should have transparency when they are
not rasterized. It is possible to remove the alpha channel
when a text layer is rasterized, which causes a CRITICAL
when gimp_text_layer_render () runs to re-render the
vector-based text layer when the rasterization is reverted.
This patch adds a check in the set_rasterized () function to
verify the text layer still has an alpha channel when it's being
converted back to a vector-based layer. If the alpha channel
was removed, it is restored before re-rendering.
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
This reverts commit 2ba6725761.
This too is wrong. First it mentions "visible-vertical" and
"visible-horizontal" properties of GtkAction, but this is not it! Two
similarly named properties are also on GtkToolItem and these are not
deprecated! Looking at the code, tool_button is a GimpToolButton, whose
parenting indeed goes up to GtkToolItem (and that's obviously not an
action anyway).
Secondly, it creates other bugs, in particular I now sometimes have a
completely empty toolbox. That's clearly wrong.
Reverting for now. Issue #9813 will have to be fixed differently.
This reverts commit ee421da346.
This is wrong. This case should not happen, or if it does, this is very
likely not the proper fix. In fact, it was trying to fix a bug created
in commit 2ba6725761 which is also wrong (and which I'm going to revert
next).
See also my comment in Gitlab:
ee421da346 (note_2596612)
"visible-vertical" and "visible-horizontal" attributes
of GtkActions were deprecated in GTK 3.10, and since
the GAction port, we don't set them anyway on actions.
This seems to have impacted the ability to toggle a toolbutton's
visibility when a toolitem's "show" property is changed.
This patch replaced the deprecated "visibile-vertical" and
"visible-vertical" properties with a single "visible" property,
which consistently updates when the eye icon is toggled in
GimpToolEditor.
Resolves#9285
In images_delete_image_cmd_callback (), we dereference
images which we want to delete. This works for images created
via the GUI. However, images created via PDB scripts are not
automatically connected to the display if created with no layers.
If you try to delete them, they will be dereferenced but will still
in the ImageView dockable. This can cause a crash if you try to
access the container again, since it will point to an unreferenced
variable.
This patch removes the image from the container first before
dereferencing it, to prevent the crash.
When the user chooses "Raise or Open Image" in the
Document History, we first try to raise an image in
documents_raise_display (). This calls gimp_display_get_image ()
to get the active image from the current display, and raise it
if it already exists.
However, if you call this when the canvas is empty, it will throw a
CRITICAL since the "image" parameter for gimp_image_get_file ()
and gimp_image_get_imported_file () calls will be NULL.
This patch adds a check if the image received from
gimp_display_get_image () is NULL, and if so, we stop the function
before trying to raise it.
The intention was that you could drag colors from
the color history to the canvas, similar to the
Foreground/Background editor colors.
However, because the GimpColorArea widgets are added
to a button, the button intercepts the DnD signal mask.
This patch adds a call to gimp_dnd_color_source_add ()
when the buttons are created, to pass the ColorArea color
onward.
This patch allows the header icon and view
in GimpViewableDialogs (and children of
this dialogue class) to scale based on user
custom icon size.
Note that it only scales when a new dialogue
is opened; it is not set to update if a dialogue
is already open and the slider is changed.
This could be added later if desired.
Resolves#15215
The GtkButtonBox that holds the overlay buttons
in GimpOverlayDialog were set to GTK_BUTTONBOX_END,
which caused them to go offscreen on one side on the smaller
overlays like Scale and Sheer.
This patch changes the layout style to GTK_BUTTONBOX_CENTER
to ensure the buttons are centered within the overlay.
Our Weekly CLang build for Debian failed with:
> ../app/widgets/gimpfiledialog.c:924:37: error: label at end of compound statement: expected statement
> default:
That is not a problem locally (with GCC), but I guess we can just add a
g_return_if_reached() in here as this code path is not supposed to ever
be reached indeed.
As per IEEE Std 1003.1-2017, Section 8.3, TERM and
SHELL vars says we are running GIMP on POSIX shell.
They are not set by either the deprecated Windows CMD
nor by Windows PowerShell since they are not POSIX.
POSIX shells are supported by us on Linux and macOS but
actually not on Windows, since they are non-native: they
rely on forking to Cygwin which have terrible performance
(##11385) and do other tricks to make deps believe they
are on Unix which breaks e.g. GObject Introspection (#11424).
Anyway, it is Unix emulation at its prime, tricky by nature.
Even so, does not hurt allow the output on these
unsupported shells on Windows so not disrupt workflows
of adventurous developers but they will be warned that
problems (like the ones above) can and indeed appear.
This patch ensures that the text style editor is destroyed whenever a text layer
is selected, even switching between them clicking on different textboxes.
This is necessary to ensure that the on-canvas editor is positioned
correctly according to the coordinates of the selected text layer.
This commit prevents the on-canvas text editor from being dragged outside
the image bounds by checking the overlay's position and adjusting the
coordinates to keep it within the canvas. Additionally, it checks whether
the overlay is entirely outside the canvas and, if so, pushes it back inside.
This commit adds a button inside the on-canvas text editor
that restores the editor to its original position after it has
been moved. The button is only visible when the editor has been
moved, and disappears when it returns to its default position.
... to reset its position via right-click menu
This commit adds the ability to restore the original position of the
on-canvas text editor after it has been moved, by accessing the option
from the context menu opened with a right-click on the text box.
Once the on-canvas text editor has been moved, its position should be
preserved across editing sessions. This commit stores the editor's
position per text layer and restores it when the layer is activated again.
After the on-canvas text editor has been moved, it should remain fixed
on the screen when zooming or panning the canvas. This commit preserves
the current behavior when the editor is in its original position, and
fixes its position on-screen after it has been moved.
This implies both when canceling or committing a filter.
Part of the fix is that we don't store filter tools as part of the tool
history, which means that when we swap back to the previous tool, the
filter tool info is dropped as though we never went through it. This
way, filter tools don't actually look as other tools (even though they
technically still are, since this is how we can implement canvas
interaction for some of the filters).
