Same patch as cb552d3d, just applied to GimpPrefsBox.
This was visible in the Preferences Dialog, where the same
unnecessary pop-up appeared in the side panel.
This was happening on Wayland in my tests, and apparently on Windows
too, according to the report. I widely simplified the code. Now we don't
list of axis anymore, and therefore we don't allow to change these
(which was not working anyway, for as long as I remember, at least on
Linux, both X11 and Wayland).
As for the pressure curve, we just show it unconditionally for any
device of type "Pen". It may mean that it might show on some rare stylus
devices with no pressure support, but in such case, it will just be a
bogus curve (it won't break the device).
And then we'll avoid all the flimsy heuristic trying to guess if a
device is supposed to have pressure sensitivity, which especially became
bad in Wayland as we have this information only on proximity. It means
that if you don't approach the stylus and were trying to set up your
pen's pressure curve with a mouse, no curve would appear!
Add to this that gdk_device_list_axes() seems very broken on Wayland and
was always returning GDK_NONE for all axis (even when only using it on
various device signal handlers, per advices by Carlos on IRC), at least
anyhow I tried to make it work, our heuristic to detect when an axis
should be ignored was completely broken on Wayland as well.
A simpler logic should work better and makes the code simpler to read
too.
It's also one less usage of GtkListStore, which is good for future GTK
versions where it got deprecated!
Since the Text Editor window uses the same
GimpTextStyleEditor widget as the on-canvas editor,
it also shows the Move handle (which doesn't work
in the Text Editor window). This patch simply hides it
so it doesn't confuse users.
This patch adds a CSS class name to
GimpPivotSelector so we can define its
CSS style in the GUI.
It also defines the margin-right CSS property
to prevent it be affected by the general
GimpOverlayDialog style.
Resolves#13014
In GimpHistogramEditor, pixels and counts are stored
as doubles. We previously converted them into 32bit integers
when displaying the values to the user.
As it is possible for the dimensions of an image to exceed the
limit of a 32bit integer, this could lead to overflow and negative
pixel counts.
This patch switches our display code to use 64bit gsize casts
for conversion to prevent this from happening.
If a filter is inactive/invisible, it does not
affect the appearance of the drawable.
Therefore, when merging all active filters,
those filters should not be removed.
This patch adds conditional checks for
gimp_filter_get_active () and does not
remove filters on merge if it returns
FALSE. It also adds sensitivity checks in
the GUI so that the merge down button is
not active if there are no visible filters.
In particular, for indexed images, color choice will happen within the
colormap.
The following uses are made context-aware:
* Test tool options color;
* Fill colors.
These other uses will not be context-aware:
* Padding, quick-mask and padding colors;
* Out-of-gamut colors;
* Generically generated color buttons (e.g. in filter dialogs);
* Foreground selection's mask color;
* Grid colors.
This was introduced in commit d4733e5b21. This was triggering a focus
grab each time we changed the color from within the FG/BG dialog, which
in particular had the focus being lost from said dialog. This is not
really good usability wise (and as a side issue, with some themes, the
focus change was apparently a bit bothering visually).
We use a GimpCellRenderToggle for the Fx icon
in the layer and channel docks. If you hover over it
when there's no filter, a square "checkbox" will appear
and give the impression you can click on it, even though
you currently can not.
This patch connects the "visible" property of the toggle to
the number of filters attached to the drawable, similar to
what we did for "active". This prevents the checkbox from
appearing, and will hopefully reduce user confusion.
...for dark mode.
The Navigation and Selection Editor
docks use GIMP_ICON_TEXTURE as their
default background when there's no
active image. On dark mode, this creates
large bright areas in the UI.
This patch removes the calls to
gimp_view_renderer_set_background ()
for these docks so the theme background
is used instead.
GimpLayerTreeView's delete button always deletes
the selected layer(s), even if a mask is selected.
This patch adds a new action button for deleting masks
(using the "layers-mask-delete" action) and conditionally
shows/hides it and the existing delete button based on
whether the mask or the layer is selected.
Note that after 3.2, we may replace this commit with a
single new action that conditionally deletes either the
mask or layer, depending on the selected item.
… input devices.
Per Carlos' advice on gtk#7534, I wait for us to get a focus, since the
pad devices are only created at that point.
Note that this is a Wayland-only issue, but since it doesn't matter too
much that input devices are not initialized before we have a focused GUI
anyway, let's make this simpler.
At the earliest, the splash focus can announce a focus, but since it is
possible to start GIMP without the splash, display shells will also
possibly announce the first focus (there will always be a display shell
focusing at some point for any GUI GIMP!).
As seen in the Welcome Dialog, if you have multi-selection
in place for a ListBox and try to Ctrl-click another row,
the call to gtk_list_box_select_row () will deselect the
prior row unless you click on an area that's not covered
by GimpRow. This patch removes the forced selection,
with the assumption that the click will bubble through
as normal to GtkListBox.
...on non-raster layers.
Resolve#15368
Per Bruno, the "Merge Filters" button on the
NDE filter pop-up should have the same warning
message if it is disabled as the "Merge Filter"
checkbox does in the Filter Tool itself.
Since the button is visible when there's a group
layer, a warning is also displayed for that, though
due to string freeze it is not yet set to be
translatable.
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.
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
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").
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.
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.
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.
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.
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 is a followup of commit 0ff960c45b which was the right fix, except
that we must make sure that gimp_widget_free_native_handle() is called
**before** chaining up with the widget's parent dispose().
Failing to do so, the first parent's dispose() was destroying the
associated GdkWindow, which made it impossible to call
gdk_wayland_window_unexport_handle() on it. And therefore we were still
getting handle callbacks possibly run after the window was destroyed, if
we were very fast enough to destroy a window immediately when it is
being shown.
I was still experiencing a crash when closing the Export file dialog
very fast with Esc while it was reappearing after canceling a plug-in's
export dialog.
This followup commit reorders the one case where we still had the crash
because of this order issue, and adds some docs comment to tell
developers how to use the freeing function.
This patch enables multiple selections in
the GimpDocumentView widget and dockable.
It also updates the "documents-open" and
"documents-remove" actions to check if the
GimpContainerView has more than
one selection, and if so, tries to load/remove
all of those images. The action wording is
slightly edited to indicate multiple
images can now be opened/removed.
We could have tweaked further the code to guess what is a meta file
procedure or not (what we have done until now) but I decided to be more
explicit and added gimp_file_procedure_[gs]et_meta() functions to
libgimp to tag a specific import/export procedure to implement a meta
format.
gimp_file_procedure_set_extensions() would still be used to list well
known formats using this meta format, for instance "hgt.zip" or
"xcf.xz,xcfxz" but the meta extension (simply "zip" or "xz"
respectively) would be used as such. No more "guessing" using the list
of extensions and assuming that at least one of them would have a dot
within.
Resolves#9324
In GTK3, a default "Search" is enabled by default in GtkTreeView.
While in most places we override this with our own search feature,
it was not explicitly set for the GtkTreeView in the GimpComponentEditor
in the Channel dockable. So, it defaulted to TRUE and created an
unnecessary pop-up whenever you typed after clicking a channel.
This patch calls gtk_tree_view_set_enable_search () and turns off
this default feature.
… controllerrc config file deserialization.
This is the first part to handle #13787 and not a bad idea by itself
per-se, since we remove one way to crash GIMP by creating an invalid
controllerrc file.
