Let's create the folder returned by gimp_temp_directory() ourselves, the
first time this function is called, using a randomized name. This will
ensure that we won't conflict with another user running GIMP on the same
machine if using the base /tmp/ (which is usually the case on Linux).
Furthermore, since we create the temp folder at this level, we will also
delete it when quitting (but only if it's empty, as it should). Also I
use a single-level folder above the generic temporary directory, this
way, it's easier to track and we don't have to delete 2 levels of
directories anymore.
When the environment variable GIMP3_TEMPDIR is set though, we do not
create the folder, nor do we try and delete it.
And use the function in script-fu. While we want wrong resource names to
trigger WARNINGs in Script-Fu scripts and plug-ins (because these can be
considered as a bug), we don't want it to happen when the resource is
not loaded on purpose (mostly it means that we run GIMP with --no-data
or --no-fonts). This was happening in our own builds when running GIMP
through the in-build-gimp.py script and that was always very annoying.
Now in such a case, we will only output an INFO message on stderr (it's
still a good idea to warn about this, because if we imagined someone was
running a script non-interactively, which called one of these
procedures, they may have relied on the default value of some arguments.
Therefore they'd want to know about such a behavior change).
Technically not problematic but when inspecting using Plugin Browser,
the resulting hierarchy is confusing because it sometimes shows actions
to be inside "empty" directories if there are doubled path separators or
trailing ones. Let's not depend on the user to do this correctly when we
can do it for them.
Resolves#16102
The active selection can impact the other NDE filters
when exporting, resulting in empty spaces displayed when
the filter is outside the area of that selection.
Similar to what we do with XCF saving, we temporarily save
and clear the selection in the duplicated image. Then we
merge the filters and restore the active selection.
While it's possible to set mnemonics on GimpResourceChooser
properties (brushes, gradients, palettes, etc), the accelerator
itself wouldn't work because the label wasn't connected to the
button widget.
The buttons are created externally and connected in
_gimp_resource_chooser_set_clickable (). This patch adds a call
to gtk_label_set_mnemonic_widget () if there is a label, so that
pressing the accelerator key on the label triggers the button
click function.
A few things were not clear, if not even kinda wrong.
E.g. the returned effective color profile docs was confused about
returning a preferred profile; or saying that an image can have no color
profile assigned is confusing (it's true, but it sounds like it means
the image has no profile — which makes no sense —; whereas it actually
means the image uses a built-in profile).
… gimp_image_set_simulation_profile().
It looks like NULL through the PDB for 'bytes' argument gets passed as a
GBytes of size 0 (which might be something I did, and to be fair, that's
fine; I just forgot having done this).
As a consequence, testing for NULL was wrong, and these 2 functions were
always failing with NULL. Now they behave appropriately.
I also improve the docs for both functions.
The function's documentation was already saying that we could set no
profile, except that in reality, setting NULL for the profile was simply
failing. Unless one checked the return value, the failure is also quite
silent. So let's actually implement what the docs say.
Also the concept of "default" profile might be a bit unclear in GIMP as
it could mean either built-in profiles or preferred ones (as set in
Preferences). I chose the former for this function, so I reword this
part of the docs.
… gimp_drawable_curves_spline().
We can now run directly "gimp:curves" operation, both destructively or
non-destructively, but also setting the TRC, as well as individual point
types (when the curve is of type "smooth" instead of freehand).
This is much more powerful!
In particular, I am getting rid of several of the properties, which are
really not that good (and even bogus for some, such as "n-points").
Properties tied together like this (number of elements stored in one
prop applying to the array stored in another prop) are often a bad idea
and only end up in messy code ending up in inconsistencies.
Instead let's use signals. I am keeping the "n-samples" for now as it
can clearly be considered more "stable" than "n-points" and not meant to
change.
We'll also have to make a decision on whether we really want to keep the
samples API in libgimp, or drop all current sample functions. Right now
we cannot actually create meaningful sample points.
Adds a GimpCurve object and functions in libgimp.
Rather than creating a GimpCurve object in core and
passing it back and forth, we just pass the attributes
and reconstruct it across.
In the future, we may combine this with the app/core one
and put it in libgimpbase.
Our export dialog resizes the width of the dialog based on the size
of the longest comment line. Apparently certain programs save data
that can be very long. On Windows I did not experience a crash, but
the dialog is many screens wide and unusable in that state.
To fix this we change the horizontal scroll policy to
GTK_POLICY_EXTERNAL because GTK_POLICY_NEVER apparently stops GTK
from resizing the window at a reasonable size.
We also set wrap mode of the comment field to GTK_WRAP_WORD_CHAR
to make sure the lines that consist of only numbers without spaces
get wrapped at a reasonable length.
… std_pdb_deprecated for previously deprecated functions.
The &std_pdb_deprecated() call won't set a "Deprecated since"
information since this can't be made generic anyway. We have the info,
it'd be a shame not to document it!
Also it clears the blurb and help string, which I find unhelpful (even
for deprecated functions, it's better to have proper documentation!).
I have manually tested each and every of the deprecated functions,
making sure we don't lose any feature. As expected, we don't. Having
dedicated libgimp functions may feel a tiny bit easier to call but this
is not scalable. We can't do this forever, with one function per filter.
And fortunately we won't have to, since now we can call filters on any
drawable directly! It also comes with the following generic advantages:
* It works with any filter, even third-party ones;
* We can also append filters non-destructively for later removal or
edits (the deprecated functions were always merging the filters);
* If the filter evolves, e.g. with new arguments, it should not affect
the API (though we should implement GEGL operation versions);
* If we don't need to set all arguments (e.g. leaving many args with
default value), the filter API may even be simpler and shorter;
* The filter API will be much less "opaque" thanks to argument naming
(rather than a long list of integers, doubles, etc.).
Specifically to the now deprecated functions, I noted the following
weaknesses on the deprecated API when testing:
* gimp_drawable_colorize_hsl() was missing a "color" argument;
* gimp_drawable_extract_component() had the enum argument "component"
set as an integer, which is particularly opaque when re-reading
existing code. Whereas the filter API uses generate choice strings
which are self-explanatory! For instance choice RGB Red is 0 with the
deprecated function but "rgb-r" with the filter API.
* gimp_drawable_levels() was missing "trc" argument (as noted in
#15681).
And as expected, no features are lost.
Note that I didn't deprecate the curves functions yet, because we need
to implement the GimpCurve type in libgimp first.
There are a few more functions which I didn't deprecate yet, because
they don't use a filter directly, but some core functions, though for
some of them, it is very likely they can be efficiently reimplemented
with the filter API too. I'll have to look closer at it. It looks like
we may have to implement GimpHistogram in libgimp too though.
One point which was raised in #15681 is that the documentation is
lacking.
* Let's write down that the range of the point coordinates is in the [0,
1] range.
* Also let's rename num_points to num_coordinates because argument
points will actually contain 2 coordinates per points (so for 10
points, the points array will be of size 20). We also write that it
means that num_coordinates must therefore be even.
* Add more spacing in the docs and some better styling and annotations.
When calling `gimp_link_layer_new` from a plug-in, a critical was
shown:
LibGimp-CRITICAL **: 13:01:54.601: gimp_gp_param_to_value: type name
GimpLinkLayer is not registered
I noticed that its type was not initialized in libgimp/gimp.c.
This commit adds that initialization.
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.
