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.
This is the result of a UX session with Aryeom. Just showing a message
forbidding editing of non-rasterized text/link/vector layers is
problematic, because it doesn't help people understand how to unblock
their situation (if they really want to just edit directly the layer).
Additionally we are now blinking the layer.
A possible alternative could have been to pop a dialog up, with the
same message but also with a quick-action button to allow rasterize in a
click (similar to how we are popping a dialog up to revert the
rasterization when clicking on a text layer with the text tool or a
vector layer with the path tool). The problem is that even though the
need to edit directly a non-raster layer arises from time to time, most
of the time, when you use such layers, you don't intend to edit these
(unlike editing text/path with matching tools, you more often wanted to
edit the relevant data).
Therefore it is more often than not just a mistake when you try to paint
directly on such a layer. I.e. that very often, you were intending to
paint on another layer, or add a new layer above your non-raster layer.
Therefore a dialog popping up every time you made such a mistake would
be annoying and workflow-breaking. A simple error message and some
blinking leave for a fluid process.
Our build files were relying 'sysroot' to find gexiv2.h but this is
not possible with Apple Clang om which sysroot points to macOS SDK.
So, exotic environments like Homebrew were failing. Let's fix this.
The rgba variable would be used uninitialized. This needs to be moved
one loop level up so that the color extracted at each cell start
position is properly reused (and also so that the full transparent color
at no-entry position is properly set and reused too).
This is the recommended fix from Gtk to use our own mime type rather than depend on a mimetype
that has a different expectation of payload.
This means drag and drop of colors uses `application/x-geglcolor` rather than `application/x-color` which expects an RGBA color rather than a structure.
This patch fixes a few (mostly Windows-specific) warnings on build.
* Hides functions like gimp_get_foreign_window () and variables
like transient_set that aren't used in Windows.
* Changes hollow_g_shell_quote () to not return a const gchar *,
since the value it returns is actually not const.
* Cast update_interval to double to remove warning about mixing
enums and doubles in division.
There is no bug report that I know of as it was reported directly by
Aryeom. When a dock had only a single dockbook, if we tried to move one
of the dockable to the above or below target areas, it would fail.
The reason is that we were not counting the dockables correctly so the
code thought we were trying to move from a dockbook containing a single
dockable (single tab).
The button for opening the edit panel for editing a brush / gradient /
pressure curves looks misaligned because it is added to the end of the
horizontal box and its icon is aligned to the end of the button instead
of its center.
This adds puts the text entry and the edit button into the same
horizontal box and fixes the image alignment.
Following the improvement in fe4cbb65, the Critical Dialogue
uses the native titlebar in Windows. This means it no longer
adapts to dark and light mode automatically.
Since we don't want GimpCriticalDialog to be dependent on
internal GIMP code, this patch copies over the fallback code
in gimp_window_set_title_bar_theme () (which sets the title bar
based on the background color) when the dialogue is realized.
Revert the logic of opening all files as link layers back into loading
their current content as normal layers.
Instead just add a new action dedicated to open images as link layers
and add it to the File menu.
Per UX discussions with Aryeom.
Instead of keeping a "modified" property in GimpLinkLayer, we just check
if the link is being monitored. It's also a better wording because we
may "discard the link information" without actually modifying the layer
pixels.
Also I now actually shut down the file monitoring process. This can be a
bit expensive so when we don't need it, let's really free the
GFileMonitor.
This commit also fixes scaling of link layer (which got broken along the
way) and improves the undo code.
Note: I'll probably want to modify the XCF flags, but let's do this in
the end, depending on further changes too.
These are layers who content depends on another source (right now only
an external image). This can be useful when for instance working at
several people on a single artwork, hence being able to load new
versions of an image without even touching anything in the XCF (for
instance, say you draw an animated character while someone else is
taking care of the background).
Similarly to what we do for text layers, once you start modifying the
contents, it turns into a "normal" layer. The link information is still
available though, so it is possible to revert to the monitoring state
with the menu item "Monitor Linked Image" which appear when a link layer
became a normal layer.
This is not finale as I'm still experimenting. In particular, I have not
implemented XCF saving/loading yet for this new layer type.
When creating a GimpFillEditor or GimpStrokeEditor with
edit-context == TRUE, a color button is created next to the
foreground/background option. However, the color of the
item associated with the button doesn't change until the
user confirms it in the corresponding dialogue. This prevents
"live-previewing" color changes on vector layers or text outlines.
This patch adds a call to gimp_color_button_set_update () when the
color buttons are created in GimpFillEditor (which GimpStrokeEditor
inherits from). This allows live-previewing on vector layer fill/stroke
and text outlines, as we currently support with text color from the
tool options.
STYLE_FG and STYLE_BG to enum GimpViewBorderType, where FG uses the
actual style FG, and BG is simply transparent. Default to STYLE_FG
instead of BLACK (which is BLACK's actual intention). Also, don't
leak all GeglColors of all view renderers.
rid of implicit knowledge about the surface's scale factor.
- render everything to renderer->surface
- pass the widget scale factor around explicitely when rendering
to the surface
- when drawing the surface to the widget, get the scale factor from
the surface itself.
While there is a style "background color", the idea of a "widget
background color" is completely bogus, the widget background can be a
gradient or whatever.
- Get rid of "background" in GimpViewable's preview API, only leave the
"foreground color" there for things like brushes or fonts.
- In GimpViewRenderer, add the background types to be used to class and
instance, so each renderer type can choose what it needs.
- Render all previews to alpha surfaces, and do the background
for all renderers generically in gimp_view_renderer_real_draw(),
then render the preview surface on top of it.
Extensions is used both for file extensions and for
GIMP's planned Extension format. This patch adds translation
context so translators know which one we're referring to.
