Setting a step/page size of less than one for a spin scale bound to an
integer property does not make sense. Similarly the number of decimal
digits shown can be set to 0.
Seems this was the last .sh script pending to ported. Since I was experiencing
problems with the .sh one (not working locally nor on HomeBrew), I just ported.
Now, it is easier to read and fix if needed.
I also fixed the build order on libgimp meson.build to ensure the patched
.typelib being always present at the time GIMP generate splash screen etc.
This commit enables GimpBrowser to emit the "stop-search" signal,
originally emitted only by the internal GtkSearchEntry.
It also connects this signal to all widgets embedding a GimpBrowser,
so they can intercept it and close themselves.
This restores the behaviour that existed before the GtkSearchEntry update
I am unsure about the previous commit (see MR !2568), though it should
not be hurtful either. At least though, let's not leave duplicate
comments. So merging the 2 comments and making the remaining text a bit
more technically correct.
GIMP hard depends on gegl and babl libraries.
We want to call their init functions early, in the GimpPlugin init.
We want to call gegl_init which calls babl_init.
But gegl_config cannot be called after gegl_init (gegl#427)
So only call babl_init in GimpPlugin init
and rely on _gimp_config to call gegl_config which seems to init gegl
(for wire msg GP_CONFIG, which comes early.)
Related: could eliminate calls to gegl_init in C plugins, now redundant.
The plugin class will do it.
Code taken from: https://gist.github.com/ugovaretto/5875385
We already do that on babl repo.
It does not exist on such platform. What MINGW do on
the pseudo-header is to implement a wrapper to
native Windows functions.
- The "Healing Brush" paper URL is dead. It now leads to one of these
horrible parasitic websites which reuse domain names. And we for sure
don't want to promote this! I'm using instead the associated page on
our developer website. I just created this page and right now it's on
testing only. But this will be the URL for the main website.
- The URL for the foreground extraction paper is still valid, but from
my small research today when writing various algorithm' pages, I think
our own implementation diverged from this original paper (though it
may still have part of this original paper's algorithm; only a deeper
check of the code would tell).
See: https://testing.developer.gimp.org/core/algorithm/foreground-extraction/
Also this PDB procedure is called generically gimp_drawable_foreground_extract()
and it even has an argument to choose the algorithm (even though right
now, there is only a single choice, which is "Matting" algorithm, and
even there you can't choose which one; it's always Matting Global;
Matting Levin cannot be chosen for instance).
So anyway it is not a good idea to point to one specific algorithm,
and even less to leave an external URL (which may also disappear some
day) in API docs. So I am just getting rid of this paper title and
URL, and replace it with actually useful information, which is how to
set the trimap to represent foreground, background and uncertain
pixels (note: I notice that it would have been different with Matting
Levin where uncertain pixels must apparently be set transparent).
- 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.
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.
When opening a tiff image with exif metadata including a thumbnail
saved in tiff format, the exif metadata of the opened image will include
tiff specific metadata like Exif.Image.StripOffsets.
These tags are not supposed to be exported to any other formats.
Although we removed these tags for the image itself, we forgot to
remove them for the thumbnail metadata if adding a thumbnail was
selected.
Since GIMP itself saves thumbnails in jpeg format, that caused some
tags to be left behind when the original software writing the tiff
wrote thumbnails in tiff format.
We fix this by always removing all thumbnail metadata first before
writing our own thumbnail metadata.
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.
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.
… 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.
Commit 6874c47544 was not correct as we generate some type/values
description, extensively using Pango markup.
This additional fix does not change the logic from the aforementionned
commit, which is that the blurb still is just plain text (nor markup),
which we properly escape to display as-is, mixed with Pango markup.
I did wonder if it was supposed to be markup, and after a bit of test, I
could confirm that adding random markup in some other arguments, it does
sometimes styles the text, and other times, it just display the tags.
So I'm leaving an API warning to review this for GIMP 4.
This also fixes WARNINGs when a tag-like text is added:
https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/2469#note_2574483
The 'Plugin Browser' and 'Procedure Browser' use the same logic for
enforcing the minimum size of the details page and the list views. And
both are doing it by first setting the minimum: size of GtkTreeView and
then they climb up the widget tree to do the same. This is not ideal.
Setting the minimum size of GtkTreeView is not necessary because it is
inside of GtkScrolledWindow which makes this request moot. It also does
not enforce the minimum height of the widget for that reason. And if
GimpBrowser ever changes, both browsers will need to update their logic.
Moving the size enforcing a level up is logical and more robust.
Using an explicit value of width for the height of the dialog window
makes little sense. This makes the size of the dialog window clear.
And now the height of the list widget is set with its own macro instead
of piggybacking on the dialog window height.
We need 2 lines in the PDB for it to be an empty line in the C file,
which in turn will be interpreted as markdown-like lists for the
gi-docgen generated HTML docs.
- Consistently add the text about inserting items into the image after
creation, with correct function links/references.
- Consistent grammar for function blurb.
- Make @name argument nullable for gimp_path_new().
This patch moves the enums for GimpTextOutline
and GimpTextOutlineDirection so that they are
accessible to plug-ins/scripts. This will allow
for us to add PDB functions to get/set text outline
properties.
When the Exif metadata comment after our adjusting was NULL, we got a
critical:
CRITICAL **: 14:09:21.853: gboolean gexiv2_metadata_set_exif_tag_string
(GExiv2Metadata *, const gchar *, const gchar *, GError **):
assertion 'value != NULL' failed
Instead of trying to set the tag with a NULL value, remove the (now
empty) tag, if there was any.
See issue #15032
In gimp_image_metadata_interpret_comment (), it's
possible to set the variable comment to NULL.
We then have a later if statement that checks if index 0
of "comment" is \0 - if comment is NULL when this
check occurs, we cause a crash.
This patch adds a check to confirm comment is not NULL
before running this if statement.
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.
