... 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).
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 issue was raised by Anders in #15152 and it was a mean one, because
it really looked like file-ani-export was crashing inside
_gimp_procedure_config_end_export() (so after its main run function),
but somehow only when being called from another plug-in (in particular
here, from the file-compressor plug-in). So it looked like a bug
somewhere in libgimp.
It turned out to be a "simple" memory corruption which was not
immediately showing its consequences.
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.
Resolves#13598
Applies the same logic designed by Jehan
in f78a0629 to the gimp_drawable_get_sub_thumbnail
function.
This allows GimpZoomPreview and
GimpDrawablePreview in older
plug-ins to show correct previews for
images that are larger than 8-bit.
This bug had several causes:
* gimp_drawable_get_thumbnail_data() is pretty crappy as it just returns
dimensions and bpp. You get no real format information.
* When using it to create a GdkPixbuf, which seems like the most common
usage, only sRGB (with or without alpha) in 8-bit is supported by
GdkPixbuf.
So I'm just making sure that private _gimp_drawable_thumbnail() PDB proc
is only returning 8-bit sRGB(A) data. For thumbnailing, this is probably
fine anyway.
Fixes when calling gimp_drawable_get_thumbnail() on an item from a
high-bit depth image:
> LibGimp-CRITICAL **: 20:12:21.028: file ../../../../../../../dev/src/gimp/libgimp/gimppixbuf.c: line 112 (_gimp_pixbuf_from_data): should not be reached
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.
This string is a bit tricky to find.
Go to "Menu > Filters > Web > Image Map."
This filter opens a dialog with a menu.
Go to "Menu > Tools > Use GIMP Guides..."
You can see that the command entry in the filter's menu is
"Use GIMP Guides," but it changes to
"Use Gimp Guides" in the dialog box title.
This patch fixes it.
gimp_image_set_simulation_intent() attachs a "image-simulation-intent"
parasite which means that it first detaches and frees the one which was
deserialized from the XCF. When calling gimp_parasite_get_name() on this
later on, we were working on a dangling pointer. It means that the fact
we didn't have crashes most of the time was the unexpected part, not the
crash itself!
Same for gimp_image_set_simulation_bpc() and "image-simulation-bpc"
parasite.
The fix is to swap the order of statements to first detach the parasite.
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.
I'm looking at #14014. It's probably not the problem either, especially
as gimp_parasite_new() would return a NULL parasite anyway with an empty
name.
But better be thorough and output a sensible error as soon as possible
when loading a XCF.
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.
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.
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.
Fixes https://gitlab.gnome.org/Teams/Translation/dz/-/issues/3
The plural form for po-python/dz.po causes a segfault when trying
to run the Python console, so change it to the plural form used
in the other Dzongkha files in GIMP.
This URLs are useful when users want to see more information about
release notes. They are visible on software stores like GNOME Software
and software websites like Flathub.
… and reset their undo stack.
This is a followup to #14463 as I realized that images opened directly
by a load procedure may still be dirty, first if the plug-in developers
didn't think of cleaning themselves the image at the end, but even as we
add some metadata which adds an undo step too. So even if the plug-in
developer made a perfect job, the image would still end up dirty if it
has metadata!
Let's just make so that GimpLoadProcedure clean the image explicitly.
Note that other types of plug-ins creating images won't have such code
as we cannot anticipate every case. In fact, in some use case, maybe
someone may want a plug-in to return a dirty image with undo steps! At
least for load procedures, we can consider these pretty standardized,
knowing we want them clean upon loading.
See commit 822c26f709. We decided to solve #14463 by having
gimp_file_load() always force-clean the image and reset the undo stack.
Therefore fix the docs again.
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).
… 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.
… deserialize with a wrong or unknown type.
The error message in issue #13787 was about trying to deserialize a
GimpControllerMouse object as GimpControllerInfo's controller. Yet
GimpControllerMouse was removed with commit 76ddf4421c so this was
failing.
With this change, such error would be more explicit, with an error
saying:
> Unknown object type: GimpControllerMouse
… instead of:
> unexpected character ')', expecting string constant
(which was very confusing to the actual issue)
