This is in part a backport of commit 6b86bb72f0, and a bit more.
In particular the mailing lists were still pushed forward (even though now
unusded for months!), and there was even a mention to the registry (which is
dead for years!).
This completes commit 685c8bde99 where the http:// scheme was automatically
transformed into https:// in some cases, in particular while typing (when
pasting for instance, it was still possible to add an http URL). So let's block
"toggled" signal handlers when the URL is explicitely edited to prevent this
annoying issue.
Resolves #6485.
The file-gbr-save procedure call was changed to require non-empty "raw-uri" strings.
The brush creation and select-to-brush scripts are still sending empty strings for that parameter.
This patch fixes the issue by reusing the filename parameter, as the paste-to-brush script does.
This is only a temporary solution meant to be backported to gimp-2-10 branch,
so that at least the preview now matches how angles always worked in at least
the 2.10 series: angles are measured clockwise.
Now there is the question that in the documentation of the Brush Editor, it is
written that angles are supposed to be counter-clockwise. A solution was
proposed to make them so, but only for generated brushes (whereas angles stayed
clockwise for other types of brush) which is a very bad inconsistency.
Furthermore I find the whole tool options vs. brush editor settings mess quite
confusing. Some decision should be made for GIMP 3.
For GIMP 2.10 though, this should be an OK fix: no behavior change on-canvas,
only making the preview actually match what happens on-canvas (even though it
goes against what the docs say but it's probably better than breaking workflows
relying on actual on-canvas behavior).
Note: this commit is based on an initial proposition by Alx Sa in MR !1119,
except that the patch was only working when the preview needed to be scaled.
Instead we must go through this brush transformation code path for generated
brushes, whatever the scale.
(cherry picked from commit eb7337d5e4)
This adds "https://" as a valid website prefix in the ImageMap URL edit
field, in addition to http://.
It also restores the prefix change that 2.10 had when you switched URL
types. It also fixes code formatting in affected areas.
(cherry picked from commit 6d02eb4505)
@Wormnest noted remaining regressions after 8faad92e.
The second fread() only runs if the DDSD_PITCH flag is set,
so the error handling check should also be conditional.
Additionally, the ZDI-CAN-22093 exploit no longer runs but
still could cause a plug-in crash. This patch adds an additional
check to ensure the buffer size was within bounds.
If the GIF has a value other than 0 or 49 in its PixelAspectRatio
header, then we now use it to set the non-square pixel resolution.
For reference, GIFs calculate this value like so:
PAR = (Value + 15) / (float) 64.
(Backport of 22963405)
@Wormnest pointed out that compressed files are likely smaller than
width * height * bps, so our check to prevent ZDI-CAN-22093
also caught valid files.
The size check is removed from load_image () and moved to load_layer ()
before the two fread() functions, as we know exactly how much we'll
try to read at that point.
(Backport of 8faad92e)
In Preferences > Toolbox, clicking on an item below the
initial scroll window view causes it to jump to the top
automatically. This patch prevents this by setting the
clicked index in the GtkTreeView before grabbing focus.
(Backport of @massimo 's !1107)
Some images have Exif.Photo.PixelXDimension and Exif.Photo.PixelYDimension
metadata tags in addition to Exif.Image.ImageWidth and
Exif.Image.ImageHeight (mainly tiff images). So far, we were not updating
these optional tags, meaning they could get out-of-sync with the actual
dimensions when resizing and then exporting the image.
Since these tags are non essential, we will only update them if they are
already present.
(Backport of @Wormnest's 52fb1e93)
Currently, patterns are loaded as-is - if the full pattern is larger
than the preview, it's cut off and you only see the left corner.
In those cases, the pattern is scaled using gegl_buffer_get ()'s scale
parameter.
Backported from !915.
Resolves #10119.
If the user sets the "Image Spacing" and "Hole Width" values
to 0, the hole creation code gets stuck in an infinite loop.
This patch adds a check to the allocation code for the hole
to make sure both its dimensions are greater than 0. If not,
then the hole is not created in the first place.
Resolves #10069
Currently, the DDS header information for the width, height, and bytes per scan line
are read in and assumed to be correct. As these values are used for memory allocation
and reading, it would be good to verify they do not exceed the file size.
This patch adds a condition after the header is read in to verify those values. If they exceed
the file size (mins an offset), the file is not read in and an error message is shown.
In our use case it is necessary to save the transform matrix, and the
easiest solution is to make the label selectable. If we print the
whole matrix into a single label, formatted with tabs and linefeeds,
then the whole matrix can be copied with a single operation.
to fix the issue when 'Standard' can be actual font from the list
or a font which starts with. (ie. Standard Symbols PS)
Fixes: #3104 (GNOME/Gimp tracker)
When replacing a selection, take and apply markup (if any)
from the first character of the selection for the entered
text.
This fixes the case when you no longer can change the
global layer text properties after replacing the text.
Also, this changes the behavior introduced in #1220.
Fixes: #7948 (GNOME/Gimp tracker)
(cherry picked from commit 4465db5223)
Resolves issue #9809, fixed by @mareroqpoland.
When "Separate Layer" is selected, the entire drawable is always
filled rather than using the selection. This patch uses the selection
instead (which will be "all" if there is no active selection)
Resolves #5742.
The check is for a horizontal line (where the Y coordinate
would be the same for all three points), but the X axis was
checked instead due to a copy/paste error.
(cherry picked from commit 624ae512fc)
The RGB histogram shows three histograms overlaid on each other.
This multiples the pixel and count attributes by 3. To correct this,
the result of gimp_histogram_get_count () is divided by 3 for the
pixel and count displays.
(cherry picked from commit bf1e125138)
So apparently Python 2 has been removed from the new Debian stable (bookworm).
As we still want to build the Python plug-ins in the CI, let's move on using
oldstable (bullseye) in gimp-2-10.
Resolves #5742.
From fa0a0212, the splash's upper text was scaled to PANGO_SCALE_MEDIUM
both when the image width was 2x or less than 2x. This was likely a
copy/paste issue, as the lower text code scaling does not duplicate.
This patch fixes it by changing the else condition to scale to
PANGO_SCALE_SMALL.
Note that this change is unlikely to be seen as it requires a very small
splash screen image to reach the else condition.
See also commit d22f1c3332 on the `master` branch. The main difference is that
right now the stable branch exits cleanly in all cases, so we don't need the
temporary environment variable to force the dirty exit (which ironically means
no crashes).
Photoshop can save metadata when exporting to tiff or jpeg, including
a thumbnail that we can't update. This can contain sensitive data, so we
should not export it. See issue #8383.
To do this, we add the two Photoshop specific tags that we know of to the
list of tags that should not be exported, so they won't be saved.
(cherry picked from commit f681c50414)
After testing a bit more, I realized that the thread was constantly re-rendering
the thumbnails, even though I didn't touch the "white-background"
button/argument.
This was not just a completely invisible problem, it actually affected the page
selection (it was very hard to select pages by clicking on them, it was randomly
working, and more often not selecting anything). This is how I realized there
was a problem.
The reason was simply that I was never actually calling g_cond_wait() because of
a first_loop flag I forgot to set.
Note that docs of g_cond_wait() explains that it is possible that "spurious
wakeup" happen. At first I thought I had this issue, which is why this commit
also adds a boolean flag to check after a wakeup, to make sure that I was in the
"condition met" case and not the "spurious wakeup" one.
Even though I realized afterwards the real reason was much more stupid, I still
left this additional check.
Fortunately this issue doesn't seem to affect the 2.10 code. Or to be more
accurate: the continuous render very likely happens there too, yet it doesn't
break page selection interaction with GTK+2 as far as I can see.
(cherry picked from commit 1584a9ba50)
Cherry pick note: though this issue didn't affect the dialog interaction in the
gimp-2-10 branch, I thought it'd still be better not to have never-ending
re-rendering of thumbnails for no good reasons.
...no image is active.
There are Arbitrary Rotation options under both the Image and Layer
menus. All of those rotation options are disabled without an image open.
To keep consistency, this disables those menu options as well.
The Tools menu Rotation option is left as-is.
(Backport)
...as parameters.
Currently, only file-gif-save can accept file paths in addition to URIs.
This results in inconsistent/unexpected behavior.
Now both versions of the GIF save procedure accept URIs or file paths.
First noted by Massimo in issue #5552.
"globalcomment" is used to store and retrieve comments for GIFs.
However, it is only loaded via the GUI; thus, the comment is lost if
you re-export non-interactively.
This patch adds code to also load the comment from GimpParasite if
non-interactive export modes are used.
gimp_display_shell_render() writes to a GeglBuffer backed by allocated memory
(shell->profile_data). Unfortunately while converting prevision in
gimp_image_convert_precision(), we change the "precision" property (hence the
source format) first, hence end up trying to write data in a too small buffer.
This crash was hard to find as it was not showing up on my machine (though it
did produce rendering artifacts!), unless I built both GIMP and babl with
`b_sanitize=address`.
Note that an alternate fix was to make sure that the profile_data buffer is big
enough (by calling gimp_display_shell_profile_update() before rendering), but
anyway the image is in an inconsistent state while conversion is in progress:
whereas the `src_format` is the new one, the `src_profile` is still the old one
(and cannot be changed before we finish converting).
Moreover the render happen regularly on progress signals, once after each
converted drawable. So each of these rendering step happens in an inconsistent
state, with the wrong profile set, some of the drawables converted and others
not yet.
We could still render properly if each drawable's buffer used space-aware format
(thus allowing different drawables to use different profiles/spaces), but it
feels over-engineering the problem. It might be much better to ignore rendering
steps while converting the image precision. Moreover it would obviously make a
faster conversion.
See discussions in #9136 for this crash, which didn't have dedicated report
AFAIK.
In case of negative y in the region to process, we were accessing invalid memory
(negative array index).
I hesitated between make so that a given ordinate always use the same index or
if we just want the start ordinate (whatever it is) to use index 0. The later
could have just been `(y - result->y) % RANDOM_TABLE_SIZE`.
I just decided to keep the existing logic (former case) though to be fair, not
sure it matters much.
While at first, the idea of always loading PDF with transparency seemed good
(commit 7aff7e9c70), I realized that a lot of administrative PDF (generated with
text and vector graphics, rather than scans or alike containing raster) actually
have transparency. So now all these documents load with transparent background.
Clearly all the office software are assuming that PDF readers will fill the
background with white.
So add a checkbox to decide whether or not to fill the image with white. I don't
update the PDB procedure. I'll just do this on the main dev branch (while also
updating a bit the code to newer API).
Fortunately I regularly open such PDF documents with GIMP and could witness this
no-transparency expectation before we released GIMP 2.10.34! 😅
The magics used for detection for CUR and ICO are not very unique and
interfere with the detection of certain types of TGA images.
Since these TGA images are regularly used, it seems better to only base
CUR and ICO detection on the extension, just as we do with TGA version 1
files.
See also issue #7912
Krita had a bug where it incorrectly saved 4 for the alpha bits instead of
8. We will allow 4 and convert that to 8 to be able to read the incorrect
TGA images.
The likelyhood of real TGA images with 4 alphabits seems pretty low, so it
should not interfere with real images that have this set. We were not
supporting that anyway.
(cherry picked from commit 5f9415a641)
Added the 2 new PDB functions. I should not have added these so close to release
(because these add 2 translatable strings for undo), but anyway the added
strings are barely GUI-facing as these functions are for plug-in developers.
And I really wanted to finally review these MRs which have been sitting there
for months. Sorry translators!
- fix a typo s/Commponent/Component/.
- Add &std_pdb_compat() to the new PDB procedures (I realize that's probably
what the contributor was asking about, back in !446). Not sure if it's right
as there were none in this file, but these are clearly just wrappers around
GEGL ops, so it seems fitting.
- Some alignment fixes.
- More accurate "$since" variables.
Original issue: #8581
1. When an image with a non-xcf format is loaded, within GIMP core it
qualifies as an imported file. (See gimp_image_get_imported_file
function)
2. But the guillotine plugin cannot propagate this information.
It can only set the file path on the new image it creates, and it uses the file extension of the original imported file.
3. But since the filename is set by the plugin is the actual filename not imported filename,
the gimpsavedialog.c module cannot differentiate it. This results in the
incorrect file extension being set in the "gimp_save_dialog_set_image"
function.
This issue can actually be present in other plugins as well that
generate new images which has to be checked.
This commit is a fixup commit for MR !790 which had a few issues:
- The args for shadows and highlights adjustments are "shadows-ccorrect" and
"highlights-ccorrect" respectively.
- Also fixing generated code.
This implements the full fix to the problem noted in the prior commit.
While it no longer crasheed when applying a function after clearing the
console, Jehan reported it still showed a CRITICAL message. This should
fix it the same as the 2.99 branch.
GTK2 get_iter_at_line_offset() does not allow invalid offsets unlike
GTK3 version. Clearing the console creates an invalid iter due to an
empty buffer.
This patch attempts to resolve it by adding a ">>> " output when the
console is cleared, thus preventing the invalid iter issue.
This reverts commit 13284c8953.
Actually I should not have backported this change from the `master` branch.
These functions are still public in 2.10 (and internal in the main branch).
This should fix our CI.
A bug in babl would run the color conversion twice when the input and output
buffer is the same and a LUT is available for the color transform. This is a
workaround in GIMP code (especially because we still don't require the latest
babl version), though a real bug fix will soon happen too in babl itself as
well.
The defcheck.py file finds these errors:
> Problem found in /home/jehan/dev/src/gimp/libgimpwidgets/gimpwidgets.def
> the following symbols are listed in the .def-file,
> but are not exported by the library.
> - gimp_color_picker_cursors_get_resource
> - gimp_icon_pixbufs_get_resource
Indeed these don't exist. Unsure why the autootols check failed to
report these until today.
(cherry picked from commit 01e87819ce)
Some PDF have transparency on purpose. Filling with white, without any question,
is counter-productive and prevents from working on such PDF files.
Note that we could add an option with a checkbox, leaving one to decide whether
to fill the background or not. But it feels over-engineering the issue. The PDF
is transparent, so that's what we load, and that's it. If one wants to add a
background, it's easy to add a layer at the bottom of the stack (and they can
make it any color they want, not just white), after loading the file.
(cherry picked from commit c369827725)
I had a TIFF file which would crash while triggering an error, inside g_logv()
code (and according to the stacktrace, even probably inside some lower level
printf implementation code).
The reason was that I already processed the variable list with
g_strdup_vprintf() and printf didn't like this va_list being reused, then
segfaulted with some "Cannot access memory at address" error.
The alternate fix was to first copy the va_list in the first use with
va_copy()/G_VA_COPY, yet since we already processed the format data, I thought
it was useless to do this. Let's just directly use the formatted string.
(cherry picked from commit fb1f16d4b8)
...when it shouldn't.
Backport of Wormnest's code.
When overwriting the same file when exporting, we didn't check if the
image previously had a thumbnail. If the default setting in Preferences
is to add a thumbnail, then it would add one where it shouldn't.
Since thumbnails get saves as part of the EXIF metadata, we need to check
that to see if there was a thumbnail in the original image.
However, we were always removing the thumbnail from the metadata on import.
Let's delay removing this metadata until we need to, which has the
advantage that the metadata in our viewer is more complete.
When exporting starts, we add a check in gimp_image_metadata_save_prepare
to see if there was a thumbnail in the EXIF metadata. If not, then we
disable the thumbnail flag.
In gimp_image_metadata_save_finish we remove the thumbnail metadata when
the user doesn't want to save a thumbnail, or when the image format
does not support EXIF.
Apparently GDK/Win32 sends the "grab-broken-event" signal before the "clicked"
signal. This has only been changed since GTK4 so far.
Anyway the bottom line is that GimpContainerPopup would process a handled on
"clicked", using the object destroyed when "grab-broken-event" happened as
callback data. The solution is to make sure that the object stays alive long
enough. So I'm changing gimp_editor_add_button() to connect to signals with
g_signal_connect_object() (since all usage of this function was used with
GObject callback data, it was not a problem).
See discussion in !815.
As a side change, gimp_container_popup_dialog_clicked() should emit the
"cancel", not "confirm". This part was taken from MR !815 by Lloyd Konneker.
(cherry picked from commit f77f772f56)
is positive or zero. Sometimes the calculated `y` or `bg_y`
values are negative because the histogram value was divided
by zero (when max == 0.0).
Resolves: #9132 (Gnome/GIMP bug tracker)
(cherry picked from commit 9b517fbf7d)
The Y offset of the statusbar tool icon is too large, which pushes it
off-screen. This scales the offset by the size of the icon to
prevent this problem.
This reverts commit f7e7f396aa.
See issue #8269.
For GIMP 2.10, I'll just revert this commit so that we get back to pre-2.10.32
situation. For 3.0, we'll try to do something better.
This sets the default TIFF export to "normal" TIFF (regardless if GIMP
was built with BIGTIFF support or not). It then checks if
the BIGTIFF option was previously selected on export
to optionally set the option to TRUE.
Backport of Wormnest's code to fix #5438.
Certain PSD layers have a flag called clipping set to 1. We were not
handling this flag and had some reports about colors bleeding where
they were not supposed to.
We are going to set GIMP's layer composite_mode to
GIMP_LAYER_COMPOSITE_CLIP_TO_BACKDROP, which is the closest we can get
to PhotoShop's clipping. With this, the colors won't bleed anymore.
This isn't the whole solution since PS apparently stops compositing when
it encounters a layer
without clipping set, while GIMP doesn't stop until
it reaches the bottom layer of a group or the image.
PhotoShop handles clipping layers in a different way than GIMP. The only
way to have it look the same is by adding extra layer groups.
PSD layers that have clipping set, combined with the first non clipping
layer below it are grouped together in a new layer group.
Doing this results in the same image as the PSD merged image unless there
are other PSD elements in play that we don't handle yet.
See e.g. the NSFW image
in the mentioned issue where the purple hair color
is a little darker than the merged image.
...visibility column.
Makes it much more obvious where you have to click for visibility, and
where each column is. Also it's more consistent.
Backport of Jehan's code.
Porting code by Stanislav Grinkov from dev branch.
Adds option for selecting predefined page sizes using the same
template selector as on "New Image" dialog.
Syncs up size and offset unit selectors to have the same value
when changing template and when resetting whole dialog.
Also adds pixel density
selector to canvas size dialog
which will be shown when selected template pixel density doesn't
match the image pixel density.
Then user can either keep current image ppi and scale the
template or set image ppi to match the template ppi.
Density selector displayed only when template and image ppi
differs and template unit is matches one of real world units
(e.g. inch, mm, etc).
vertical space.
Let's use the horizontal space a little better.
To do this, Jehan moved the preview on the right side of the Canvas Size
and Offset number fields, and the "Center" button just below it.
It is better to add a comment rather than simply disabling these 2 calls without
explanation on macOS. This way, developers who'll look at this code in the
future will immediately know what's the reason and status for the "unicity"
concept of GIMP process on macOS. Basically there are 3 features:
- Opening files from another software (such as "open with" in file browsers)
which is handled differently in macOS and apparently works fine. It looks like
it works by handling system signals, connected from gui_unique_quartz_init().
- Opening files by running a new GIMP process which would pipe the filenames
into an existing GIMP process before immediately exiting.
- Running batch process in an existing GIMP process, also by running a short-run
GIMP process.
The last 2 features are simply now officially disabled in macOS because dbus is
not installed by default and seem like it may cause issues when it is.
See discussions in !808 and #8997.
(cherry picked from commit 68cd873481)
DBus can cause instability on the MacOS platform, and regardless
MacOS handles application uniqueness already.
The batch version has also been modified as it only applies if
compiled as an application, since it returns FALSE if it is complied
as a console app.
(cherry picked from commit 9102e47637)
Instead of using the string directly. This ensures that possible updates
in the string don't go unnoticed in gimp-help.
(cherry picked from commit 8372220345)
Add several missing help ids, remove those that are not used anymore,
and update "gimp-colorselector-water" to "gimp-colorselector-watercolor".
Also add a comment why some help ids are not used directly.
Partial back-port of JPEG XL export from GIMP 2.99
Export is always in 8bit lossless.
Export is quite slow but compression efficiency is usually
significantly better than PNG
and yet slightly better than lossless WebP.
- Use g_malloc* functions instead of malloc, so we don't continue on
failed allocations unless we test for NULL.
- Make sure we don't iterate past the known number of control points (ncps).
- Safely allocate, initialize and free points. Since points seems to be
used uninitialized, we use g_malloc0 to set everything to 0.
(cherry picked from commit 981979bb39)
Thanks to a report by Stefan Cornelius, we became aware that the flame
plug-in does no checking for correct input when loading a pre-saved
settings file.
I reworked the parser to read one or more values based on the type of
token, making sure we also don't read past the end of our token buffer.
All int values have a min and max value set. If any unexpected input is
encountered, we will give a warning.
(cherry picked from commit 89c83ef4c7)
The flame plug-in can read stored settings from a file. The expected
input is that a ; signifies the end of input.
However, with user input we cannot depend on this to be true, so we need
to make sure that we do not read past the end of our input buffer.
To do so, we add a length check.
(cherry picked from commit 536c7cbc4b)
We were using the plug-in name with underscores, which is incorrect.
Since nobody ever complained about this, this doesn't seem to be used
very often.
We will use the const that defines the plug-in name instead.
(cherry picked from commit 193596397e)
Adds a toggle to let users load TIFF pages with FILETYPE_REDUCEDIMAGE
tags. The specs do not state that these are always thumbnails, and they
may have other uses. We assume that if only one page with this metadata
exists then it is a thumbnail; otherwise, the toggle option is
enabled on load.
This help id was used in the past but all references to it were removed
long ago with commit c53113d0cc.
Let's remove this define too since it causes a warning in gimp-help when
checking for help id's without documentation.
(cherry picked from commit 4b4dd5ec38)
Automake doesn't accept the "if else" syntax. Instead, we must add a new if/else
inside the first else block.
While I'm at it, I also add a G_GNUC_INTERNAL to the internal function
_gimp_pick_button_win32_pick(), though I don't think it's absolutely necessary
(yet explicit is better).
(cherry picked from commit 8ac5178214)
Update processing has to be done on the main thread to avoid
problems with GTK thread safety.
(cherry picked from commit 7f257a3a33)
Conflicts fixed:
app/gimp-update.c
We were using GIMP_UNSTABLE extensively to differentiate development
from stable code. But there is actually another level of development
code. Basically GIMP_UNSTABLE tells you are on the development branch,
e.g. for current branches, that you are on 2.99.* versions (vs. 2.10).
This depends on the minor version oddness.
GIMP_RELEASE will tell you if it's a release or a in-between-releases
code. This works with the micro version which must be even on release.
Any odd number means you are basically using random git code.
There can be any combination of GIMP_RELEASE and GIMP_UNSTABLE. For
instance 2.99.12 is a release of the unstable branch, whereas 2.10.33 is
development code of the stable branch.
I use this first in the update code as we were using GIMP_UNSTABLE for
both concepts but it made it harder to test. Now:
* GIMP_DEV_VERSIONS_JSON environment variable is only available on
development code, not on release (whether stable or unstable).
* The weekly check limitation is also only for releases (dev code just
check at every startup to quickly detect issues and regressions).
* Whether to look on testing website or public website json file depends
on the code being a release or not.
* Finally only whether to check "DEVELOPMENT" or "STABLE" sections in
the json file depends on whether we are on stable or unstable
branches.
(cherry picked from commit fbb5b40345)
I.e. non-macOS and non-Windows. For these, we don't really care about
the startup check usually (which is normally disabled anyway, at least
as a default), but we still care about the version check to work when
explicitly requested through the "About" dialog's button.
and import as inches
When GIMP's display unit was mm, our PSD export converted the X and Y
resolution as if a conversion from mm to inch was needed.
However, PSD's resolution is always measured in pixels per inch, so a
conversion is never necessary.
Removing the conversion, resolves the issue.
(cherry picked from commit 24886f91b1)
Add the info about max dimension of WebP with WEBP_MAX_DIMENSION macro.
There is also a test about (picture->width / 4 > INT_MAX / 4), resp.
height, but this should anyway never happen as the C spec says the
smaller range for int is [-32767, 32767], which is an order bigger than
the current WEBP_MAX_DIMENSION (16383).
So we are probably fine assuming all VP8_ENC_ERROR_BAD_DIMENSION errors
will happen because of WEBP_MAX_DIMENSION.
(cherry picked from commit dfb7d2543a)
Actually our X11 implementation is right, and the implementation from
the Freedesktop portal is "as far as it can do", i.e. that we get the
returned RGB value, which is unfortunately in display space. And it
doesn't return any space information together (we don't even know which
display the color comes from, in multi-display setups).
Therefore let's check if we are running GIMP on X11 and if so, let's
call this implementation first.
See this report on xdg-desktop-portal to get proper space info:
https://github.com/flatpak/xdg-desktop-portal/issues/862
(cherry picked from commit 9b21688501)
Cherry-pick note: GIMP 2.10 on Linux will just run on X11 even inside
Wayland (XWayland) so there is no need to check anymore if we are
actually running on X11 with GDK_IS_X11_DISPLAY() (to be more accurate:
you can't on GDK 2!). So now if X11 is compiled in, we simply use the
default color-picking implementation and drop portal calls. As simple as
that.
created by Adobe Lightroom 5.1
Adobe products are known to write incorrect RichTIFFIPTC tags in TIFF
images.
Since libtiff correctly detects and handles this there is no real need
for end users to be warned. So instead of a warning we will only output
a message to stderr.
(cherry picked from commit 0ad54f863a)
This is essentially the same check as done in gimp_image_set_resolution,
but doing it here means we can load the image instead of throwing an
error.
We still need to get replacement xres and yres values, because these are
used to compute layer_offset_x_pixel and layer_offset_y_pixel.
(cherry picked from commit ced071a8ee)
Image m2-d0f86ab189cbe900ec389ca6d7464713.tif from the imagetestsuite
is a fuzzed image with an invalid very high number for the channel count.
This causes GIMP to become unresponsive for a very long time. Possibly
trying to allocate memory for all channels or another cause related to
the high number of channels.
Let's go for a more "reasonable" limit of 99 channels like we also do
for Photoshop images and show a message when we find an image with more
channels.
(cherry picked from commit 18d466df7f)
When loading a TIFF image using a script/plug-in in non interactive mode,
we did not initialize the list of pages, causing a crash when trying to
access it.
So, always initialize this list when non interactive.
(cherry picked from commit 853e9d5cb4)
Due to a change in the format string in libtiff, warnings about unknown
fields were not filtered out anymore.
Adjust our filtering of warning messages so we catch this again since
end-users don't need to worry about this and we don't need the
possible extra issues.
(cherry picked from commit ac5a6e56b7)
Apparently some layers in PSD files can have extra channels which we
did not account for when computing destination offsets, causing crashes.
So let's make sure we don't include the "extra" channels when computing
the offsets by introducing base_channels. We also move the alpha channel
in the spot of the first extra channel (even though it seems, based on
the one example we have, that the extra channel might be the same as
the alpha channel).
(cherry picked from commit 5fbd06629d)
# Conflicts:
# plug-ins/file-psd/psd-load.c
Just use the image format as-is. The only problem now is that we don't
support all formats for loading in file-raw yet.
(cherry picked from commit 01e0675f67)
Conflicts:
plug-ins/common/file-raw-data.c
We only set tiff_mode for images with bps < 8, but we also use it for
8 bps grayscale images to detect if MINISWHITE needs to be converted.
So, let's always set tiff_mode for PALETTE, MINISBLACK and MINISWHITE.
(cherry picked from commit 2e4b9bcba7)
generated by matlabs blocproc function
Based on the suggested solution by Massimo, we should not compute the
remaining pixels per line but only at the end of the whole block, be it
tile or scanline.
I have not been able to find bw or palette examples that use load_separate
instead of load_contiguous, so that case is not tested. But, it also
doesn't make much sense to have planar when you have just one plane.
(cherry picked from commit 94de89febf)
In a previous commit 1, 2 and 4-bit B/W images were converted to grayscale.
However, it seems that there is more of a use case for these images to be
handled as indexed, even though technically they can be considered
grayscale.
Also, the only way to export these images again in the same format, is to
have them as indexed.
So, let's change this back, so that these kind of images will be opened
as indexed. With a reminder that in the future we could add an option
at loading time where the user can choose whether they prefer it to be
loaded as indexed or grayscale.
We use grayscale mappings, that we moved in the previous commit, to
add a palette to these grayscale images.
(cherry picked from commit 3e6237030c)
In preparation of using some of them earlier, we move the variables
used for grayscale mapping of 1, 2 and 4-bit per pixel images to the
top of file-tiff-load.
(cherry picked from commit 11ef2e4432)
# Conflicts:
# plug-ins/file-tiff/file-tiff-load.c
This will allow to use the official Windows installer directly in the
Windows Store, as per the new proposed workflow by Microsoft.
Nevertheless our GIMP for Windows has a built-in update check which
would check if a new version exist and warn people (advising them to go
on the website and download the new installer to update). We obviously
don't want this on the Windows Store which has its own update channel.
It would be confusing.
Therefore I added a feature to disable the built-in update check (not
even showing in Preferences) by tweaking a single package variable. The
installer now comes with new option /DISABLECHECKUPDATE=true which will
add said variable.
(cherry picked from commit 10145bb938)
GIMP was saving the last changed/saved date to IPTC tag DateCreated,
which should only be used for the original creating date of the image
and thus should not be changed by GIMP.
After discussion in the cited issue, there is no tag in IPTC that we can
use, so we remove saving modified date from the IPTC metadata.
Instead we add two XMP tags, one for modified date and the other for the
date that metadata was changed. Since we do both when exporting, both are
saved with the same date/time in ISO 8601 format.
This also fixes another issue where we were not storing the timezone offset
for Xmp.tiff.DateTime. Since this has the same format as the other
XMP tags, we fix this together with this issue.
… in the gimp-release file.
This will be useful to disable the update check for the Windows Store
even though we use the same build as the installer. All it will take
will be to append the line `check-update=false` to the file
`share/gimp/2.10/gimp-release` and it will behave as though the update
check is disabled (even though it is actually built-in).
(cherry picked from commit 9ef10c8764)
Conflicts fixed:
app/dialogs/preferences-dialog.c
More safety checks for detecting broken xcf files, also based on examining
issue #8230.
After reading an offset where layer, channel, etc. data is stored, we
add a check to make sure that offset is not before where we read the
offset value. Because the data is always written after the offset that
points to it.
(cherry picked from commit a842869247)
Improvements in loading broken xcf files, based on examining issue #8230.
Besides checking for a minimum width and height, GIMP also has a maximum
size we can and should check.
In the case of the image itself, we change invalid dimensions to a size of
1 in hope that the individual layers etc will have the correct size.
For layer, we will also try to go on, but for channel and layer mask, we
will give up.
(cherry picked from commit 24c962b95e)
gimp_channel_is_empty returns FALSE if channel is NULL. This causes
gimp_layer_invalidate_boundary to crash if the mask channel is NULL.
With a NULL channel gimp_channel_is_empty should return TRUE, just like
the similar gimp_image_is_empty does, because returning FALSE here
suggests we have a non empty channel.
(cherry picked from commit 22af0bcfe6)
Adds a new option to flip the image on export. This allows for
direct imports into certain DirectX engines without altering the
project file. It also adds a new option to save all visible layers on
export, again to avoid altering the user's project file.
Backports option from master to toggle whether IPTC and thumbnails
are saved on export. Note that in webp format, IPTC data is saved
via XMP, so if XMP is not saved, IPTC option is deactivated.
JXL import is backported from GIMP 2.99
Added .jxl association for Windows installer
It was necessary to adjust plugin-defs.pl for HEIF plugin,
because necessary dependencies were missing there.
With large image sizes a 32-bit int is not enough for the intermediate
computations, which byte per pixel, width and height are.
So, just like the function below it does: gimp_gegl_pyramid_get_memsize,
we will cast these to gint64.
Thanks to Massimo Valentini for finding the cause.
(cherry picked from commit ba841a98da)
Removal of the snprintf define was also part of the UCRT Windows patch
in MINGW. Although it builds fine without this change, there is no need
anymore to redefine snprintf. In addition, I seem to remember that
_snprintf had a shortcoming.
So let's remove the Windows specific code, since it works fine without it.
(cherry picked from commit e268d38fb1)
The UCRT environment is a successor to the MINGW environment on Windows
with a more modern C runtime library.
Building under UCRT we get this error:
../../gimp/plug-ins/file-raw/file-darktable.c:420:7: error:
function '__p__environ' is initialized like a variable"
To fix this we use the relevant part of patch 6 from:
https://github.com/msys2/MINGW-packages/tree/master/mingw-w64-gimp
(cherry picked from commit ef817dc452)
when Offset and Dimensions Bigger than File Size.
If we didn't read the exact amount of bytes, the whole image would be
filled with white.
Let's change this, so we read as much bytes as we can, and fill the rest
with white.
(cherry picked from commit 3644b9010a)
GIMP could crash if the information regarding old path properties read
from XCF was incorrect. It did not check if xcf_old_path succeeded and
kept trying to load more paths even if the last one failed to load.
Instead we now stop loading paths as soon as that function fails.
In case we have a failure here we also try to skip to the next property
based on the size of the path property, in hopes that the only problem
was this property.
(cherry picked from commit 4f99f1fcfd)
This was a long standing issue where the image was not printed at the
position as selected in our print preview.
The problem being that we do not take into account the dpi of the print
context we are printing to, but instead always assumed 72.
This is the fix that was suggested by Massimo.
(cherry picked from commit 0e462440cc)
As mentioned by Massimo in issue #6618, part of the problem there is an
integer overflow when using large size images when computing the offset
in pixels.
Let's fix our part of the problem by casting to guint64.
Besides that, also use casts to correctly compute progress for very
large images.
(cherry picked from commit cd4401fee4)
GIMP stopped trying to read the XCF as soon as an invalid parasite was
encountered. However, in this specific case only the parasite data is
invalid, while the rest of the image is not corrupt.
Instead of terminating when we see a corrupt parasite, we skip to the
offset after the parasite. This may still be corrupt, but we can handle
that correctly, see e.g. the XCF in bugzilla issue 685086, which was
the reason of some of the previous changes.
Additionally:
- We add some logging to make it easier to handle future issues in this
area.
- We add tests for a NULL parasite name, and for reading a different
amount of parasite data than we expected. In both cases we return
NULL instead of a parasite.
(cherry picked from commit 5b39bc963d)
with many Xmp.photoshop.DocumentAncestors tags
This is similar to #7464, but in this case the XMP metadata was already
included in an XCF image.
We check for the occurrence of Xmp.photoshop.DocumentAncestors and stop
handling values when there are more than a 1000.
It would be easier to just check length for all tags and always
ignore when there are more than a 1000 values.
But in that case we would need to be sure there are no valid reasons for
tags to occur more than a 1000 times. So let's just limit it to this
specific tag.
(cherry picked from commit cadf485299)
# Conflicts:
# libgimpbase/gimpmetadata.c
Also when working on out-of-tree builds, it would not find the file
anyway and we get this output:
> chmod: cannot access 'test-installer-langs.sh': No such file or directory
Though this was not breaking the tests, it has clearly been useless
until we see this one today.
(cherry picked from commit 201cbe7e3e)
We heavily rely on GError in libgimp to retrieve plug-in error messages.
In a lot of our code, we just use domain=0 for g_set_error*() functions
and alike, but this is actually forbidden and results in GLib warnings.
Some plug-ins instead create their own domain, other use G_FILE_ERROR
nearly everywhere, even in some cases where the choice is really
questionable. Since anyway this is mostly useful for passing the error
message through, it is much nicer to provide a generic domain
GIMP_PLUG_IN_ERROR, which can be used by all plug-ins when they don't
want to bother with the error domain.
Note: basically a copy-paste from commit 3f9c736592 which could not be
cherry-picked as surrounding code is completely different.
In issue #7528 the wrong export dialog label "RGB Save Type" caused
confusion.
Let's change it to "Palette Type", the same as it is in our master branch.
This is the same issue as with IM000001.dcm mentioned in issue #313.
There are two problems: incorrect endian conversion for 16 bits per pixel,
and not handling photometric interpretation "MONOCHROME1", which means
minimum value is white instead of black.
The endian conversion was fixed as suggested in issue #313.
For "MONOCHROME1" we added a variable bw_inverted and we invert the pixel
value if that variable is true.
(cherry picked from commit e51ca66ee5)
Just like COLOR targa MAPPED (indexed) images with a size of 32 per
index should also have alphaBits set to 8 or else the images get
loaded incorrectly.
(cherry picked from commit a77131db3c)
Exporting an image to TGA fails with a crash when it's an indexed image
with alpha channel. We were not taking into account that even though
the output is 1 byte per pixel, the input should allocate memory for
2 bytes per pixel (1 color index and 1 alpha channel).
(cherry picked from commit 059599fc78)
Some images have huge amounts of XMP tag Xmp.photoshop.DocumentAncestors.
In certain cases more than 100000 values. This is apparently due to a bug
in certain versions of PhotoShop.
This makes deserializing it in the way we currently do too slow, probably
because of continuous reallocations after adding each value. Until we can
change this let's remove everything but the first 1000 values when
serializing. I think it is very unlikely there are any real cases where
more than a 1000 ancestor documents are referenced in an image. Testing
shows that this amount doesn't cause any serious slowdowns.
(cherry picked from commit b2c715b52b)
The gimp-2-10 patch contributed as !514 was slightly different from the
master one as !515, especially since the last one got the reviews. This
syncs the 2 codebases (making it easier to backport future patches on
the same piece of code) and do a few fixes.
- Syncing alignments.
- Fix a comment.
- Use g_build_filename() for properly creating paths rather than string
concatenations.
… rather than generic "gegl:load" and "gegl:save".
In particular, it means using "gegl:rgbe-load|save" for RGBE images and
"gegl:exr-save" for EXR exporting.
Without this, we could encounter weird run cases where for instance, we
would detect a RGBE image through the file magic number in GIMP,
redirect the load to file-gegl, but "gegl:load" only relies on file
extension. So if the file extension was not ".hdr", "gegl:load" could
redirect to a different handler operation meant for another format,
hence break proper loading. If no extension was matched, it could even
redirect to a fallback handler, such as Image Magick.
This breaks loading or saving images which we would be otherwise able to
load/save. And it could also have some security implications. So let's
fix this by setting the accurate operations to use for each specific
file formats we want to support through the file-gegl plug-in.
Note: this is the gimp-2-10 version of commit e8a31ba4f2 (`master`
branch) adapted to the older 2.10 API.
Note that the full magic should be "#?RADIANCE". Not sure why we only
use the first 2 characters. Do some software create these RGBE files
with just "#?" and we want to be able to read these? No other image
format use these 2 characters as the start of their own magic numbers?
Anyway let's keep like this for now. We'll see. If it makes a problem,
we might update to more accurate magic later.
(cherry picked from commit d5164072e0)
… implementation and Freedesktop portal.
This is an alternative to commit ef9c483771 (`master` branch) for the
2.10 series. On the dev branch, we simply get rid of the KDE portal
implementation, on the basis that by the time that GIMP 3 gets released,
most KDE users will have a recent-enough KDE with featureful Freedesktop
portal.
Yet for the 2.10 series, I am wary that there might still be many KDE
installations where maybe there is not even a Freedesktop portal. So I
just switch the test order. Now we use the X implementation in priority,
if we are running in X (it's still the most featureful and robust
version anyway). Then we test the Freedesktop portal. And finally we
test the KDE portal. I am guessing that if we encounter a KDE
installation with no Freedesktop portal but a KDE one, it's an old
version so we won't have permission issues.
See issue #5785.
When a channel is selected as bumpmap, the bump_format can be different
than it was before. However, we always kept the first bump_format, which
could be RGB, in which case trying to use it with a channel caused a
crash in GIMP.
To fix this we always update the bump_format if bumpmap is enabled.
(cherry picked from commit 7b7d616358)
# Conflicts:
# plug-ins/lighting/lighting-image.c
Freedesktop (XDG) portals are a collection of D-Bus APIs that work
across desktop environments, display servers and work within
containerized applications, like Flatpak. The internal implementation
can then choose to implement these in such a way that takes into account
security considerations, as well as making sure the user consents to
certain actions.
One such portal is the `Screenshot` portal, which contains a
`Screenshot()` method as well as `PickColor()`. We already use the
former for taking a screenshot, and this commit makes sure our color
picker also makes use of the latter.
By doing this, color picking is now possible on the major Wayland
compositors.
(Honestly, we should remove DE-specific backends like that of KWin, to
have less variation on the possible results of a color picking
operation).
Fixes https://gitlab.gnome.org/GNOME/gimp/-/issues/1074
(cherry picked from commit e82f6d5b0f)
See the comments in MR!424.
Basically realpath relies on false assumptions (probably ones which used
to be true when the API got created) on the max size of a path. Actually
nowadays paths can be much bigger than what the macro advertizes or can
even be unbounded.
The Linux version of realpath() allows the second parameter to be NULL,
in which case it would allocate the buffer, exactly for this reason
(written in the BUGS section on the man). Unfortunately this behavior is
not standardized in POSIX and the man from Apple I found does not
indicate it will do this.
So let's use g_canonicalize_filename() instead, which seems to do the
right thing. Similarly use g_strdup_printf instead of g_snprintf().
Cherry-picked from commit 6f4fac7715eb66a90727f931246c93cd8e13a819 with
some conflict resolution.
GNOME Shell has started restricting access for it's Screenshot D-Bus API
to internal components only [1] for security reasons. In other words,
this will start failing, so remove it in favor of just using the
freedesktop portal, which should always work.
[1]: https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/1970
(cherry picked from commit 62953e6830)
This proved to be both an import and export issue.
Our import set expected format as RGB, causing garbled image output.
Our export for indexed images converted to grayscale first, although the
palette was correctly saved. This caused wrong palette indexes on import.
For indexed images, on import, we request the actual indexed format after
creating the layer with gimp_drawable_get_format, which gives us a correct
indexed Babl format.
Also added logic for indexed with alpha, although I have no sample images
to test this.
For indexed images on export we do the same: use gimp_drawable_get_format
to get an actual indexed Babl format.
(cherry picked from commit dec5ca2219)
# Conflicts:
# plug-ins/file-dds/ddsread.c
… series as well (it was already so in the `master` branch).
See discussion:
https://gitlab.gnome.org/GNOME/gimp/-/issues/7515#note_1318891
Basically it's probably possible to backport some changes and still
support an older version, but we clearly lack contributors on macOS so
the current unique one's decision matters most.
In cases where the whole EXIF MakerNote is invalid we still load that
MakerNote data and export it too, causing partial invalid EXIF metadata.
We don't need to explicitly save Exif.Photo.MakerNote at all, because
as soon as we try to save a brand specific tag exiv2 will create that
MakerNote tag itself.
So from now we don't save the MakerNote but only the tags that go in it.
In issues like #2159 where exiv2 doesn't parse all tags inside certain
brand specific MakerNotes correctly, we will still export invalid EXIF.
That is an exiv2 issue that we can't do much about unless we remove all
MakerNote metadata including those that we can read, which doesn't seem
like a good idea at all.
(cherry picked from commit 6840bb9eba)
Fix as suggested by Massimo with formatting adjustments by me.
The use of gulong and glong is not cross platform safe: on Windows it is
32-bit and on most other platforms 64-bit.
Let's use guint64 and gint64 instead.
(cherry picked from commit d2c5591088)
When we try to export a grayscale image with layers with negative offsets
to a GIH brush GIMP crashes without producing any crashlog.
Running in GDB showed us that there is heap corruption caused by incorrect
computation of buffer sizes because of the negative offsets.
In file_gih_image_to_pipe there is a comment that offsets are assumed
positive, but no checking is done whether that is correct.
Let's add some checks, set offset to 0 if negative and adjust width and
height accordingly.
(cherry picked from commit e2b1cc9476)
On Windows when exporting an image saving the exif and other metadata fails
if the path or filename includes non ASCII characters.
Reason is that gexiv2 changed to using utf-8.
In the past we had to convert the filename to current locale on Windows,
but since it now also expects utf-8 there, just remove the special
handling of filename there.
(cherry picked from commit 8e1f982945)
PSD images using CMYK as color mode and without layers didn't load
correctly (wrong colors).
When a PSD does not have any layers, CMYK color mode was not converted to
RGB.
Note that PSD color images that do have layers (e.g. CMYK and LAB) store
the merged image as RGB!
To do all this we added a conversion for CMYK PSD with 0 layers and added
code to correctly determine whether an alpha channel exists.
This also fixes the case where loading the merged image of a 16 bit per
channel RGBA psd loads with the alpha channel opaque.
(cherry picked from commit b7518195b5)
Probably due to a copy-paste error the case without alpha was also using
the img->cmyk_transform_alpha instead of img->cmyk_transform.
(cherry picked from commit 5115021eac)
Our psd plug-in checks for valid layer mask sizes. Apparently a psd
layer mask where the rendered flag is set can have invalid dimensions
0, 0, 0, -1.
We will skip the sanity checks for rendered layers and at the same time
move the debug statements up to have relevant debug info available even
if our sanity checks stop further processing.
(cherry picked from commit b27bf5caa9)
Detected issues fixed here:
- Use GString and g_string_append since otherwise we need to add g_free
after every g_strconcat.
- No error checking.
- We need to g_free value_utf.
Not detected by coverity:
- Wrong quotes around utf-8.
- Remove unused includes.
(cherry picked from commit 641080c838)
Several resource leaks here were detected by coverity:
- Not freeing value_utf.
- Strings returned by g_strconcat should be g_free'd. To handle the string
concatenations easier we use GString and g_string_append instead.
Also introduce function get_list_elements to reduce the number of
repetetive elements.
While we were at it, also remove unused includes.
(cherry picked from commit e90f041ca5)
When writing metadata in the metadata-editor it did not check for empty
values. In combination with gexiv2 0.14.0 (which doesn't check in this
specific case for an empty list of gchar **) and trying to set a non
repeatable Iptc tag (Iptc.Application2.Headline) using
gexiv2_metadata_set_tag_multiple we get a crash.
This fix checks first for a non empty value before trying to save the
metadata tag.
Since the code is very similar also implemented this check for the Xmp
tags in addition to the Iptc and simplified some duplicate code.
(cherry picked from commit 6eba73e714)
See issue #7408 where this is causing a crash when using gexiv 0.14.0
in combination with trying to save it as a multiple tag with an empty list.
According to https://exiv2.org/iptc.html the tag Iptc.Application2.Headline
is not repeatable so we will set mode to "single.
In addition to that I added comments to explain the differences in the
meaning of "single" and "multi" between the list of Xmp tags and Iptc tags.
(cherry picked from commit b070c6fba6)
Not sure why but adding a handler to the "expose-event" signal of
GimpDisplayShell (similarly to how we do it in master branch on "draw")
just didn't work. But it works on the already existing signal handling
on the canvas instead (which actually is not a bad deal, as we also
remove the coordinates translation so maybe we should test this on
`master` too).
Note: why we are backporting all this logics to gimp-2-10 is because
changes in macOS BigSur broke the selection's marching ants the same way
they broke on Wayland and it was confirmed this fix worked for BigSur as
well, at least on the dev builds.
It is unnecessary to backport for Wayland (because GIMP 2.10 is based on
GTK2 which anyway works only through XWayland, hence doesn't have the
issue), we do it only for macOS BigSur (and further). Well at least the
fix will hopefully work on the stable branch, because I cannot test
myself.
See issue #5952.
I'm still very unclear why exactly but it would seem that just queuing
the redraw with an idle function is not enough. At least on Windows,
Jacob was having cases where opening an image would get stuck unless the
mouse was moved (causing draw events most likely).
So let's use a timeout function instead. Probably no need to queue the
idle followed by the timeout function as we had before commit
4fee04b839. Instead just directly queue a draw if relevant, then run the
timeout at regular interval (marching ants speed).
(cherry picked from commit 668c9de5a5)
This way, we would queue a lot less canvas region unnecessary redraws.
We still remake the time-before-last-draw check in the draw() signal
handling before we want to update the marching ants index for draw
events coming for other reasons (canvas updates, moving/zooming on
canvas, exposition changes, etc.).
(cherry picked from commit 6466d46052)
… displayed.
We should use the dimensions from the GimpDisplayShell not the the
GimpCanvas. Indeed the canvas is shorter when rulers are visible, hence
the selection next to the extreme sides (bottom and right sides of the
canvas) was not drawn.
(cherry picked from commit e8a531e51e)
As suggested in a comment (itself coming from an IRC discussion), we
should not use gdk_window_(begin|end)_draw_frame() functions as this
works on X, but not on Wayland anymore. Instead draw directly during
draw() call of the shell widget, and force it to happen regularly, to
update the marching ants, via gtk_widget_queue_draw_region().
This is tested and works on Wayland. Please everyone, test thoroughly to
make sure it works well in all situations, and also that we don't get
any unexpected slowdowns.
Since the symptoms are very similar, it is highly possible that it also
fixes the issue #5952 too, for selection not showing on macOS since Big
Sur 11 (maybe they changed the same way as Wayland did). Unfortunately I
can't check this myself. Please test, whoever has access to a macOS Big
Sur and can build GIMP!
(cherry picked from commit 4fee04b839)
… apply to GIMP GUI not text layer rendering in image.
Reviewer note: this is the theoretical fix, but it won't work right now
because Cairo explicitly bypasses grayscale antialiasing when system set
subpixel one. Still let's push this first patch, but the issue will be
actually fixed when Cairo will merge my MR too:
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
(cherry picked from commit 00bbeabaf4)
XMP array tags of type BAG and SEQ can have multiple values, each of
which is on a separate line. However, we were reading and saving it as
just one value.
We change this by setting each line as a separate value with
gexiv2_metadata_set_tag_multiple.
In addition to that we found that setting the type of tag struct with
gexiv2_metadata_set_xmp_tag_struct caused arrays of multiple values per
tag to be set incorrectly: the last value in the list got added multiple
times. I'm not sure if we are using this function incorrectly, or that
there is a bug in gexiv2 or exiv2. Anyway, since it seems that all tags
and values I tested work without calling this function, let's just omit
this call.
(cherry picked from commit a4cb134f14)
XMP array tags of type BAG and SEQ can have multiple values, each of these
values needs to be on a separate line to be correctly recognized as a
different value in the tag array. We were incorrectly loading all values
on one line separated by a comma.
For those tags that have equivalent IPTC tags we were also comparing just
the one XMP value with the whole, possibly multiple lines, of the same
IPTC, which could cause a failure to recognize identical tags.
We changed this to now have each value in a tag array on a separate line
by adding \n between values.
Each IPTC equivalent tag value is now compared to each value in the XMP
tag array and only added when a different value is found.
(cherry picked from commit 76dc649b3f)
XMP tags that have multiple values (usually of type XMpBag or XmpSeq) were
shown on one line. Which, especially for long text values, could make it
difficult to see the separate values for that tag.
Let's do the same as we do for IPTC tags that can occur multiple times and
show each value on a separate line.
(cherry picked from commit baaa1380cf)
In the metadata-viewer refactor the code that adds multiple values per tag
to the list store into a separate function.
Currently used for IPTC tags only but the intention is to reuse it for
XMP tags with multiple values.
(cherry picked from commit e9ab89fa4f)
# Conflicts:
# plug-ins/metadata/metadata-viewer.c
When saving XMP metadata were using gexiv2_metadata_get_tag_string for all
tags, even those that can have multiple values. This caused those values
to be saved as one value instead of multiple.
To fix this we use gexiv2_metadata_get_tag_multiple, except for XmpText.
Then we add all returned values for that tag separately to our metadata.
(cherry picked from commit af888e481f)
- Update last-active parameter to 3.0 for various people.
- Add Liam Quin, lillolollo, Stanislav Grinkov, Povilas Kanapickas and
woob.
- Move myself to maintainer.
(cherry picked from commit 0645bf6f0f)
Adding names of people with significant contributions:
- Jacob Boerema for his awesome work (on too much stuff to list it all!)
- Daniel Novomesky (HEIF, AVIF support)
- Félix Piédallu (meson build)
- Elad Shahar (Python 3 plug-ins, Spyrogimp, Mandala symmetry
kaleidoscope mode)
(cherry picked from commit 9fc87b8d91)
Thanks to the unit test comparing the available translations (based on
po files) and the configuration for InnoSetup, as well as the build
configuration, it's now easier to make sure we are always in sync.
We were only comparing the po list with the language list in the
gimp3264.iss. Nevertheless since we also generate the <code>.setup.isl
files, we should also verify generated files corresponds exactly to the
same list of languages.
This commit does it for meson and autotools build.
This is also how I fixed the meson list (cf. previous commit).
(cherry picked from commit 602add8c45
except that I removed the comparison with meson files)
This way, we will avoid in the future any discrepancies between
languages set in the Windows installer and available translations (po
files in po-windows-installer/) because `make check` will fail.
(cherry picked from commit 8a42c6ccc2
apart from the removed meson file)
If you first open a multi page TIFF, exiv2 generates EXIF tags for the
first 3 pages in the form of Exif.Image.<tags>, Exif.Image2.<tags>,
Exif.Image3.<tags>. When exporting with EXIF saving enabled, exiv2 thinks
it needs to save TIFF pages for the EXIF metadata of the second and third
page too. Those pages saved by exiv2 contain only metadata no real image
data and give warnings when loading.
The EXIF tags read from page 2 and 3 are only the basic image specs. We
don't use those, nor do we add tags to it. Until we support handling of
metadata for those pages and exiv2 has better support for all TIFF pages
beyond the first few, I see no reason to save this information.
So for now lets just delete all tags that start with Exif.Image followed
by a number.
On Windows there is a long standing issue in its File Explorer. When
GIMP exported as a multi page (multi-layer) TIFF with thumbnail saving
enabled, then the Windows thumbnailer apparently gets stuck and does not
close the TIFF file when browsing a folder. Because those files are not
closed it is impossible to delete them. This issue has been reported
many times over the years to Microsoft without any reaction.
Investigation showed us that this lock up only happens when we save the
thumbnail as a subifd. To resolve this issue we change this and now let
exiv2 handle our thumbnail saving, just as for other image formats. For
TIFF this means the thumbnail is saved as the second page of a TIFF.
Previous commits have made sure that it is now easier to recognize a TIFF
page as a thumbnail and to make sure we don't load thumbnail TIFF pages.
Since saving as a subifd is what made TIFF thumbnail saving different
from other formats, this commit consists of only removal of code.
(cherry picked from commit 42e61104d7)
# Conflicts:
# plug-ins/file-tiff/file-tiff-save.c
TIFF image pages can specify what type of image that page represents.
If the page is marked as FILETYPE_REDUCEDIMAGE we will consider it to be
a thumbnail and filter that out of the list of pages that can be selected
to be loaded.
In addition to that we will try to recognize certain pages as thumbnail
that don't have the subfiletype tag set.
We will consider it a thumbnail if:
- It's the second page
- PhotometricInterpretation is YCbCr
- Compression is old style jpeg
- First page uses a different compression or PhotometricInterpretation
If these conditions are true the page will also be filtered out.
We could consider having an option whether to filter out thumbnail pages.
Since in the situation up until now we also don't load thumbnails, I think
this should be considered as a separate feature.
(cherry picked from commit 2a38ec9e4b)
We can see we are really working towards stability and consolidation
now, with few new features, but a lot of bug fixes.
(cherry picked from commit f04e7442f4)
By default, when on "auto", the update check feature will be set
depending on the OS. In particular, on Windows and macOS, it will be ON,
because these are the 2 OSes which we distribute without an update
channel, hence where people used to have very outdated versions of GIMP.
On Linux, *BSD, and so on, distribution provide updates through package
repositories.
(cherry picked from commit 0e46fadf43)
This fixes a memory leak as reported by Massimo.
But even more, we fix the code logics, as the cleanup items were never
added to the `item_cleanups` list.
(cherry picked from commit ee09ae7245)
As noted in issue #6032 the error message when trying to open a pattern
file with dimension larger than supported could be a little clearer.
We do this by adding the maximum allowed dimensions to the error message.
(cherry picked from commit 317b5d9cff)
For GIMP patterns we have maximum allowed dimensions which we check when
loading a pattern. However, we did not check this when saving a pattern.
See issue #6032.
This commit adds a check when saving a pattern and adds a descriptive
error to make clear why saving fails.
(cherry picked from commit f130fe1917)
On Windows loading metadata from images with non ASCII characters in their
path failed. Part of the fix is in gexiv2 that now converts the path from
utf-8 to utf-16 on Windows.
However we were still sending a localized path to gexiv2 where it was
expecting utf-8. This caused the conversion and thus loading of metadata
to fail. Fix is to remove the special handling for Windows and use the
utf-8 filename.
(cherry picked from commit 65950de735)
Due to differences between Windows and most other platforms Ghostscript
didn't correctly load files with special characters on Windows.
First we needed to make sure that the filenames we use are in utf-8
format and then tell gsapi that we use utf8 encoding.
(cherry picked from commit 4f86d8088d)
# Conflicts:
# plug-ins/common/file-ps.c
When exporting a C source file with runtime length encoding, the
C-string's array size does not accomodate for the null byte. However,
GIMP accomodates for the NULL byte in it's NON-RLE export, suggesting
that this has been a mere oversight for RLE.
This can cause at the worst a compile-time error and at least a warning
from the compiler.
(cherry picked from commit 4d528f297f)
I somewhat bisected GEGL commits between 0.4.20 and 0.4.24 and found
that the one that introduced the env var GEGL_OPERATION_INIT_OUTPUT is
the first showing the problem.
Reviewer (Jehan) note: so it would be commit 6e9610e65c on GEGL repo.
This fix makes sense as it means that since this commit, the output
buffer could have random values. It's not a problem for any operation
where we fill every value, but I guess it's not the case for
"gimp:cage-coef-calc" which was likely relying on the old behavior of
being 0-initialized.
(cherry picked from commit 3b2a8f79f0)
Reviewer comment (Jehan): we have used this patch successfully on our
installers since start of 2021 (see commit b4d665d of our gtk-osx fork)
and it really improved the situation. I only fixed minor coding style
stuff in the patch.
Looking at what it does, I guess it is not ideal long-term if related to
10-bit display (as I understand from the comment), which a graphics app
would want to support properly. But for now, this is better than
extra-slow display until we get macOS developers able to look at this
more in depth in the future (I don't think that our dependencies are
really ready yet for 10-bit display support anyway, though I may be
wrong).
Some other forums seem to say it comes from macOS invalidating now more
than it should (i.e. the whole area instead of only the changed area)
and this NSViewUsesAutomaticLayerBackingStores flag would disable this
behavior. It might be one of these reasons, the other or both. This is
anyway a good first start for future contributors.
(cherry picked from commit 4f9b7373e6)
g_alloca() is unadvised. Even though it might be more efficient in some
specific cases, it is pretty subject to stack overflow when a lot of
memory is requested.
Let's allocate dynamic memory instead. To avoid doing it too much, let's
just reuse the same pointer especially since region of interest will
usually be the same size when iterating a buffer, except for border
ones (which would usually be smaller, so we can use the same allocated
buffer again). I still make size checks, just in case.
(cherry picked from commit f2fb98cb69)
For 1-bit BMP export we did not show the save dialog, making it
impossible to change settings interactively.
We enable the save dialog for 1-bit too, making sure to disable RLE, which
is not available for 1-bit.
On most keyboards the [ and ] keys are shared with { and }. Which means
that if you press Shift+[ you get {. We were using this key combination
to increase the tool's size by 10 and the other to decrease it by 10.
However, on all keyboards where these keys share the same physical spot
on the keyboard, this wasn't working.
So, let's change the actual keys to do this to { and }.
(cherry picked from commit 42fe8abc98)
Our plug-in was not correctly handling DICOM images that use big endian
transfer syntax, which is deprecated.
We add support for that here, add a few g_debug statements to make future
debugging easier, and also return an error when we encounter a transfer
syntax that we can't handle instead of blindly continuing.
(cherry picked from commit e0707af073)
# Conflicts:
# plug-ins/common/file-dicom.c
Part 1 of the fix for #1146.
In addition to that we also add some g_debug statements to make it easier
to determine certain image info.
(cherry picked from commit 3733a36d84)
… source colors
Reviewer's (Jehan) note: a git blame shows this is a clear bug
introduced in commit 9d19bf2a3e, which was a cleanup patch, and the
BOUNDS() macro was not doing exactly the same thing as the code before
the change.
(cherry picked from commit 3b3f34cd22)
The markdown triple-quote (```) has to be on its own at the start of a
newline. Schumaml was telling me that too many reporters would paste
just after some text, which would therefore break the markdown syntax.
Instead let's add 3 newlines before the triple-quote, so that even
people who would not hit the "Copy Bug Information" button (but instead
select and copy) have a hint that these newlines are made on purpose.
Also add a comment (which is discarded by Gitlab) to make this even more
obvious.
Then even when pasting just after some text on the same line, the
triple-quote will end up on its own line.
(cherry picked from commit d3105e5c72)
… the container.
There was this weird case which we somehow could only reproduce on
Aryeom's computer/build, not mine, with the same code and reproduction
steps (reproducible at will on her build only). Basically when drag'n
dropping a duplicated layer inside a collapsed layer group, the
row-expanded handler would try to select the moved layer before it is
actually inserted. This would end up into crash-happy code.
I'm still unsure of why the order of operation is different here, but
anyway what is for sure is that the `inserting_item` boolean flag was
not protecting much. It's not like it's an actual mutex and anyway this
is not multi-threaded code either so this flag was mostly useless (which
is why we were crashing). Instead let's actually look if the item is in
the container or not.
GIF export was not taking into account that there can be
both grayscale layers with and without alpha in an image.
We make sure that the GEGL buffer knows the type of
drawable for the current layer.
(cherry picked from commit 3b3ab0aa11)
# Conflicts:
# plug-ins/common/file-gif-save.c
Similar to previous plug-in but only for autotools. Separated in its own
commit for easy cherry-picking to `gimp-2-10` branch.
(cherry picked from commit a4a6ac59e0)
Exporting to psd could result in very large files which often failed to
load in both GIMP and PS when a group layer with a layer mask
was present.
Reported on our IRC channel with a sample xcf which made it
possible to figure out the problem.
(cherry picked from commit 8fdeaddbe7)
So far all dds images were loaded as 8 bit per channel which makes
sense for most but not all dds formats.
This commit implements loading in 16 bit for "L16" - a 16 bit
luminance channel.
In addition to that we improve security a bit by not assuming
that L16 is the only left over case but instead explicitly
checking the correct value of rmask for L16.
For other cases we now set an error with enough details
to identify the type of DDS image that needs extra
handling.
(cherry picked from commit fe228a6f6f)
# Conflicts:
# plug-ins/file-dds/ddsread.c
Let's increase the default size of the metadata viewer a bit.
Ideally we would add some logic to determine the width of
the first column since that one currently depends on the
length of the longest tag. However for now this change
will be enough for most cases.
(cherry picked from commit 165b50abcc)
The round corners script was assuming that the drawable always
was a layer, which is incorrect when a layer mask is selected.
We fix this by always requesting the active layer instead of
active drawable.
We also enable this script for RGB and GRAY with alpha
channel. Although it might not always make sense to
use this script when an alpha channel is present, there
can be use cases where it is perfectly fine.
So let the designer decide if this script is suited or not
instead of GIMP making that judgement.
(cherry picked from commit ed35579861)
# Conflicts:
# plug-ins/script-fu/scripts/round-corners.scm
Closes: GNOME/gimp#541
Reviewer note: thanks to Stanislav Grinkov for cleaning up and reworking
a bit the patch, such as renaming the procedure to dir-make, as per
Kevin Cozens' review.
(cherry picked from commit 11906fa82c)
Removing useless condition, add a g_return_if_fail() assertion for the
only (impossible unless bug) case which we don't expect. Also set
default mindist to G_MAXLONG instead of a magic number (which was ok now
but might become a problem if some day colormap allowed more than 16-bit
per channel colors).
Finally break when we reach a distance of 0 since we won't get lower
anyway, so better stop early.
Thanks to Rafał Mikrut and Øyvind Kolås for code commenting.
(cherry picked from commit d6dac25579)
We cannot just compare the drawable format with the model-type specs of
the color model. We need to include the space now.
In my case, some random screenshot converted to gray then indexed would
assert because the format is "Y' u8-space-gray-sRGB" (or for layers with
alpha: "Y'A u8-space-gray-sRGB"), hence indexed conversion failed and
ended up dark.
(cherry picked from commit c0e605ef96)
Looking at the documentation it is indeed red that should go
in the lowest bits and blue in the highest bits so just
reverse our code for red and blue.
We also update the version of our GIMP DDS plug-in,
this way we can catch and correct RGB10A2 images
written by older versions of our plug-in and correct
them.
(cherry picked from commit cad6273fed)
# Conflicts:
# plug-ins/file-dds/dds.h
With my previous commit, I improved the search action display and search
algorithm (which was returning wrong results), but we had lost showing
the non-sensitive reason in menu item tooltips. This fixes it, by
actually appending the reason, but only in the end, on the GtkWidget
tooltip (not in the action's tooltip itself).
(cherry picked from commit 13a02aea23)
Fixes:
> Calling error for procedure 'gimp-brush-get-pixels':
> Brush 'Circle (03)' not found
The data/brushes/Circle-3.vbr brush doesn't exist since commit
7aa12175a4 in 2012 as far as I can see.
(cherry picked from commit 65e10faf50)
… to GIMP not text layer rendering in image
Patch was merged n Cairo today, wouhou!
https://gitlab.freedesktop.org/cairo/cairo/-/merge_requests/114
If not mistaken, the fix should then appear in Cairo 1.17.6 or 1.18.0
(whatever comes next). As we are obviously not going to bump the Cairo
dependency so early, let's just add the patch, at the very least to be
used for our official builds. Also this way, we won't forget about this
issue in the future when we need to bump Cairo.
(cherry picked from commit 5f61d84570)
This is the same as what we did for #5357
but in the reverse situation. The reason
for not doing the same at that time was
because I wasn't sure if that was valid
in all cases.
Looking at the documentation it does seem
to be the right solution and is working for
the supplied example image.
(cherry picked from commit 48ff5313c3)
# Conflicts:
# plug-ins/file-dds/ddsread.c
… Cintiq 16).
Adding the patch provided by Knuckx. Note that the GTK3 variant of the
patch is already merged to gtk-3-24 branch and published since GTK
3.24.28. Nevertheless since the contributor also provided a GTK2
variant, it would be a bit of a waste to let it go down the drain,
wouldn't it?
So let's try and use it in our GIMP 2.10.x packages for Windows.
This is a patch for issue #913, the infamous "non-existent floppy drive"
or other unreachable network or unmounted drives. Well at least it
*should* fix the issue, but GLib developers are hoping we could test. So
let's add this in there for our next Windows package.
(cherry picked from commit 7e2a0238a2)
Removing this check makes the treatment of LittleCMS consistent with
all the other dependencies checked in the same file, which only check
that the runtime version is at least the required version.
As long as we were compiled against LittleCMS >= 2.8, and are now
running against a version that has at least the same symbols, it doesn't
necessarily matter whether the version we are running against is the
same one we were compiled against.
Distributions like Debian and Ubuntu track the versions in which
individual symbols were introduced, which allows runtime dependencies
to be weakened when no newer symbols are actually used; this is
practically necessary when working with very large numbers of packages,
to avoid a new version of a dependency library unnecessarily blocking
upgrade of dependent packages. However, this doesn't work if dependent
packages add their own checks that bypass this mechanism.
Signed-off-by: Simon McVittie <smcv@debian.org>
(cherry picked from commit dda65d85c3)
Also ".sun" is a possible (and common) file name extension for Sun
Raster images, according to various sources and samples I found (these
samples with .sun extension also opened fine in GIMP, so it's not just a
subvariant which we may not handle or something of the sort). This one
is not so important though as we also register magic bytes for detection
(which is the proper way), but it can still be useful, mostly for
exporting (as we will direct to the SunRaster plug-in if someone tried
to export a file with .sun extension, since no other file format uses
this extension AFAICS).
There is no functional change, I just had a look at this plug-in while
handling !428 and realized this format was not present in the MimeType
list (which is used to generate the desktop file, in order to have
proper mime types, not detection based on extension only, unlike
Windows in !428).
(cherry picked from commit cd3333c6d3)
Nowadays .rs is the extension for the Rust programming language files,
and it's confusing that GIMP is trying to associate with them.
A simple rename of existing .rs images to .ras will allow them to be
opened again.
Note by reviewer: ideally file association should not rely on filename
extension, and should be detected properly (i.e. file "magic"). This way
even extension clash would not be a problem (format would be detected
whatever the extension used). Unfortunately it's apparently not the case
on Windows.
Anyway since nowadays chances to see a Rust code file are likely much
higher than seeing a Sun Raster image file, let's just accept this patch
and drop association of `.rs` on Windows.
(cherry picked from commit 809e045ead)
Fix again these warnings:
> cast from pointer to integer of different size
(cherry picked from commit 2c6e21b1e7)
Note: the absence of this made script-fu crash on Windows 64-bit. See
issue #6664. Why this suddenly appeared and never happened before GIMP
2.10.24 is a big mystery.
… there are no such data available.
No need to have people test and wonder what it changes when it makes no
difference. Also adding a tooltip to make the "present on import"
condition a bit more obvious (hopefully).
This is only on `gimp-2-10` for now, for the 2.10.24 release. I will
port this to `master` branch later.
Contents of these arrays are assumed to be limited to a specific range.
While it did work sometimes (because a further processing would randomly
regenerate some of the indexes and correctly limit the range), it often
crashed.
This commit fixes the crash, but I am not sure this plug-in is working
exactly as expected regarding data load/save. It feels like you would
expect to always get the same patterns with a same source data. Yet
there is further randomization going on.
Oppositely when saving data, and re-loading it later, I would expect
once again to get back the exact same patterns I had when saving the
data. So it would be a way to save the result of randomization (as
chances to get back a pattern one liked are slim by definition when it's
created randomly).
Right now, it doesn't behave at all like this. Files are only used as
some kind of random seed, not as a way to save/load patterns. I feel
this was not the purpose of the file handling here.
(cherry picked from commit 7fb696206e)
Note that I marked the news as releasing on the 29th though the release
is marked for 28th, because we never manage to release the web news on
the same day, and usually we wait for the Windows and/or macOS
installers at least.
The saved value for Iptc.Application2.Caption is copied from Xmp.dc.description.
However the last one is multiline but the former should be single line. This
caused only the first line to be saved instead of all lines.
To fix this we set Iptc.Application2.Caption to single and use a different
conversion based on whether the tags from Xmp and Iptc are both
multiline or whether Iptc is single line.
(cherry picked from commit 5d14c59d2e)
While testing the metadata-editor I noticed that certain values for
ModelReleaseStatus and PropertyReleaseStatus were incorrectly
read back.
Apparently while copy pasting some values were forgotten to be
updated which caused incorrect values to be saved.
There probably are not many users of these metadata tags
since in all these years there hasn't been a bug report about this.
(cherry picked from commit 93f591931b)
The metadata-editor allowed Iptc tags to be set if an empty string was
used contrary to Xmp tags. In the case of DateCreated this cause an
invalid date "0-00-00" to be written.
We added a check to only write text Iptc metadata if the value is
not empty.
(cherry picked from commit 0a902456ac)
Fixes issue #3656 Empty metadata tags are written to XCF at least.
Xmp.plus.ModelReleaseStatus and Xmp.iptcExt.DigitalSourceType are
defined as combo boxes with a fixed number of possible values.
However there was no option to leave it empty so there always was
a value written when saving metadata in the metadata-editor.
We added a "select value" as default option and only write
metadata if a different value was chosen.
As a bonus we replaced the fixed loop numbers with
the current actual number of defined choices.
(cherry picked from commit a229454915)
Since version 0.27.3 exiv2 has changed how it returns
comments for Exif.Photo.UserComment. We now get
the comment including the charset=Ascii value.
Let's remove anything that's not part of the actual
comment. To not complicate things we will only
handle charset=Ascii for now since I've never seen
any other charset used.
(cherry picked from commit 352b5885b1)
# Conflicts:
# libgimp/gimpimagemetadata.c
1. Convert xmp /Iptc4xmpExt tag parts to /iptcExt because
exiv2 fails when we try to use the default namespace.
2. Don't only set structs from a fixed list but find all
xmp array elements and check what the best struct
type is: bag or seq.
3. Work around a sorting issue in (g)exiv2 by using a natural
sorting algorithm ourselves.
4. Added some g_debug statements to make it easier to
determine the cause of issues.
We need to work around an issue in Exiv2 that saving to /Iptc4xmpExt bag
records fails which seems related to it registering /iptcExt. Unregistering
that and registering the first one doesn't work.
See: https://gitlab.gnome.org/GNOME/gexiv2/-/issues/24
So let's use /iptcExt for saving even though it's the less common form
for now. When loading metadata we try to load the most common
form first and if that fails we will load /iptcExt.
(cherry picked from commit a95371c2b0)
Set Xmp.iptc.CreatorContactInfo/Iptc4xmpCore:* last since the short
form Xmp.iptc.Ci* could have been used to set this information too.
Becausethe first (longer) form is the most common let that override the
shorter form in the (unlikely) case that both are present and also have
different values.
Due to a bug in the metadata-editor previously only the short form
was saved.
(cherry picked from commit d00fe2bfe2)
Reordered the strings in artworkorobject to be in the same
order as the columns.
Add write_metadata_tag_multiple function that handles most
of the previously duplicated code and check for special
handling of phonetype when necessary by adding
an enum and a get_phonetype function.
(cherry picked from commit 4609def72f)
Use a separate function that can be reused and also get rid of
the large output_data array and strcat without length
checking. We will use GString instead.
(cherry picked from commit 9c2451d813)
This removes some flawfinder warnings by not using a fixed
size array and using g_snprintf instead of g_sprintf and
using more safety checks.
(cherry picked from commit c2fa21ac7d)
There was a lot of duplicate code based on
whether or not value was NULL with for
some tags partially unreachable code.
We combine the parts and only test
value for NULL where needed.
Also rename the typos in enum
COL_REGSITRY_* to
COL_REGISTRY_*
(cherry picked from commit 0a0eeac1ad)
There's a lot of duplicate code for adding string values
to the gui (liststore). This is another part of trying
to reduce that.
Besides that the copying code uses fixed size arrays
without length checking as pointed out by flawfinder.
We will instead use a function add_to_store to add a
comma or semicolon separated list of values stored in
value to add rows with values to the gui.
(cherry picked from commit e24a6dc8d6)
Crop tool used stale color / pattern values when performed crop with
'Allow growing' option. Its context was not notified when fg/bg/pattern
value was changed.
Closes: #4103
GLib has been fixed with commit 00e848fbc.
Add it in our patch list for the Windows installer until we get a
release containing the patch.
(cherry picked from commit 106e13d5db)
Only count a broken line once and only stop after at
least 10 consecutive broken lines since older fax
images are known for having bad lines.
This enables loading the image in issues #475.
(cherry picked from commit fd2aa645af)
- Miniswhite and Minisblack TIFF images with bps 1, 2 and 4 were loaded as
indexed. We change this to grayscale since that's what they are.
- Fix not handling of miniswhite for 8 bps.
Fixes issue #1838 Tiff image display wrong (tiff tags not interpreted), black
line instead of white line.
Fixes issue #2680 Failure to load 4-bit grayscale TIFF layers.
(cherry picked from commit a6d4ef8b94)
# Conflicts:
# plug-ins/file-tiff/file-tiff-load.c
Without the proper button response associated, we don't have the right
button order, as standardized by various desktops.
(cherry picked from commit 9893f60d8c)
Improved and added a few error messages and made all
user visible messages (g_message) translatable.
(cherry picked from commit 20cedd4c0c)
# Conflicts:
# plug-ins/file-tiff/file-tiff-load.c
Testing some fuzzed TIFF images from the imagetestsuite
revealed we should add some more checks for valid input
and function returns.
We now stop whenever the reported bps is above 64.
Even if it is valid we can't handle it anyway and I'm not
aware of any actual valid image like that.
Make sure the image dimensions are valid and in the range
that GIMP can handle.
Return directly when TIFFReadRGBAImage fails instead
of doing further processing and improve the error message.
Check result of TIFFReadTile and return if it fails.
(cherry picked from commit 2ff9ccf46c)
Certain broken tiff fax images can cause a huge amount of warnings
which on Windows eventually causes GIMP to run out of resources
and then crash.
Since the avarage user won't have much use for these warnings
let's just only send them to stderr.
(cherry picked from commit 97739af643)
Check at runtime for the operation availability and set the "Show Image
Graph" action active depending on this check.
This goes with discussions to make this operation optional with a
runtime check for the tool `dot`.
See: https://gitlab.gnome.org/GNOME/gegl/-/merge_requests/84
Was caused by widget tool fixed_center_x and fixed_center_y coordinates set to
coordinates of mouse click instead of rectangle center after converting channel
selection bbox to rectangle.
Now rectangle fixed_center_x and fixed_center_y coordinates are always updated
when tool widget x1, x2, y1, or y2 coordinates are updated.
Closes #6487
(cherry picked from commit 6959426603)
The Lua API is undergoing changes in darktable master. I've fixed the lua-scripts repository as I've made
changes, but I forgot about the collateral damage.
Attached is a fixed version of file-darktable-export-on-exit.lua which should be good for darktable 3.6 and
beyond.
Fixes #6421
(cherry picked from commit 636eb02edc)
This commit also makes snap to grid and snap to vectors work off-canvas.
Since we now have off-canvas viewing, it just makes sense that snapping
would work there too.
Note that I disable snap to grid when "Show All" is OFF. I am actually
unsure this is right (as "Show All" is a view action, and we usually
don't change behavior based on view actions; for instance snap to guides
are not disabled if guides are hidden). Yet I noticed we do this in
various other features when off-canvas. We kind of use this view flag as
a switch for features working off-canvas (for instance, color picking
works off-canvas only when "Show All" is ON). So let's keep the same
logics for now at least.
Snap to guide or snap to vectors will always work though, because guides
and vectors are always visible off-canvas (even when "Show All" is OFF).
They always have been (visible, not snappable off-canvas; now they are
both).
(cherry picked from commit 82438728fb)
If the interp file contains CRLF, the \r is read as part of the
executable file name, and gimp searches for python3.exe\r.
(cherry picked from commit b134da1f39)
This commit fixes the issue when requested page width/height was
not honored because DPI resolution value was constrained to whole
integer numbers only.
XMP metadata saved by GIMP 2.8.x or earlier can have duplicate tags
making the XMP data invalid. There's not much we can do without a
whole lot of processing and complicated code and even then no
guarantee we would catch everything.
Instead let's just try to improve the message to the user so they
will be more likely to understand what's going on.
(cherry picked from commit 6df6332f9b)
Although I haven't been able to reproduce it, it is apparently
possible to get a Stack Overflow when loading xcf files with
presumably very large dimensions on Windows. From what
I'm reading Windows normally has a smaller stack size than
Linux, probably why it hasn't surfaced there.
Instead of allocating on the stack let's do a g_malloc0
combined with g_free.
(cherry picked from commit 6b65998bf7)
Argh I should have properly reviewed !392 (commit c264f0b705).
It was leaking the return value of a g_path_get_basename().
(cherry picked from commit 1873f0d65c)
darktable GUI is "mangled" when opened from GIMP for a reporter. There
was already some debug info outputted (when running with DARKTABLE_DEBUG
environment variable). Adding the environment list (and some separation
titles to make it easier to distinguish what is what). Hopefully it will
help debugging.
See #6195 and https://github.com/darktable-org/darktable/issues/7402
(cherry picked from commit 7465b0782a)
We were not handling all possible record sizes for mask info and
in case it was an unknown size we set everything to 0 instead
of reading the parts we do recognize.
Let's make it more flexible by reading the parts we do know
about and skip the remaining data if any.
Also added a few more g_debug statements to make it
easier to check some values when needed.
(cherry picked from commit 83ab86eb8b)
When testing for the presence of extra channels we were not taking into
account all values of TIFFTAG_PHOTOMETRIC causing incorrect messages
that we had a non conformant TIFF without ExtraSamples field.
Since the same test is used twice I separated the code into a new function
and also added another related function to have similar code grouped
together for easier maintenance.
(cherry picked from commit f489976b05)
GIMP was exporting certain BMP images with 1, 4, 8 and 24 bpp
with an incorrectly set value of BI_BITFIELDS for compression,
see issue #6144.
According to the specification this is not supported but testing
shows that many image viewers and editors load these
images correctly.
Since allowing these unsupported values for bpp does not
seem to have any negative side effects and is easy to
implement let's add this.
(cherry picked from commit e55e078245)
The Microsoft specification for BITMAPV5HEADER says that
BI_BITFIELDS is valid for 16 and 32-bits per pixel, but we
were also using this flag for other values of bpp when
no rle compression was used.
Since this specification doesn't mention 24 bpp or other
values use BI_RGB instead.
(cherry picked from commit d8c164ced3)
Information in issue #6200 revealed that 0 as default value for
the blue channel is a lot more common than 255 so let's use
that instead. The discussion and testing revealed no negative
effects for the other formats that use the same code to
initialize the memory to read blocks of image data.
(cherry picked from commit 691548579a)
Since older versions of our GIMP dds file exporter incorrectly
saved BC5 dds images with the red and green channels
swapped we should fix that. Since the exporter already
wrote the plug-ins version number and that it is written by
GIMP we can check for these incorrect images.
To enable that we increase the plug-ins revision in this
commit and swap red and green channels for images
that have an older version number and are of the
correct type.
(cherry picked from commit a4cc8b7070)
# Conflicts:
# plug-ins/file-dds/dds.h
When the "Omit hidden layers and layers with zero opacity" option is
set, this property was only checked on non-group layers. So if we had
non-hidden layers inside hidden layer groups, they ended up exported,
which is not the expected behavior.
See https://gitlab.gnome.org/GNOME/gimp/issues/4425#note_675350
(cherry picked from commit 24a0b0c53a)
If we were loading multi page tif images as layers then only the tif pages
that had a color profile attached would get set as linear (and each tiff page
can have a color profile). Since most of the time only the first page has a
color profile this caused us to load linear tiff pages incorrectly.
Also we were overwriting the color profile if there was more than one since
GIMP can only load one per image. Instead of using the last one we see
use the first one and notify if we encounter more than one.
(cherry picked from commit c05abcefc6)
# Conflicts:
# plug-ins/file-tiff/file-tiff-load.c
My fix in commit 9e4aa586f7 was not enough because CLEANFILES apparently
would only be processed on Makefile.am (i.e. with automake). Just remove
the file explicitly in the distclean rule.
(cherry picked from commit dfc4ecfc4c)
Now the distcheck job fails with the following error:
> ERROR: files left in build directory after distclean:
> ./po/.intltool-merge-cache.lock
> ./po-plug-ins/.intltool-merge-cache.lock
> make[1]: *** [Makefile:1155: distcleancheck] Error 1
There is definitely some change which happened on Debian packages,
either on intltool-merge itself, or something around, because these are
behavior breakage. We never set such `.intltool-merge-cache.lock` lock
files ourselves, so obviously we should not be the ones to clean these.
This is only a workaround which should be removed once upstream fixed
the issue.
(cherry picked from commit 9e4aa586f7)
We have a sudden CI failure which is maybe because of a change of
intltool-merge. We believe it might be because of a missing directory.
Let's test making it before running the command.
Fixes:
> /usr/bin/intltool-merge ../../../po-tags
> ../../../data/tags/gimp-tags-default.xml.in gimp-tags-default.xml -x -u
> -c ../../po-tags/.intltool-merge-cache
> No such file or directory at /usr/bin/intltool-merge line 396.
(cherry picked from commit 845f1c81ed)
This fixes issue #6065 and part of #2680.
Sometime after GIMP 2.8 loading of 2 and 4 bit tif images,
both grayscale and indexed, got broken.
I added routines for handling 2 and 4 bit tifs based on
the handling of 1 bit images.
(cherry picked from commit 991e99f08a)
By using a logging domain we can filter the messages and can choose to
only see them when needed. They seem to be leftovers from coding or
debugging but I don't wanna invest too much time into this.
(cherry picked from commit 08afb7d03b)
metadata-editor and metadata-viewer did return GIMP_PDB_SUCCESS when
loading the dialog ui failed, we changed this to GIMP_PDB_EXECUTION_ERROR
and now use a GError to report it back to GIMP.
In metadata-editor also improve the error handling when loading the calendar
dialog fails.
The error also only showed in the console so change that to show a dialog
or the error console.
(cherry picked from commit 0ffee001bf)
# Conflicts:
# plug-ins/metadata/metadata-editor.c
# plug-ins/metadata/metadata-viewer.c
The string parsing for gps longitude/latitude was not taking all
possible values into account and also the seconds part was
not saved with enough detail.
For altitude lets also increase the detail a bit from .1m to
.10m.
(cherry picked from commit 3d9a9fbbf3)
# Conflicts:
# plug-ins/metadata/metadata-editor.c
By using g_log with G_LOG_LEVEL_MESSAGE and empty domain
name we make sure the failure to write a tag will be seen by
the user in GIMP's user interface (error console or error
dialog).
(cherry picked from commit c4fa4fcda0)
Adding metadata-tags to Makefile.am for
the metadata-viewer since until now it was only used in
the metadata-editor.
The Exif gps metadata tags for longitude, latitude and
altitude get special handling to show them with more
precision and let the string parts be translated.
(cherry picked from commit 34407a6b7e)
# Conflicts:
# plug-ins/metadata/meson.build
# plug-ins/metadata/metadata-viewer.c
The abbreviations M for meter and FT for foot/feet were written in uppercase.
However the offical abbreviations are lowercase so let's just follow that and
make them lowercase here too.
Above and Below Sea Level were using camel case with every word starting
with an uppercase letter and were used on the label of a combobox option
for gps altitude reference. Using standard casing with only the first word
using a capital seems better in this case.
a capital
(cherry picked from commit 23fa5c7ef7)
Saving of longitude and latitude was duplicating the same code,
except that in latitude it forgot to free some strings.
Let's move this code into it's own function to make it easier to
improve it.
(cherry picked from commit aa2027cc18)
Certain metadata is already UTF-8. Converting them from locale
to UTF-8 again leads to incorrectly shown strings.
(cherry picked from commit 3128047a0b)
The values of Description tab - Copyright Status and IPTC tab - Urgency were not saved.
We are fixing that with this commit. Urgency is also saved to Iptc.Application2.Urgency.
(cherry picked from commit d004305019)
Iptc equivalent tags of Xmp tags were only read if the Xmp tag had no value
which doesn't make sense since there is no guarantee that they are the same.
We changed this to always read the Iptc tags too and if the value differs
from the Xmp tag we add both values. That way the user can decide
which values are relevant.
(cherry picked from commit 7cce45b377)
This is one of the problems mentioned in issue #5863. This commit fixes
this problem in the metadata-editor by using gexiv2_metadata_get_tag_multiple.
Empty string values will be skipped.
(cherry picked from commit 879b3745d2)
This is one of the problems mentioned in issue #5863. This commit only fixes
this problem in the metadata-viewer.
(cherry picked from commit 26db975a84)
# Conflicts:
# plug-ins/metadata/metadata-viewer.c
This is one of the problems mentioned in issue #5863. This commit only fixes
our loading (and saving) of this metadata.
Certain iptc tags like "Keywords" can appear multiple times. We were using
gexiv2_metadata_get_tag_string to get the value but that always returns
the first value so we replaced that by gexiv2_metadata_get_tag_multiple.
(cherry picked from commit d0f67faf29)
… fails.
My previous commit was just assuming there is one page when the libtiff
function fails. But thinking a bit more on this, there are 2 edge cases
even here:
- If the image is actually really corrupted to the point there are no
TIFF directories to read.
- If there are actually more available directories. It would be much
better if GIMP were able to salvage them from a broken file.
To handle these cases, I actually count manually the number of
directories by looping with TIFFSetDirectory() (which still works fine
on our minimal image). I use 65535 as a max value because in libtiff's
TIFFNumberOfDirectories() implementation, it says this is the max value
(even though I couldn't confirm this in the spec; there is a "Number of
Directory Entries" on 2 bytes, but this is about various fields for each
directories, not a number of directories; still anyway this is already a
huge number and since libtiff won't likely be able to handle directories
over this limit, not need to go over either).
I am also adding a test in the end so that we can output an appropriate
message if we actually failed to read any data from the TIFF (whether or
not TIFFNumberOfDirectories() succeeded, when we actually tried to read
the contents, we couldn't).
(cherry picked from commit 9a90eefe1f)
On a provided minimal 1×1px TIFF file, TIFFNumberOfDirectories() seems
to choke on some missing field and returns 0. I am not sure if the file
is actually valid or not, but let's make some kind of exception
(outputting a warning of our own when we do) by assuming there is at
least 1 page/image in the file when TIFFNumberOfDirectories() returns 0.
Other than this minimal file (which probably has no other interest than
being a test case), it could actually help salvage corrupted TIFF file
by attempting to read more data.
(cherry picked from commit 9ff0204230)
`man snprintf` clearly says (in NOTES) that when source and target
overlap, the result in undefined.
g_snprintf() conforms to the same standard hence would not get the
expected result. In my case, the result was just tzstr (e.g. "+01:00").
(cherry picked from commit 435d5ce83a)
The color space label may be a bit long (depends on profile title which
may just be anything and we don't control it), so I allow it to wrap.
The file path on the other hand would not work well with wrapping. It
already has ellipsis in center, but GTK always gives the max size it can
as a default. So if the file is even just slightly deep in the file
tree, we end up with extra-wide Image Properties dialog.
My trick is to give a sensible max size at dialog creation (25
characters max) but to disable this max size as soon as the window gets
realized, hence allowing the label to actually grow up to the contents
actual max size, were one to manually resize the window.
(cherry picked from commit 377de0a65b)
"RGB color" is not a color space, only the model. To get full color
space information, we want to display the model and associated profile
name.
Of course, the "Image Properties" dialog also has a tab displaying
details about the color profile. Still it's better if the general info
displays not too wrong label contents.
Note: when the used color profile has no name, it will show "(unnamed
profile)" which is still more informative than just the color model.
(cherry picked from commit b9ab461977)
- Set the software as `initialized` later, and in particular after all
recovered images (from crash) then all command line images were
opened. The reason is that the DBus calls have necessarily been made
after GIMP was started (typically could be images double-clicked
through GUI). We don't want them to appear before the images given in
command line (or worse, some before and some after).
- Process DBus service's data queue as a FIFO. The image requested first
will be loaded first.
- When a DBus call happens while GIMP is not initialized or restored,
switch to a timeout handler. The problem with idle handlers is that
they would be attempted too often (probably even more during startup
when no user event happens). This is good for actions we want to
happen reasonably quickly (like would be normally DBus calls), but not
when we are unsure of program availability schedule (i.e. at startup).
Here not only the handler would run a lot uselessly but it would
likely even slow the startup down by doing so. So while GIMP is not
initialized, switch to half-a-second timeout handler, then only switch
back to idle handler when we are properly initialized and GIMP is
ready to answer calls in a timely manner.
(cherry picked from commit b2649daf11)
… DBus calls.
In particular, Aryeom would start GIMP and directly double click some
image to be loaded in GIMP in the very short while when splash is
visible. Previous code would wait for the `restored` flag to be TRUE.
This was nearly it as we can actually start loading images as soon as
the 'restore' signal has passed. Yet the flag is set in the main
handler, but we actually also need the <Image> UI manager to exist,
which is created in gui_restore_after_callback() (so also a 'restore'
handler, yet after the main signal handler, i.e. after `restored` is set
to TRUE). Without this, gui_display_create() would fail with a CRITICAL,
hence file_open_with_proc_and_display() as well.
I could have tried to set the `restored` flag later, maybe with some
clever signal handling trick (and handle both the GUI and non-GUI cases,
i.e. I cannot set the flag inside gui_restore_after_callback() as it
would break the non-GUI cases). Instead I go for a simpler logics with a
new `initialized` flag which is only meant to be set once, once
everything has been loaded, i.e. once you can consider GIMP to be fully
running hence ready to process any common runtime command.
(cherry picked from commit a86ed68870)
This is very similar to commit c6063183d3 from master branch, except
that I use the legacy tagged icon because GTK+2 does not have real
symbolic icon theme support yet, which means that I would actually have
to add the icon to all themes, and also revert colors and so on. That's
just annoying so let's just use the color icon here, which will be the
same fallback for all themes (even symbolic style ones).
The icon used is the update one from:
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/src/fullcolor/legacy/software-update.svg
Also I use now the same hicolor/ theme overlay trick as in master since
commit e815c615e1 so that I don't have to duplicate the work on all
themes.
Same as for the commit in master, licensing applies.
This icon comes from the Adwaita repository and is therefore licensed
under the terms of either the GNU LGPL v3 or Creative Commons
Attribution-Share Alike 3.0 United States License. See:
https://gitlab.gnome.org/GNOME/adwaita-icon-theme/-/blob/master/COPYING
Since obj->type_data is also int anyway, multiplying by a double value
is unneeded anyway. So let's just make an integer multiplication.
Fixes the following warning:
> warning: using integer absolute value function ‘abs’ when argument is
> of floating point type ‘double’ [-Wabsolute-value]
(cherry picked from commit 7462945360)
These small glitches have bothered me for a while now, so I finally
fixed these before the dev release!
Basically there were 2 fixes:
1. use the ink extents to compute any drawn area as this is what will be
actually drawn.
2. Not only expose the drawn area of the new text, but also the one of
the previous text in order to be sure all text pixels are correctly
reset (in case the new text is smaller than previous one). I.e. we
must expose the smallest rectangle containing both previous and new
area of text.
(cherry picked from commit 3a50e52ac7)
Upcoming autoconf-2.70 exposes deficiency in configure.ac:
```
$ autoconf-2.70_beta2 && ./configure --host=x86_64-pc-linux-gnu
./configure: line 1430: 5: Bad file descriptor
checking whether is declared... ./configure: line 1432: ${+y}: bad
```
It happens because macros are called with parameters using insufficient quoting.
More details at https://lists.gnu.org/archive/html/bug-autoconf/2020-10/msg00027.html
The fix only amends `--with-linux-input`. Other cases of underquoting
will need to be handled separately.
Fix-by: Zack Weinberg
Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
(cherry picked from commit cebeb90a87)
Lossless option switch to YUV444 format when save depth is 8bit.
I would like to enable YUV444 for 10,12bit depth
in the future too, but there is issue in libheif.
After discussion with Jehan we concluded that it is better to report
these data loss messages to the user using g_message.
(cherry picked from commit f336f86f60)
We didn't check whether TIFFSetDirectory succeeded nor did
we check TIFFReadScanline for failure which can cause
unresponsiveness.
We will not try to read a tiff page if setting its directory fails
and we will stop reading a page if reading scanline fails.
(cherry picked from commit e4514567f9)
Because of Exif.Thumbnail.* tags file-tiff-save saved an invalid extra page in
exported tif images. Removing these tags fixed this for me.
(cherry picked from commit 7957653e98)
The correct tag for sub images is Exif.SubImage instead of
Exif.Image. I also added Exif.Image.InterColorProfile since
that didn't seem to get deleted when saving without
color profile.
Also added a FIXME note since most of this stuff should be
genealized for all gimpmetadata handling.
(cherry picked from commit c10bb098b4)
# Conflicts:
# plug-ins/file-tiff/file-tiff-save.c
The About dialog refreshes the release information relatively to
currently running version before being displayed. No check of the remote
JSON file is done, it only verifies whether any stored released
version/revision is not same (or even lower) than the actually running
version. Indeed existence of a stored release means that a newer version
exists at check time only. On later run, this stored information may
have become deprecated.
(cherry picked from commit 5c89099f75)
Partially based on the comments of Massimo Valentini we block all Pentax and PentaxDng
exif Preview tags from being exported. We leave finding a more flexible solution for
problematic tags to a future contributor.
(cherry picked from commit 9069d812ef)
Also taking the opportunity to change the minimum size since I
apparently counted it wrong. The size always seems to be 46
starting from psp file-version 4 up to and including the current
version 13.
(cherry picked from commit 02bad34a41)
It just says "The GIMP team" so it's kind of redundant/useless, but I
noticed that Flathub would just display an empty "Developer" section
because the tag is absent. Well at least it emphasizes the
community-developed side of GIMP.
(cherry picked from commit 257ada495f)
... and also doesn't write out all the data, if it does a "goto out" for
any reason. A leaked file descriptor can prevent a file from being
renamed or deleted on Windows.
See also #3740.
Reviewer note (Jehan): this may not be the main issue as reporters were
not writing about export failure. So there is probably another case even
when the plug-in successfully wrote the TIFF image.
(cherry picked from commit fe340c822a)
In several GeglOperation filters, it is possible to pick a color. Up to
now, it was only possible to pick a color from the active layer (the one
you run the operation on). With this change, we can also pick in Sample
merged mode, same as Color Picker tool and other color tools.
(cherry picked from commit 578c078590)
The rational: advanced users won't really care about defaults (they know
to switch this option on/off depending on situation) but maybe beginners
would be less confused to pick "what they see" on first use, rather than
picking on the active layer? Now whatever is the default won't change
anyone's daily usage of GIMP. Clearly every image and use case is
different, so both with or without sample merged are useful one time or
another (this is why the option exists). It's really about the less
surprising option for beginners, based on usage statistics.
I ran a small poll on Twitter/Reddit/Patreon/Tipeee and ended up with
numbers of 131 for switching to "Sample merged" as default and 43
against, which is about 75% in favor. So let's just switch. It makes
sense anyway.
(cherry picked from commit 578e3b0bd9)
A log error can have a NULL domain (apparently equivalent to "" default
domain, according to g_log_set_handler() docs and we even explicitly
list the NULL domain in the log_domains array in app/gimp-log.c.
Yet our log handler was not expecting such possibility and was running a
g_str_has_prefix() on NULL. Not sure why it aborted there. It might be
because outputting a new warning inside the warning handler did not go
well. Anyway this seems to fix our side of the bug #5358. The main fix
will likely be on GEGL side (UMFPACK_ERROR_out_of_memory error).
(cherry picked from commit 5fb0577768)
Make some of the bigger Preferences pages automatically scrollable if
needed. Based on my tests, this should be enough to fit on quite small
displays, at least with the default themes, even the 1366×768 reported
as too small. It should even fit in 1280×720 (in my tests, it did).
Targetting even smaller screens may be overdoing it for an image
manipulation software. We'll see if people still ask for a smaller
dialog.
(cherry picked from commit 2ec6510973)
Adding patch by Massimo Valentini (@Massimo) for what is seemingly a bug
in GTK+2.24 in Windows.
The bug does not seem to happen on GIMP 3 (according to contributor
tests), so the bug/patch is likely not relevant anymore on GTK+3. So
let's just add this patch in our official GIMP build and be done with
it.
The XPM export plugin was saving the color `None` (transparency) to the
exported image palette for all images with an alpha channel, even if the
color was not used on any pixel.
Since it's nice to have `None` as the first color on the palette, mapped
to character ' ', and it could be too wasteful to scan all pixels twice,
the approach taken was to just undo it's premature insertion.
The lossless option does not provide true lossless encoding yet, unfortunately.
We must rename the string to correctly inform users that the compression is not 100% lossless,
Technically the image gets converted from RGB to YUV420 format (which is lossy operation itself) and only afterwards the data are compressed lossless-ly.
Backported features from master:
AVIF export (when built with >= libheif 1.8.0)
High bit export
User can select save bit depth (8, 10, 12) during export
Minor fixes in import
Back-porting some of the features from master:
AVIF import (need libheif >= 1.8.0)
High bit (10/12) import
NCLX color profile import (link with lcms)
Metadata import (link with gexiv2)
This adds a blend mode for all known psp blend modes that were not
converted yet except for adjust.
I couldn't find any information about adjust and it's value of
255 suggests that it is not a normal blend mode.
(cherry picked from commit 19b261f3c6)
Reduce number of undo steps created by Spryrogimp previews.
The implementation adds a function for clearing the
incremental preview drawing that is being executed as an idle task,
and closing an undo group in case the preview left it open (which
would usually be the case).
Traditional -config scripts are awkward for cross-compilation, multilib
systems (lib/lib64), and multiarch systems like Debian; only one copy
of the -config script can be in the PATH. As a result, some OS
distributions are starting to deprecate or even remove them.
pkg-config is designed to be a replacement for traditional -config
scripts, and is cross-compilation-friendly: the PKG_CHECK_MODULES macro
looks for an architecture-specific executable like
x86_64-linux-gnu-pkg-config, which can look in an architecture-specific
search path for library metadata, before falling back to a generic
pkg-config executable.
As a bonus, pkg-config also compares version numbers correctly
(see #2454).
libwmf having pkg-config metadata seems to be a relatively new thing,
so I've kept the -config script code path too, using it if pkg-config
does not find libwmf.
Bug-Debian: https://bugs.debian.org/956183
Signed-off-by: Simon McVittie <smcv@debian.org>
(cherry picked from commit 00024db382)
Our currently registered JPEG magics was using possible fields at the
start of the file (JFIF, Exif) in 7th byte. A JPEG provided in #5584 was
starting with yet another field (apparently some Photoshop-specific
field "Photoshop 3.0.8BIM") thus magics detection failed (and since
extension was wrong, the file was sent to another plug-in, hence loading
failed).
Looking further, it looks like the 3 first bytes are actually always
common to all JPEG and are the right magics/signature for a JPEG. These
3 bytes don't seem to be used by other formats as well according to my
research, which means we should not have false positives either. So
let's switch to this magics 0XFFD8FF at byte 0.
Note: same as commit 47a68dc871 on master but on old 2.10 API.
It looks like GDK motion hints are broken, at least on X, causing
us to drop motion events in GimpSpinScale, if the motion triggers
an operation that blocks the main thread for a significant amount
of time, such as projection invalidation.
Instead, disable motion hints for spin-scales, and use an idle to
perform ad-hoc motion compression.
Starting from psp file version 4 the specification recommends to always use the
block/chunk length to determine the next part of the image. This way it is
possible to skip parts you don't know or don't care about or additions in
newer versions.
This change makes sure to always do this which fixes reading several images
which crashed the plug-in before.
Also only try to read layer data if it is a raster layer.
(cherry picked from commit 15ad952)
Additionally to loading the default fontconfig configuration file, GIMP
also looks up /etc/gimp/<version>/fonts.conf and
$XDG_CONFIG_HOME/GIMP/<version>/fonts.conf (or equivalent in other
OSes). If these don't exist (which is the most common case), this is not
considered a bug. Fontconfig had a regression bug of
FcConfigParseAndLoad() in 2.13.92, which was fixed in a later commit:
fcada52291
As a consequence of this bug, font loading failed in Windows when these
non-mandatory files were absent.
The current commit, originally proposed by Jacob Boerema (@Wormnest) and
slightly reviewed works around the issue, because anyway there is never
any reason why failing to load these files should break font loading as
a general rule. Even if these files exist and are broken (wrong syntax
or whatnot), we should just output some warning on stderr and continue
loading without these additional confs.
With fontconfig 2.13.92, warnings will be also outputted (wrongly), but
at least it won't block loading anymore.
Also let's unref() the `config` object even when the whole font loading
succeeds. Man of FcConfigSetCurrent() clearly says that the reference
count of config is incremented since 2.12.0 (our current minimum
fontconfig is 2.12.4) so let's not leak one reference.
(cherry picked from commit c5f9b8e190)
According to the PSP specifications "Each scanline in the image data is stored on a 4 byte boundary. "
Based on all actual images I've seen this is incorrect. Possibly it is a leftover from an older specification.
(cherry picked from commit f4088adefa)
I don't add this at the end of the distcheck job to make the interface
clearer, and also because the distcheck job will have full build
artifacts (allowing to debug a failing distcheck if necessary), whereas
the `sources` job will just publish tarballs and SHA256 sums generated
from these tarballs. Simple, clean.
This will make Python plug-in available for the main build step.
Also it should make the distcheck step shorter, hence hopefully will
prevent it from timing out so often.
Looking further at this widget, many things are not right. Here are the
changes:
- Use binary prefixes (i.e. kibibyte, mebibyte and gibibyte) instead of
decimal ones. We are making binary shifts so we were actually showing
the wrong units.
- Round the value to the closest integer when showing it, not towards 0.
Otherwise I had cases where it was showing 7GiB for an actual value of
7.69GiB (default as computed by GIMP from my actual physical memory).
Note that I am actually unsure even rounding makes sense. Shouldn't we
rather show double values with a few digits after the decimal points?
For such values, I think it would make sense.
- Do not edit the internally saved accurate value when the entry is
edited to the same less accurate value as our saved value would be
shown too. In particular when changing the display unit to a bigger
one, we don't want to lose accuracy. This is especially true for low
values. Say you don't have a lot of memory and you set the Tile cache
size to 1.5GiB (1536MiB), you certainly don't want it to become either
1 or 2GiB when switching display unit to GiB. Now even if the number
will still display with less accuracy, the internal value will stay
accurate.
(cherry picked from commit d886bb1b90)
This bug doesn't happen when setting value through the GUI as in such
case, the unit never changed. It happened when setting a value which
could not be properly displayed by current unit (typically smaller than
1 in this unit, or with remainder).
In such a case, we should not manually set private->shift before
gimp_int_combo_box_set_active(), or the callback was failing to
reconfigure the GtkAdjustement, in particular min and max values.
As a consequence, hitting a Preferences reset, with a GimpMemSizeEntry
in Gigabytes, it got reset to Kilobytes with the max values capped at
4096. So I realized a Reset ended me with a Tile cache size of 4096 KB
in particular, which is of course ridiculously small and would be a
problem if one doesn't notice the issue immediately.
(cherry picked from commit 0be4e5c1dc)
Unfortunately the dist target requires pygtk.
Note that even adding --disable-python to DISTCHECK_CONFIGURE_FLAGS
doesn't help as pygtk-codegen-2.0 is needed to generate various .defs
file added to the DIST.
Yet pygtk is absent from Debian testing nowadays because it is too old
and unmaintained. So let's build pygtk ourselves.
Among the few tricks to make pygtk build fine:
- force Python2 by setting PYTHON env variable (detect Python 3
otherwise).
- patch to allow building against latest Pango.
Add a new "Messages" boolean parameter to performance logs, which,
when set, records GLIB log messages in the performance log as
markers, with an accompanying sample capturing their backtrace.
This option is enabled by default.
(cherry picked from commit 9e0fdc8e2c)
... which set/remove a GLIB log handler for all domains used by
GIMP.
Use the new functions in errors.c, instead of using
g_log_set_handler() directly.
(cherry picked from commit a143bfdf1d)
Add a new performance-log-progressive-coalesce.py tool, which
coalesces partial address maps in progressive performacne logs into
a single global address map, suitable for processing by the rest of
the tools.
Use the new tool as part of the pipeline in performance-log-viewer.
(cherry picked from commit 76f9e5feaf)
Add a new performance-log-close-tags.py tool, which closes unclosed
tags in incomplete performance logs, allowing the rest of the
perofmance-log tools to process them. This is necessary for
unfinished progressive logs.
Use the new tool as part of the pipeline in performance-log-viewer.
(cherry picked from commit e5fe1ef152)
Add an option to record progressive performance logs. Progressive
logs contain complete information after each recorded sample, by
writing partial address maps at each sample, containing all new
addresses introduced by the sample. Furthermore, when recording a
progressive log, the output stream is flushed after each sample.
This allows recording complete logs even in cases where they can't
be properly terminated, such as when GIMP crashes or freezes in the
middle of the log.
Progressive logs are disabled by default, since they potentially
increase the sampling cost. They can be enabled through a toggle
in the log file-dialog, or through the
GIMP_PERFORMANCE_LOG_PROGRESSIVE environment varaible.
(cherry picked from commit 146c234350)
When recording a performance log, allow setting the log parametrs
through the file dialog. Currently, this includes the sample
frequency, and the option to include backtraces.
These options are still controllable through the
GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY and
GIMP_PERFORMANCE_LOG_BACKTRACE environment variables. When set,
the variables override the values entered through the UI.
(cherry picked from commit 126002c5c9)
In gimp_edit_selection_tool_translate(), perform the active-item
checks even when the effective translation offset is 0, and only
bail afterwards. This avoids erroneously calling
gimp_tool_message_literal() with a NULL message in this case.
(cherry picked from commit 3a462a5e63)
Runs in the gimp stage in parallel to the make && make check build.
May catch dist errors.
Distcheck is allowed to fail. The idea is that being able to build GIMP
is more important and should get fast feedback, while make distcheck is
usually only used when a release is prepared.
Reviewer note: not sure about the "allowed to fail" part because we also
want to fix dist bugs as soon as we can (it's easier to find a bug
source when we get notified as soon as a guilty commit breaks the CI).
But anyway this is a step forward from current CI. So let's merge this
for now.
In file_open_image(), mount non-native files *before* looking up a
file-proc. Previously, we'd only mount the file after the initial
lookup, and fail to perform a second lookup if the mount succeeded,
leaving us with a NULL file-proc and a subsequent segfault.
Additionally, simplify the rest of the remote-file code-path.
(cherry picked from commit 0829dba97f)
File paths can contain confidential information such as usernames
and directory structures, making the previous behaviour a potential
privacy and security risk.
(cherry picked from commit a3a88bf6b9)
Basically if you enabled OpenCL or any of the experimental tools, it
will show the Playground in Preferences. Otherwise, say you enabled some
experimental feature months ago (e.g. with the CLI option) and you now
experience crashes or whatnot. And you forgot how to change it, and only
remembered that there was something in Preferences. It would make you
crazy to not find the tab again to disable the option.
This is even more important as OpenCL is moving from a normal option to
a playground option. So you might not even have ever seen the Playground
tab in Preferences and would not know how to disable OpenCL after you
enabled it originally in "System Resources" tab.
So now Playground is visible with any of these 3 conditions:
* If you use an unstable version.
* If you run GIMP with --show-playground option.
* If you previously enabled one of the playground options.
(cherry picked from commit d3ef6cfb18)
After discussions on IRC, it was decided that our current level of
support of OpenCL was not good enough. As a normal settings, people just
see it as a normal acceleration checkbox, even despite the warning text
and emoticone saying the opposite (i.e. it may even slow things down in
some cases).
Basically this feature needs more love to be back into mainstream
Preferences.
(cherry picked from commit 0f806d0e9c)
This file is available in a flatpak sandbox and will contain various
info such as the build commit, very useful info as we can have several
builds for a same version. For instance if we have exactly the right
commit, we can load exactly the same binary as a bug reporter very
easily, hence are able to get source correspondance without necessarily
asking reporters to install debug symbols (though it stays easier if
they can do it).
Other interesting info contained in this file are the exact runtime
used, the installed application or runtime extensions, the permissions
(people may override our flatpak permissions so it's useful to be able
to check when they did) and environment variables…
(cherry picked from commit bc5f6371e9)
In GimpSpinButton, don't propagate Enter key-press events if
updating the spin-button's value in response changes the entered
text. This prevents confirming dialogs when hitting Enter after
entering a math expression in size entries, updating their value
instead.
Likewise, don't propagate Escape key-press events if a new value
was entered, and restore the original value instead.
(cherry picked from commit e531023031)
Even though this engine is optional, we already have the code to detect
its absence at runtime, and to fallback to "gegl:matting-global". So it
won't be a problem even then.
When the operation is present though, it definitely makes a lot more
sense than matting global as default, because it performs a lot better
in most cases (as far as I could see as well as others).
(cherry picked from commit b52cdf4c90)
In GimpToolButton, when in "show menu on hover" mode, increase the
idle priority for hiding the the tool-group menu upon button/menu
leave-notify. Make the priority one step below the normal event
priority, so that a subsequent button/menu enter-notify event
canceling the idle is processed beforehand, while the idle is
otherwise still processed before ordinary lower-priority sources,
in particular, before projection rendering timeouts.
In file-tiff, add an option to crop the layers to the image bounds
when exporting individual layers (using GIMP_EXPORT_NEEDS_CROP
added in the previous commit), since TIFF has no concept of global
image bounds otherwise. Cropping is enabled by default.
Add a new GIMP_EXPORT_NEEDS_CROP export capability, which causes
gimp_export_image() to crop the exported image content to the image
bounds; this is useful for formats that support layers, but have no
concept of global image bounds, hence cropping is the only way to
enforce the image bounds.
When showing the export dialog, give an option to either crop the
layers to the image bounds, or to resize the image to fit the
layers.
When exporting a TIFF file without merging the image, make sure non
of the exported layers has a negative offset, by offsetting all the
layers as necessary. TIFF doesn't support negative page offsets,
giving an error in libtiff.
When loading a TIFF file with signed-int samples, convert the
samples to unsigned-int by offsetting them to the unsigned range,
instead of misinterpreting them as unsigned values.
(cherry picked from commit 8b9819339d)
In gimp_tool_button_enter_notify(), only mask-in the mouse-button
state for determining whether to show the tool-group menu. This
avoids other bits of state -- in particular, certain keyboard
locks, including keyboard-layout state -- from preventing the menu
from showing.
In psd-save.c, fix erroneous call to gimp_item_get_image(), which
was being called with an image-id, instead of a drawable-id,
potentially causing an error or wrong results if the image-id did
not correspond to an existing item, or if the corresponding item
did not belong to the exported image.
Clean up faint pixels in the "Acrylic 05" brush, which produce a
badly-thresholded mask with the Pencil tool. See issue #5180.
Thanks to Sevenix for the fixed brush!
(cherry picked from commit f9cc239f2c)
Fix horizontal downscaling of brush mipmap levels with odd width.
We'd previously fail to skip the last pixel of each input row,
which isn't included in the output when the width is odd, causing
subsequent output rows to be shifted to the right.
(cherry picked from commit c4a201eaf4)
In GimpDrawableFilter and GimpFilterTool, use an absolute offset
for the split-preview guide position, instead of storing it as a
fraction of the drawable's width/height. The latter could
introduce rounding error, which would result in wrong coordinates
when converted back to an absolute offset.
(cherry picked from commit 214936e8c6)
In GimpGuideTool, when a custom guide (whose position is updated
directly on motion) is moved past the display bounds, keep updating
the corresponding GimpGuide's position, even though the guide will
be removed on release, to avoid leaving the guide at its old
position.
This affects the filter tool's split-preview guide.
(cherry picked from commit 9a25ae7171)
... by qualifying them with "extern", in addition to
"__declspec(dllexport)". Omitting "extern" happened to work in the
past, but recent GCC versions require it.
... by qualifying them with "extern", in addition to
"__declspec(dllexport)". Omitting "extern" happened to work in the
past, but recent GCC versions require it.
(cherry picked from commit b2e223813b)
In gimp_config_deserialize_fundamental(), we can't use
g_value_set_static_string() because that will in the end pass the
GScanner's temporary scanner->value.v_string to
GObject::set_property(), and depending on set_property()'s
implementation, we might not dup the string (for example objects
created via gimp_config_type_register() will simply use g_value_copy()
and end up with a dangling pointer as a string member).
(cherry picked from commit 2e6656599d)
Simplify data transfer in the twain plug-in, and add support for
16-bit RGB/grayscale images.
(cherry picked from commit 30f65bb6c5fdbbb48edd3d07d764763d6a2477c4)
... since GEGLification of the twain plug-in (2.10.14 and later
versions)
In the data-transfer functions, allocate a temporary buffer for the
converted data on each call using the current chunk size, instead
of reusing the buffer allocated on the first chunk. This allows
for different chunks sizes across calls.
(cherry picked from commit 9a1d43c978)
... by grouping the geometry options, which can be controlled
through the on-canvas UI, in an expandable frame, which is
collapsed by default. The shape option is not part of the group,
and is moved to the top.
(cherry picked from commit 438babea6b)
In _gimp_prop_gui_new_generic(), when a pair of consecutive
properties have "range-start" and "range-end" roles, respectively,
and "luminance" units, use a range prop-widget for both properties,
as per the previous commits.
The range is sorted by default, unless the first property has a
"range-sorted" key of "false".
(cherry picked from commit 8eb752b194)
... which sets the limits of the range-widget's handle-bar
explicitly, instead of using the lower/upper properties' limits.
(cherry picked from commit ce8235e977)
In GimpHandleBar, add gimp_handle_bar_{set,unset,get}_limits(), to
allow settings the handle-bar limits explicitly, rather than
inheriting the adjustment limits.
(cherry picked from commit fa5dd99559)
... which creates a widget controlling a pair of lower/upper range-
limit properties, comprised of a handle-bar and two spin-buttons.
If the "sorted" parameter is TRUE, the "lower" property is bounded
above by the "upper" property, and vice versa.
(cherry picked from commit e03b8e597b)
... which takes a pair of GtkAdjustments, and binds the value of
the first to the lower-limit of the second, and the value of the
second to the upper-limit of the first.
(cherry picked from commit 45e5c2231a)
In tool-group GimpToolButton tooltips, in addition to showing the
description of the currently-active tool, list the other tools in
the group as well, to improve discoverability.
(cherry picked from commit 4d83c7a3fc)
Add a new GimpAccelLabel widget, which shows an accelerator label
for a given GimpAction. Unlike GtkAccelLabel, GimpAccelLabel
doesn't show a user-provided label in addition to that.
Note that the size request of GtkAccelLabel doesn't include the
accelerator part, which is desirable in some contexts.
GimpAccelLabel doesn't suffer from that.
(cherry picked from commit 2259ad5fcc)
Mostly I am adding a counter to the insignifiant zone fill, to be double
sure we are not going to fill huge areas (this should not happen already
anyway) and also it is no use to sample the line art buffer in such
case.
(cherry picked from commit 248477a125)
Partially revert commit c73710e410,
avoiding updating tool widgets unconditionally on tool resume in
GimpDrawTool -- it's too expensive in general.
Instead, handle display-shell changes in GimpToolWidget, by adding
GimpToolWidget::update_on_{scale,scroll,rotate} flags, which
subclasses can use to request an update on any of these events.
Set the flags as necessary for the affected widgets.
(cherry picked from commit afda774f44)
In GimpImageProxy, implement GimpColorManaged by forwarding the
functions to the underlying GimpImage, and forwarding the signals
in the other direction. This fixes color-managed view in the
Navigation dockable.
(cherry picked from commit 258c8454d5)
When converting an image to indexed mode, zero-out transparent
pixels instead of leaving junk in their indices, which might well
be out of range of the palette.
(cherry picked from commit 09870d4b15)
Wherever we store arbitrary-format colors in an opaque buffer, use
double for the buffer, instead of char, so that it has a strict-
enough alignment to handle all our used pixel formats.
(cherry picked from commit a90f59d961)
This fixes:
> GEGL-WARNING: (../../src/gegl/gegl/buffer/gegl-tile.c:127):gegl_tile_dup: runtime check failed: (! src->damage)
Which happened when a GEGL operation was running and you canceled it in
the middle, say with the ESC key (easy to reproduce with long operations
such as "Color to Gray"). In such case, obviously don't try to copy the
unfinished operation result into the dest buffer.
(cherry picked from commit 2b764c6542)
When using "show all" by default, gimp_display_flush() can be
called during GimpDisplayShell construction, before the newly-
constructed shell is assigned to the display. Use an ugly hack to
just ignore the flush when this happens.
(cherry picked from commit 0a06294af7)
gegl:focus-blur blurs the image around a focal point. It can be
used to create fake depth-of-field effects.
Add a prop-gui constructor which uses a FOCUS controller to control
the focus geometry.
(cherry picked from commit 60d4d25b93)
Add a new GimpToolFocus tool widget, which defines a focus region,
consisting of an inner limit, an outer limit, and a transition
midpoint between them. The widget allows controlling the limits
and the midpoint, and moving, scaling, and rotating the region.
(cherry picked from commit 5e005a762c)
... which constrains an angle to discrete increments in screen
space, similarly to gimp_display_shell_constrain_line().
(cherry picked from commit 8c1a277007)
Add a new GimpCanvasLimit canvas item, which draws an area limit
for different shapes. It will be used by the following commits to
implement GimpToolFocus.
(cherry picked from commit 06a2b4f338)
In GimpDrawTool, update the tool widget on GIMP_TOOL_ACTION_RESUME,
so that it can respond to changes in the display-shell scale/
offset. We'd previously done that for individual tools/widgets,
but let's just do it in one place.
(cherry picked from commit c73710e410)
In GimpDisplayShell, pause and restore the active tool when
rotating the canvas, similarly to scrolling and scaling.
(cherry picked from commit cd5e4e99dd)
There is no non-hackish way of fixing this without adding a new
"use-opacity-paint-mode" property to GimpToolPreset and a new toggle
in GimpToolPresetEditor. Restoring opacity and paint mode can now be
controlled explicitly, and defaults to TRUE.
(cherry picked from commit 97b714d428)
If we don't do this, the clipboard owner doesn't get unreffed (also the
GtkClipboardClearFunc is not called either, but we don't set any so this
was not a big problem).
The main consequence was that copying was setting the Gimp object as an
owner, which kept a reference and prevent its finalize() method to run,
hence was leaking data (and in particular some GEGL buffers for
clipboard operations, which was how the issue became more visible upon
exit).
(cherry picked from commit fca6371e29)
Properly initialize GimpSelectionTool::saved_operation upon
modifer-key press, even when some modifiers are masked out by
GimpPolygonSelectTool while the tool is active. This avoids
erroneously "restoring" the operation to a previously-saved state
once the modifier keys are released.
(cherry picked from commit e0a5aaeb22)
Remove the "CMY" model from compose and decompose, it's gone from
babl. Also fix decomposing to CMYK by using the right component names.
(cherry picked from commit f3f8d3a54e)
Change while() to go from 0..360 instead of 0..361 so the code passes
automated tests. The code never ran into this situation but the change
is a small improvement anyway.
(cherry picked from commit 452924dbe9)
By only doing the snapping to white/black for whitest/blackest palette
entries when the original RGB data contained these colors we permit
choosing near white/black colors in the cases where this might be
a desirable result as the whitest/blackest colors.
(cherry picked from commit d4387987b5)
The median-cut algorithm to derive a suitable palette for the image
computes each index to be used as the average of colors in a 3d box
in a color space, making the result value drift away from the extremes.
This makes it nigh impossible to achieve pure white or black, even
when the original image contained these colors, like in scans of
printed documents and technical drawings.
We counteract the drift by snapping the whitest color to white and the
blackest color to black if the resulting colors of median-cut are
already sufficiently close to white or black.
(cherry picked from commit 9bb3ff42d7)
layers_opacity_cmd_callback(): get the select_type from
the GVariant instead of using the GVariant as an enum
directly (missed when porting, spotted by Massimo).
Fix the same bug in channels_select_cmd_callback()
and layers_mode_cmd_callback().
(cherry picked from commit 50257e9f7e)
In GimpUnifiedTransfomTool, avoid moving the pivot when
readjusting, and when the transform directions are linked, if the
pivot is locked.
(cherry picked from commit d7c995153d)
... which copies a TransInfo array to the current info array,
possibly with modifications. While the default implementation
simply copies the array as-is, the following commit will override
the function for the Unified Transform tool, to avoid copying the
pivot position when the pivot is locked.
Use the function in GimpTransformGridTool, instead of copying the
array directly, as necessary.
(cherry picked from commit aa1a1f0a0c)
In GimpTransformGridTool, keep the transform-direction chain-button
insensitive while the tool is not active, and always unlink the
button when halting the tool. This avoids the directions from
accidentally being kept linked, resulting in the tool seemingly
having no effect.
(cherry picked from commit 9f6af7dbd3)
For some reason we reverse the channel order when loading/saving a
PSD file. This doesn't seem to be necessary, and leads to a
reversed channel order across GIMP/Photoshop. Simply use the
normal channel order instead.
On 64-bit, all seems fine, but when building to 32-bit (at least Windows
32-bit), G_GUINT64_FORMAT is defined to "%llu" while time_t is a long
int. So it doesn't match and the compiler complains:
> warning: format '%llu' expects argument of type 'long long unsigned int', but argument 3 has type 'time_t' {aka 'long int'}
Let's cast to (guint64) to make sure the type always match.
(cherry picked from commit 7e7d48a7ac)
Our installer use Msys2 packages when possible. And Msys2 repository
provides version 0.3.9, released on March 2, which contains our patches.
No need for them here anymore, no need to make custom builds.
(cherry picked from commit 0aca033370)
Use the right GtkAdjustment in gimp_scale_entry_log_to_linear().
See merge request !49.
Thanks to MihailZenkov for spotting this!
(cherry picked from commit 5dc1572b01)
When building (at least on 32-bit), fixes this warning:
> app/widgets/gimpdashboard.c:3840:58: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast]
Unsigned long long is specified in the C99 standard to be at least
64-bit. So it's normal that the compiler complains, as a cast from
unsigned long long to a pointer has chances to go very wrong.
Yet gimp_backtrace_get_frame_address() actually returns a guintptr which
is type-compatible with gpointer so let's not give the compiler false
information and just use this type. Then cast it to unsigned long long
just for printing to dashboard log.
(cherry picked from commit 8caef4ea0b)
... when rulers and scrollbars are hidden
In gimp_display_shell_fill(), make sure a size-allocate always
happens for the canvas, even when the rulers and scrollbars are
hidden, so that the pending size_allocate_center_image is handled,
and doesn't block canvas drawing.
(cherry picked from commit 4e560f2ff0)
I am comparing absolute value of 2 double computation results. Might as
well just use fabs() instead of truncating both values to int.
Fixes the following:
> warning: using integer absolute value function ‘abs’ when argument is
> of floating point type ‘double’ [-Wabsolute-value]
(cherry picked from commit f6dd30f3a8)
Fixes the following bug:
> warning: absolute value function ‘abs’ given an argument of type
> ‘glong’ {aka ‘long int’} but has parameter of type ‘int’ which may
> cause truncation of value [-Wabsolute-value]
(cherry picked from commit fddaa77218)
Fixes:
> warning: using integer absolute value function ‘abs’ when argument is of floating point type ‘double’ [-Wabsolute-value]
(cherry picked from commit b71754f2a7)
1 > warning: "_WIN32_WINNT" redefined
2 > pointer targets in passing argument 2 of 'send' differ in signedness
3 > passing argument 4 of 'setsockopt' from incompatible pointer type
For the signedness/type issues, I just casted to (void *) which was the
expected type for these parameter on the Linux API anyway. As for
Windows API (which was expecting char* for these various API), the
compiler just does the cast itself from void* without complaining
anymore.
(cherry picked from commit c280cb9da7)
On Windows, accept() wants an int for addrlen but on Linux, it wants a
socklen_t which is an unsigned int. So we can't just switch to gint as
proposed in !232 (if we do so, the signedness warning now happens on the
Linux build instead of the Windows one).
Fortunately it looks like socklen_t is actually typedef-ed to int in
Windows headers. So let's just use this type, which is much more proper
anyway as this variable is only used in functions which want this type
on Linux.
Fixes:
> warning: pointer targets in passing argument 3 of 'accept' differ in signedness
(cherry picked from commit e854de73ee)
In gimp_filter_tool_real_config_notify(), make sure the incoming
pspec in not NULL before accessing it.
gimp_operation_tool_aux_input_notify() may emit "notify" on the
config object with a NULL pspec.
(cherry picked from commit 19c0d43c25)
When converting Brightness-Contrast to Levels, and Levels to
Curves, make sure to copy the common settings as well as the
operation-specific settings.
(cherry picked from commit 987447f18f)
In GimpCurveTool, don't reset the curve config manually, and rather
let GimpFilterTool reset it, only maintaining the active channel
(similarly to GimpLevelsTool), so that the common operation
settings are also reset.
Note that this also avoids keeping the channel curve types, which
should work correctly after last commit.
(cherry picked from commit 88689515ab)
In gimp_curve_config_copy(), make sure to copy the curve type
*before* the points, so that, when changing the type from FREE to
SMOOTH, we don't overwrite the copied points with interpolated
samples.
(cherry picked from commit 56693a8393)
It's minimal. I've not added CLang build or the Windows cross-builds
yet. Probably later. :-)
Only dependency changes from master are: GTK+2 instead of GTK+3.
Also GIMP is now built with --disable-python because even though Python
2 is still in Debian testing, apparently python-gtk2 is not packaged
anymore. So let's unfortunately drop this in our CI for simplicity sake.
This makes both master and gimp-2-10 CI now very similar, hence will
make it easier to fix one or the other.
In gimp_operation_config_sync_node(), when the operation has a
property of the config object's type, don't skip the other
properties. This makes sure to set the "linear" property of
GimpOperation{Curves,Levels} according to the config object. We'd
previously done it manually in GimpFilterTool, but the setting was
not applied when repeating the filter.
(cherry picked from commit 0096e563f6)
pygtk is being removed from distros, and this breaks our gimp-2-10 CI
build.
Removing it from the dependencies should make the build work
again, but means we lose building of the pygimp modules.
In GimpToolButton, don't let the group menu grab the keyboard focus
when showing it on hover. This avoids accidentally reassigning the
keyboard shortcut of the selected tool.
In file-psd, add support for exporting high bit-depth images. This
is currently limited to 16-bit images, since 32-bit images seem to
have a different structure (our loading code can successfully load
32-bit images exported by the plug-in, but not actual 32-bit PSD
files saved in Photoshop.) Higher bit-depth images are saved as
16-bit for now.
Note also that when saving a linear image with a built-in linear
profile the result is wrong (the image is exported with a linear-
TRC profile, but the data is perceptual), but this is a general
problem we have to fix, not restricted to the PSD plug-in.
(cherry picked from commit 9099f317bc)
Let's go with the logics "bottom layer is first", which is also the
logics in animated formats. Hence changing the layer order on loading
multi-page PDF.
(cherry picked from commit 809e79f37a)
As per commit ed7ea51fb7, reintroduce
the "Fade" functionality for filters, by incorporating it directly
into GimpFilterTool.
Add "mode" and "opacity" options to GimpOperationSettings, and add
a corresponding "Fade" expander to the GimpFilterTool dialog
allowing to control them.
Reintroduce the FADE layer-mode context, and use it to mark the
layer modes avaialable for fading.
Add a new gimp_drawable_apply_operation_with_config() function,
which takes an operation node together with a config object, and
applies the operation using the config options, including both the
operation-specific options, and the common GimpOperationSettings
options.
Use the function in gimp_gegl_procedure_execute(), so that
reapplying a filter takes the common operation settings used
originally into account.
Remove the common operation settings from GimpFilterOptions, and
instead, in GimpFilterTool, store these settings in the operation's
config object, which is now a GimpOperationSettings subclass, as
per last commit.
Add a new GimpOperationSettings class, to be used as a base class
for all operation-config types. The class provides options common
to all operations (namely, the clipping mode, input region, and
color options), which were previously stored in GimpFilterOptions,
and were therefore bound to the filter tool, instead of being
stored as part of the operation settings; as a result, these
options would have no effect when reapplying a filter, or when
restoring a preset.
The GimpOperationSettings options do not affect the operation
node, but rather the associated GimpDrawableFilter object. The
class provides a gimp_operation_settings_sync_drawable_filter()
function, which applies the options to the filter.
Modify all custom and auto-generated operation-config types to
derive from GimpOperationSettings, and modify the GimpConfig
functions of the former to account for the GimpOperationSettings
properties, using a set of protected functions provided by the
class.
... which determines if a node's operation-class has a specific
key, and can be used instead of gimp_gegl_node_get_key() when only
existence is important, to avoid compiler warnings.
Update the rest of the code to use the new function.
I don't reproduce these build warnings in my build but frogonia reported
them:
> warning: 'strcpy' accessing 1 byte at offsets 0 and [0, 2147483645] may overlap 1 byte at offset 0 [-Wrestrict]
And indeed the man of strcpy() clearly states that "The strings may not
overlap" (which is clearly not guaranted in current code as we don't
know the size of what's after the substring).
strncpy() might have done the trick as it doesn't say anything about
possible overlap or not, but let's just use memmove() instead where it
is clearly written that memory areas may overlap (note that bcopy() as
proposed by ankh would have also done the trick, but it is marked as
deprecated).
(cherry picked from commit 291af71e95)
… defaults to FALSE for PNG, TIFF.
The logics is that in most case, when alpha is 0, you don't expect color
to be retrieved and some people were bothered by this when erasing data
with eraser tool or selection deletion.
For the WIP image as well as for XCF format, we definitely want to keep
color data as there are workflows where you would want to erase/unerase
pixels subtly (selection also are not binary and should not be expected
to erase color data on layers with alpha channel). So we want to keep
the non-destructive behavior there.
Yet for export formats, going for "deleting what looks deleted" is a
valid approach, especially as it has been argued that experienced users
would know how to read and change the format options (and these
experienced users are likely the ones who may have valid reasons to want
pixels with full transparency to keep color values).
PNG and TIFF were the only 2 formats where I see such options, so
changing the default for these 2 plug-ins.
(cherry picked from commit 105c4efc8b for
the TIFF one and adapted to gimp-2-10 code for PNG)
… oscp-router0[12].gnome.org.
The file was opened asynchronously through g_file_read_async() but the
actually reading from a GFileInputStream was actually done in the
callback, in the main thread. So it may be possible that file is
accessible but connection is very slow or non-reliable and actual
reading would block the main process. I am assuming this is what may
have happened for this reporter.
Instead let's use g_file_load_contents_async() which does the file
opening, reading and closing all in the asynchronous task, hence would
not slow down anything even if the remote resource is unavailable or
connection is very slow.
(cherry picked from commit cc16ec5f9f)
Apparently, the "drag-begin" signal of dockbook tabs can be raised
multiple times when a drag begins (this seems to happen randomly,
and rarely -- possibly a GTK bug). In
gimp_paned_box_drag_callback(), which gets called in response, make
sure not to leak the corresponding idle source in this case, which
can lead to a segfault if the widget is destroyed before the idle
is run.
(cherry picked from commit 6bae5d8cf7)
It was unneeded on master, surely because there must be a
gtk_widget_show_all() run somewhere down the line.
Also reuse the button widget (not so important, but while I'm at it).
In GimpFilterTool, use gimp_drawable_filter_set_preview(), added in
the previous commit, to toggle the filter's preview, instead of
removing and re-adding the filter. This avoids destroying cached
results when disabling the preview, allowing to quickly toggle the
preview on and off to compare the result.
(cherry picked from commit 912b36a8f8)
... which allows temporarily turning the applicator into a NOP,
without destroying cached data.
This commit also improves gimp_applicator_set_{src,dest}_buffer().
(cherry picked from commit e324e2d4b3)
Cropping tools will no longer discard layer data that falls out of the
crop region if the layer's pixels are locked
(cherry picked from commit 9a9e2e9a19)
Adds a new "Delete cropped pixels" toggle to the crop tool options,
to allow turning off the deletion of layer data that falls out of the
crop region.
(cherry picked from commit ee97c25b87)
Revert "app: also localize LC_TIME to GUI language."
This reverts commit a4e65ac836.
LC_TIME format apparently does not accept the broader format with just
the lang part, for instance "fr". The region is necessary, like "fr_FR".
In our supported languages, we were mostly using lang only except for a
few langs where we support regional variants.
This makes sense as time format may be quite different depending on
regions (dates are quite different in GB vs US, though that was actually
one of the cases where we were using accurate locale format).
And the main issue is that it was not only breaking time localization.
Normal string localization (LANGUAGE) got somehow broken as well by
broken LC_TIME.
Anyway for now let's just stick to whatever OS-set time format (even
though it may differ from GIMP Preferences-set language defaults).
(cherry picked from commit 39890a49eb)
After discussing with Schumaml and Houz on IRC, let's just drop the
generic comment which may be confusing and is probably unecessary,
especially now that I write the revision number (present and new ones).
So let's just assume people understand that they should update, even
when GIMP version stays the same (this was the case I was the most wary
about, that people think the notification is an error as since they have
the last version, they don't have to update GIMP).
I hesitated to at least leave just the simple "It is recommended to
update." sentence but after much hesitation, let's go with no generic
comment at all. The download button by itself should suffice.
Of course, when a specific revision comment is set in
gimp_versions.json, it is still displayed.
(cherry picked from commit 56ffa2fd11)
- gtk_show_uri_on_window() replaced by gtk_show_uri()
- gtk_button_new_from_icon_name replaced by
gtk_image_new_from_icon_name() in a GtkButton.
- gtk_widget_set_margin_top() removed.
While this issue was unseen so far on common desktop machines, the CI
build encountered it, hence failing 6 of the unit tests.
A connection to the bus could not be established hence the dbus_manager
was never allocated, and finally it would crash at exit if we tried to
unref it unconditionnally. Use g_clear_object() instead.
Also add some stderr output for easier debugging, for when one of the 2
possible error cases might happen (as documented by g_bus_own_name()).
(cherry picked from commit 2c1efdedf0)
- Instead of the download link being just a link button (similar to
browser "blue text" links), make it a proper button encompassing the
update icon and the download text "Download GIMP X.Y.Z".
- Make also the revision number part of the download information.
- Frame title is now "Update available!" instead of "New version
available!" (because it's not necessarily a new version, it can also
be just a package revision. "Update" is more generic).
- When no update is available, the "Check for updates" button is big and
has a label, and also now an icon. When an update is available, hence
we display now a button for the download link, the "Check for updates"
button becomes small with icon only in order not to take visual
priority over the download itself (yet allowing to re-check for even
newer information).
(cherry picked from commit a55e898c96)
As noted on IRC, after the first update check on a given day, it looks
like the check button does nothing. Therefore also display the check
time to clearly show the button click was taken into account (simply
there are no updates, hence only displayed check time is updated).
(cherry picked from commit a05b085112)
Do it even on stable builds as it can help diagnose bugs on releases.
Note that the issue we had just know with casing on the build-id would
not have been seen by such stderr output anyway. Just in case for future
issues.
In gimp_symmetry_{mirror,mandala}_update_strokes(), adjust the
symmetry origin according to the drawable offset, so that it
remains fixed relative to the image regardless of the drawable
position.
(cherry picked from commit 6ed9b2bb7a)
Add a "Menu mode" option to the toolbox preferences, which controls
the menu behavior for tool-group buttons, and can be one of "Show
on click" (current behavior), "Show on hover" (show the menu when
hovering over the button), and "Show on hover in single column"
(behaves like "Show on hover" when the toolbox has a single column,
and "Show on click" otherwise) -- the latter is the default.
Note that "Show on hover" requires the ability to remove the menu
grab, which doesn't seem to work in GTK3, so this change is
restricted to 2.10 for now.
In gimp_image_duplicate(), explicitly mark the new image as dirty,
so that its dirty time is set. This avoids showing a NULL message
in place of the dirty time when closing the image.
(cherry picked from commit 83f935873a)
In GimpSpinScale, apply the slider gamma to the input [min,max]
range, rather than the output [0,1] range, using an odd gamma
curve, in particular, so that we handle negative values correctly.
(cherry picked from commit 5678153797)
When checking for updates, write the new timestamp and version info
to Gimp::edit_config, instead of Gimp::config, and rely on its
auto-save mechanism to save the changes, in order to avoid having
to save Gimp::config on exit, which overrides modified settings
that require a restart, such as the UI language, as they are only
reflected in Gimp::edit_config.
This fixes the bug, but can cause the new update info to be
discarded if the Preferences dialog is open while checking for
updates, and is subsequently canceled. Ideally, the update info
should live in a separate file, rather than in gimprc.
(cherry picked from commit ee2a65af0d)
This makes the configure tests for SSE support fail if CFLAGS specify -mno-sse2 or/and -mno-sse4.1.
Fixes #4363.
(cherry picked from commit 0108d7e214)
Found via `codespell -q 3 -S ./ChangeLog*,*.po -L als,ang,ba,chello,daa,doubleclick,foto,hist,iff,inport,klass,mut,nd,ower,paeth,params,pard,pevent,sinc,thru,tim,uint`
(cherry picked from commit a928452eba)
The serial 7 of m4macros/ax_gcc_func_attribute.m4 has an issue that when
Wstrict-prototypes is used with gcc, the attribute detection always
fails even if the attribute is actually supported. In such case the fish
cache will never be constructed. It's fixed in serial 12 of the macro in
autoconf-archive and this change updates the one distributed with GIMP
to serial 12.
(cherry picked from commit 7a4254dda1)
Instead of rejecting plug-in procedures with invalid parameter- or
return-value names (see issues #4392 and 4641), simply fix the
invalid name and allow the procedure to register. Apparently,
there are plug-ins out there that use invalid parameter names (in
particular, liquid-rescale), so let's keep them working in 2.10.
Show appropriate warning/error for invalid parameter names when not
in PDB compat mode.
And by "supporting CR3", I mean sending the file over to raw developer
software which are supposed to support it! At the very least RawTherapee
support CR3 (since recent version 5.8 apparently), not sure about
darktable (but if not yet, I assume it won't be long either).
(cherry picked from commit 3a0af1f50a)
In gimp_drawable_get_sub_preview_async(), when the drawable buffer
has a validate handler (i.e., when it's a group layer), use a chunk
iterator to validate the buffer in chunks, where each chunk is
validated in a separate invocation of the async function. This
prevents validation from blocking the main thread for too long when
the buffer is not already fully validated.
(cherry picked from commit 64bf77aed8)
In gimp_drawable_get_sub_preview_async(), when the drawable buffer
has a validate handler (i.e., when the drawable is a group layer),
validate the requested area before calling gegl_buffer_get(), so
that the buffer is validated in a single step, instead of tile-by-
tile.
(cherry picked from commit 919ddce773)
In gimp_idle_run_async(), connect to the async's "waiting" signal,
and run the async func in the context of the caller in response, to
avoid blocking indefinitely.
(cherry picked from commit 30f509c84d)
In gimp_drawable_get_sub_preview_async(), use
gimp_idle_run_async_full() to render the preview in a low-priority
idle source when the drawable uses a validate handler (i.e., when
it's a group layer), to avoid rendering the preview before the
projection is done rendering, causing a noticeable freeze.
(cherry picked from commit fee159e6b4)
In gimp-utils, add new gimp_idle_run_async() and
gimp_idle_run_async_full() functions, having the same signature as
gimp_parallel_run_async[_full](), but running the async function in
an idle source on the main thread, instead of in a separate thread.
The 'priority' parameter of gimp_idle_run_async_full() specifies
the idle-source priority.
(cherry picked from commit 6733b153cc)
Recent code changes depend on 2.56 symbols, and no one seemed to
complain for 2.10.18, so let's just bump the requirement.
Furthermore, 2.56.0 and 2.56.1 have a Windows-specific bug we were
testing for, so let's just bump straight to 2.56.2.
...from an svg file
gimp_bezier_stroke_new_ellipse(): need to interpolate the path's head
and tail, not its tail and tail. Spotted by Massimo.
(cherry picked from commit 27e78849a2)
In the various libgimp data-selection functions, replace spaces
with hyphens in the callback-proc parameter names. Spaces in
parameter names are invalid, which is now enforced by GIMP/GLib,
causing procedure registration to fail.
When committing a transformation to a floating-selection layer, if
the selection mask is non-empty (probably a state we don't want to
allow, but one that can currently be achieved), and the tool-GUI
dialog is detached, gimp_transform_grid_tool_response() is called
*while* applying the transformation, leading, ultimately, to a
segfault.
Fix this by returning early when this happens.
(cherry picked from commit 11efe64736)
In file-psd, make the data_start and data_len fields of the
PSDimageres and PSDlayerres structs unsigned, to avoid potential
overflow/sign-extension.
(cherry picked from commit be7cace74e)
Add new Symbolic-High-Contrast and Symbolic-Inverted-High-Contrast
themes, which are automatically-generated high-contrast variants of
the (original) Symbolic theme. The contrast factor is settable in
the makefile, and is currently at 1.5 for both themes.
Rename tools/invert-svg to tools/svg-contrast, which now takes a
contrast-factor argument, and adjusts the input SVG contrast,
instead of just inverting it. Note that we can still use the tool
to invert icons, using a contrast of -1.
I didn't realize it because the meson build was returning 'windows' for
GIMP_BUILD_PLATFORM when I cross-built with Mingw-w64. But in the
autotools, it was storing "mingw32", which would not compare with our
gimp_versions.json. Therefore in GIMP 2.10.16, the version update check
would have worked, but not the revision check.
This fixes the problem.
(cherry picked from commit a5ea6d6b9b)
Allow horizontal scrollbars in all the Preferences dialog tree-
views, so that they don't limit the minimal width of the dialog (in
particular, the UI- and icon-theme tree-views may contain
arbitrarily-long paths).
(cherry picked from commit d868247fd9)
In GimpFgBgEditor, we currently use gtk_render_frame() in master,
and gtk_paint_shadow() in gimp-2-10, to draw a border around the
color FG/BG color areas. However, the former is relatively
subtle, especially with dark themes, and the latter is a NOP with
the pixmap engine, which is what our built-in themes use.
Instead, draw the border ourselves as a pair of black and white
rectangles, similarly to Photoshop.
Move the entire color-frame drawing functionality to a separate
function, to avoid code duplication between the FG and BG frames.
(cherry picked from commit fb1c086097)
In xcf_load_image(), suspend size updates for layer groups before
adding their sublayers, to avoid unnecessary intermediary size
updates. Resume size updates in reverse order, so that nested
groups are updated before their ancestors, after all layers have
been loaded.
(cherry picked from commit 63df5602a2)
... causing artifacts
In GimpGroupLayer, override GimpLayer::get_bounding_box() to return
the group's own calculated bounding box for pass-through groups,
instead of using the group graph's bounding box, as calculated by
the default implementation of GimpDrawable::get_bounding_box().
We don't currently update the group's bounding box in response to
all the events that may affect the graph's bounding box, which can
lead to artifacts, neither should we use the graph's bounding box
anyway, since it includes the backdrop's bounding box, as the
group's layers are composited against the background.
Note that we still use the graph's bounding box for non-pass-
through groups, since it takes attached filters into account,
which are applicable for normal groups, but not pass-through
groups.
Additionally, don't restrict the group's bounding when it has a
mask, since this is now handled by GimpLayer.
(cherry picked from commit aa9ae1c65c)
In gimp_layer_get_bounding_box(), return the mask bounding box when
show-mask is active, and otherwise delegate the actual layer
bounding box calculation to a new GimpLayer::get_bounding_box()
function, and intersect its result with the mask bounding box, if
necessary. The default GimpLayer::get_bounding_box()
implementation simply chains up to
GimpDrawable::get_bounding_box(), but GimpGroupLayer will override
this function in the following commits.
(cherry picked from commit 7f53cf9c55)
In GimpLayer, update the effective mode, and excludes-backdrop,
when any of the mask-related properties change, and, when show-mask
is active, set the effective mode to NORMAL.
(cherry picked from commit b2a1a7cb01)
In GimpOperationLayerMode, when the op has a mask connected, and
we're processing an area outside the mask bounds, set the op's
opacity to 0, so that the backdrop shows through. The actual
process() function gets a NULL mask pointer in this case, and so
would composite the layer as if it had no mask, exposing areas that
should be masked out.
Add a GimpOperationLayerMode::parent_process() function, which
subclasses can override instead of GeglOperation::process(), and
make sure to update the GimpOperationLayerMode::opacity field
before calling this function (and, subsequently, before calling
GimpOperationLayerMode::process()).
Clean up the rest of the fields, and adjust the rest of the code.
(cherry picked from commit 646c804c04)
In GimpPaintTool, when not snapping brush outline to stroke, make
sure to properly snap the cursor position to 15-degree angle
multiples in line mode, not only when painting the line, but also
during motion.
(cherry picked from commit 0f07f1baa5)
In gimp_drawable_merge_filter(), fix the format of newly allocated
buffers when applying a filter that changes the size of the
drawable, and the requested format is either unspecified, or
matches the existing drawable format. The new buffer would
previously be created with a "RGBA float" format in this case,
regardless of the image precision, resulting in a potential
mismatch between the drawable format and the image precision.
This cna lead to inconsistent buffer data when saved as XCF, which
is later rejected on load. See issue #4643.
(cherry picked from commit ae6f6ba42a)
When dropping a corrupted layer while loading an XCF, make sure to
clear the corresponding XcfInfo fields that point to it, so that
it's not erroneously used later, as we now continue loading the
image even after corrupted layers are encountered.
See, for example, issue #4643, for a corrputed XCF file affected by
this.
(cherry picked from commit d53e701daa)
In gimp:replace, when compositing the same content over itself,
i.e., when the input and aux buffers share the same storage and
same tile alignment, pass the input buffer directly as output,
instead of doing actual processing.
In particular, this happens when processing a pass-through group
outside of its actual bounds.
(cherry picked from commit 2eaaa950a5)
In the screenshot plug-in, don't clean the image, since it's not
backed by any persistent source, and disable undo while modifying
it, so that the initial edit history is clean.
(cherry picked from commit 4fe8217898)
In GimpPaintTool, fix the brush outline position while painting,
when "Snap brush outline to stroke" is enabled.
(cherry picked from commit ea729f6d02)
I realized having the revision as a build number is the wrong idea as it
implies packagers will have to rebuild GIMP for just a revision. Yet
very often revision may just be data change or dependency fix/update
without rebuild needed (i.e. no ABI change).
Instead let's keep this package information as a file 'gimp-release'
(inspired by /etc/os-release and other /etc/*-release files of
distributions).
(cherry picked from commit 87e9ebcfad)
If for instance you've got no internet connection or other reasons that
a check might fail, the check-update-timestamp will be 0, which is
1970-01-01.
Thanks to Alexandre Prokoudine for noticing it!
(cherry picked from commit ed77830381)
Even when we already notify of an update, we should leave the ability to
query the last gimp_versions.json manually.
It would allow also people who disabled automatic check at startup
(whether through preferences or because the build disabled the feature
altogether) to still make update checks, and to not be forever stuck
with the result of an outdated version check.
(cherry picked from commit 2900f2a868)
In the Airbrush tool, increase the maximal stamp FPS from 15 to 60,
and change the corresponding maximal Rate value from 150 to 100.
This technically affects tool presets, but we'll live.
(cherry picked from commit 6cd3c8bc74)
Adds generalized erase Nth row function,
and sets original erase row function to
call generalized one with n = 2
to reduce code duplication
(cherry picked from commit 0a5af889f9)
This is backported from the gimp 3 master branch. Replace the checkbox
of two saving options (keep layer, or redraw on last active layer),
with a combo box that has a third option for saving the pattern as a path.
When downscaling raster brushes, we currently resample the original
brush with no fitlering (other than bilinear interpolation), which
results in very noticable aliasing when using heavily downscaled
big brushes.
This commit constructs a box-filtered mipmap hierarchy for the
original brush on-demand, and the closest mipmap is used as the
resampling source for downscaled brushes, significantly improving
the output quality.
(cherry picked from commit ee39f0ec13)
... which converts a (scale, aspect_ratio) pair to a (scale_x,
scale_y) pair.
Change gimp_brush_transform_matrix() to take (scale_x, scale_y)
parameters, instead of (scale, aspect_ratio), and change the rest
of the code accordingly.
(cherry picked from commit 2dddf59dbf)
In gimpbrush-transform.cc, resample the transformed brush at pixel
centers instead of edges, and fix the corresponding source
coordinates.
(cherry picked from commit e0e1ad5e2a)
When loading ABR brushes, error out on negative scan-line lengths,
instead of trying to allocate a huge buffer. This entire code
could use a whole lot more unsignedness, but this should cover the
crash.
(cherry picked from commit 52cb2edd9e)
Improve the efficiency of decoding RLE data when loading ABR
brushes, by reading entire scanlines into a buffer all-at-once,
instead of reading the stream byte-by-byte.
(cherry picked from commit 07f95291a5)
In GimpPaintTool, track the cursor position separately from the
current paint core position, so that the brush outline doesn't lag
behind the cursor while painting.
(cherry picked from commit d244a079ca)
... containing a floating selection
When destroying a GimpGroupLayer, remove all the children signal
handlers before destroying the container, so that we don't attempt
to reallocate the group's projection in response to
"update-bounding-box" signals emitted during layer destruction,
which can happen for floating selections.
(cherry picked from commit 893990afce)
The idea is to be able to advertize a new revision of the same version
of GIMP. For instance, this would apply when we release a
`gimp-2-10-14-setup-3.exe` Windows installer (then we are at revision
3, provided we started at revision 0).
The revision number is obviously only relevant to a given platform and
version. Also the concept of build ID allows to differentiate various
builds for a same platform, in particular to not look at revisions of
third-party builds. The build ID can be any string. Maybe we could just
use reverse DNS build id (such as "org.gimp.GIMP_official") to identify
the official GIMP build. So in the end, we only compare revisions for an
identical (version, platform, build-id) tuple.
(cherry picked from commit 7b5fff7861)
Allows to disable the automatic update check at startup. I believe some
packagers will want such options, in particular on Linux distribution
(where they control their own release schedule and won't want GIMP to
pop new version warning up because they have been slow to update their
package).
Note that it is still possible to query version checks manually in the
about dialog, but the automatic check/popup is gone with this option.
(cherry picked from commit 315665592c)
- Clear the GError when relevant.
- Check result of json_path_compile() just in case.
- Print some error on stderr when parsing of gimp_versions.json fails
(which should never happen on releases but would help during
development).
(cherry picked from commit 8528759834)
Instead of storing versions as objects, we now store them as arrays,
because json arrays are ordered, unlike objects (the website was using
non-standard Python extension to consider the version objects ordered
but this is not proper and even more, the lib we use for GIMP does not
have a similar extension.
This simplifies a bit the code as we don't need to order the versions by
comparing their string representations.
(cherry picked from commit 1f75d2e34a)
gtk_widget_get_window() may return NULL. I had the case when opening
some menus in bottom of tool options (like the "Save|Restore Tool
Preset" menus). We must check this before doing anything with it.
(cherry picked from commit 0a28534a90)
Previously we were only passing this information on the debug dialog
when debugging warnings and criticals. Now it will also have the
information for crashes, hence recommending people to update their GIMP
instead of reporting bugs on old versions.
(cherry picked from commit 5b664ecbec)
Instead of making the focus on bug reporting, the debug dialog will now
make the focus on updating the application if it is found that one is
not using the last version.
Debug data (backtraces and co.) will still be available and copiable,
but under an expander, and bug report button won't be displayed (i.e.
data will still be available upon request but we don't push anymore
people to submit it directly if they are using old versions of GIMP).
Of course, if you are using the last version (or version check was not
possible), the dialog still stays the same.
(cherry picked from commit 2f379494a7)
When we set the GUI language through Preferences, also set LC_TIME, so
that locale-aware date functions also produce the right formats.
For instance, I use this in the About dialog to format the release date
of the last version of GIMP.
(cherry picked from commit a4e65ac836)
This about dialog will complain an explicit message about the new
version and a link button to go to the download page.
(cherry picked from commit 6b237b90fd)
When an update is available, a big frame is visible, proposing to go to
the download page. Now a button is also available to explicitly request
for an update check in other cases (bypassing the wait delay for a
future startup).
(cherry picked from commit 827473fd88)
I was wondering which shape should take the new version notification
(again some ugly pop-up?!) and realized using the About dialog was a
good idea.
This is preparatory work for this to happen.
(cherry picked from commit 826ece3b86)
First, let's make the check happen at each startup on unstable (still
once a week on stable).
Second, make it parse gimp.org's gimp_versions.json on stable, but
testing's one on unstable and also check environment variable
GIMP_DEV_VERSIONS_JSON (unstable only) to allow setting a local path
(allowing to tweak the file and test various cases).
Unrelated to testing, some improvements:
- save a timestamp in seconds (really no need to keep microseconds
precision here).
- just in case, check that the saved timestamp is not in the future.
(cherry picked from commit b874cadfad)
This fixes the following warning when compiling with Mingw:
> warning: integer overflow in expression of type 'long int' results in '-694967296' [-Woverflow]
(cherry picked from commit bb7f229b97)
GIMP will now process the remote gimp_versions json file to look if one
is using the last version of GIMP. This initial code doesn't act up yet
on this information. This will come in further commits.
Here are the characteristics:
- Since this requires internet access, a new checkbox is available in
the Preferences dialog, allowing to disable version checks. Note that
it is enabled by default as it is an important security feature, but
it has to be deactivatable.
- The remote access is done as an async operation because we don't want
it to block the startup in any way (for whatever reason). Also it
doesn't output errors if it fails to not be a bother (you don't
technically need internet access for an image program).
- We don't check at every startup. At each successful check, we save a
timestamp to prevent too frequent useless checks (I set it the timer
to a week or more for now).
(cherry picked from commit 506a0476f4)
The point will be for a packager to create a unique build ID to identify
the build or provenance. I also add a revision number so that we can
identify 2 builds from the same version/commit, same maker and platform.
It will also be used later to check for new versions (see "phone home"
feature #2584).
Separating autotools and meson commits for easy backport.
(cherry picked from commit 73c09ebb32)
In the Warp tool, handle the brush-outline and cursor prefernces
(namely, show-brush-outline, snap-brush-outline, and
show-paint-tool-cursor) similarly to the paint tools.
(cherry picked from commit 5cc9af09b0)
Add a new "Snap brush outline to stroke" toggle to the "Image
Windows" preferences page. When enabled, the brush outline in
paint tools snaps to the individual dabs while painting, instead of
following the cursor precisely (this is the existing behavior).
When disabled, the brush outline follows the cursor while painting
in the same way it does while not painting.
Disable the option by default. This seems to be what most other
programs are doing, and it does give paitning a smoother feel.
(cherry picked from commit 499834a1cb)
Change the default mode of the 3D Transform tool from CAMERA to
ROTATE. Canvas interaction is limited in camera mode, while
rotation is the main function of the tool.
(cherry picked from commit 251d758771)
Add a new GimpToolInfo::experimental boolean field, and mark
GimpNPointDeformationTool and GimpSeamlessCloneTool as
experimental. In gimp_tools_deserialize(), don't reject the file
if the only missing tools are experimental, but rather add them to
the passed container. In particular, this prevents us from
rejecting the default toolrc file when experimental tools are
enabled.
(cherry picked from commit 9f298f767f)
Now that painting is done in a separate thread, the display update
rate has a far smaller impact on it. Increate the GimpDisplay
update rate, which handles image updates, to 60 FPS, and the
GimpDrawTool update rate to 120 FPS. In particular, the latter
change makes brush-outline motion much smoother.
In the Foreground Select tool, use the drawable bounds (including
its offset) as the trimap buffer extents, which is now supported by
the rest of the code. This is both more streamlined, and works
around a GEGL bug (independently fixed by commit
gegl@378cd512c35fe2eb255492f90b503a67ab38d7a3), causing
gegl:matting-global to segfault when the drawable and trimap bounds
are differnet.
(cherry picked from commit 666d0845e1)
In GimpCanvasBufferPreview, take a strong reference on the preview
buffer, fixing a segfault in the foreground-select tool when
switching engines while the grayscale preview is active.
(cherry picked from commit ea864e2d5c)
... and gimp_gegl_mask_combine_buffer()
Allow the functions to work with buffers whose top-left corner is
not at (0, 0).
(cherry picked from commit 24534338e7)
While GimpPolygonSelectTool is active, don't let GimpSelectionTool
handle the Shift/Ctrl modifiers, which are handled by the tool
widget, unless they're used in combination with Alt, in which case
they're used to move the selection, instead of control the
selection mode.
(cherry picked from commit 0c917cb359b0ace43f82c68e36e64221ab1bcf91)
Add a new GimpSelectionTool::have_selection() virtual function,
which determines if the image has a selection (default
implementation), or if the tool will create one upon committing
(implemented by subclasses). Use this function in
gimp_selection_tool_oper_update() to determine the tool function;
in particular, don't use SELECTION_MOVE and SELECTION_MOVE_COPY
when there's no selection.
Override have_selection() in GimpFreeSelectTool, and return TRUE if
we have a polygon with three or more vertices, which will create a
selection upon committing.
(cherry picked from commit aeff0d6207463d0ed6f97e39e6b2450a60715863)
This commit removes the empty-dock-pane message, and instead
highlights all empty dockable drop-target areas once a drag
operation begins.
Add new gimp_dockbook_{add,remove}_callback() global functions,
which can be used to register a callback function to be called when
a dockable drag operation begins and ends.
Register such a callback in GimpPanedBox, and use it to highlight
all drop areas the widget handles. Furthermore, when the widget is
contained in a GtkPaned, make sure that it has a minimal size for
the duration of the drag operation, so that the drop area is
visible even if the widget is normally hidden.
In GimpToolEditor, update the visibiltiy-toggle state in response
to the corresponding tool-item's "notify" signal, rather than its
"shown-changed" signal, since the latter is not emitted when the
item's visibility changes while it's not shown.
(cherry picked from commit df19401fb3)
Add a new Gimp::tool_item_ui_list, which is a GimpTreeProxy over
Gimp::tool_item_list. This allows us to use either a hierarchical
or a flat tool list in the UI, by setting the "flat" property of
the new list.
Use Gimp::tool_item_ui_list in GimpToolPalette, so that the toolbox
layout is affected by this choice.
Add a "Use tool groups" toggle to the toolbox preferences, and bind
it to the "flat" property of Gimp::tool_item_ui_list.
(cherry picked from commit 3cda972100)
Add a new GimpTreeProxy container class, which proxies a
GimpViewable tree. The proxy has a dynamically-settable boolean
"flat" property, which controls if the tree hierarchy is preserved,
or if it's viewed as a flat list.
(cherry picked from commit 2caa518b19)
Add a new GimpContainer::search() virtual function, and a
corresponding gimp_container_search() function, which works
similarly to gimp_container_foreach(), except that the callback
returns a boolean. When the callback returns TRUE, the search is
stopped, and the current object is returned.
Implement GimpContainer::search() in GimpList.
(cherry picked from commit c4cc015c43)
Add a new read-only GimpToolItem::shown property, and a
corresponding GimpToolItem::shown-changed signal, which determines
if a tool item is visible throughtout the hierarchy, i.e., if it
and all its ancestors are visible. This replaces
gimp_tool_item_is_visible().
Use the new property and signal in GimpToolPalette and
GimpToolEditor, to simplify the code, and in preparation for a flat
toolbox view.
(cherry picked from commit ee9661237e)
In GimpToolManager, use a weak pointer for tracking the active tool
group, instead of taking a reference on it. This avoids
erroneously extending the group's lifetime, which can cause
problems with the tool-item hierarchy.
In GimpToolGroup, make sure that newly-added tools don't already
have a parent.
(cherry picked from commit 30d833d00f)
When the active tool of the tool group associated with the
currently-selected tool changes, we select the new active tool;
this is currently handled in GimpToolButton. Move this logic to
GimpToolManager, which already handles the other half of the
problem: updating the group's active tool when one of its tools is
selected.
Add a default toolrc file, installed in the sysconf dir, with a
more minimalistic tool layout using groups, inspired by Photoshop
(not identical, though, don't kill me! :)
Reduce the size of the toolbox color area, and make it square.
This allows for a narrower toolbox layout, which is more practical
now that we have tool groups.
Add a new GimpToolButton class, used for tool-buttons in the
toolbox, instead of implementing them directly in GimpToolPalette.
Each GimpToolButton is associated with a GimpToolItem, which can be
either an individual tool or a group.
When a tool button is associated with a group, it displays the
group's active tool, with an arrow at the corner. Clicking the
button selects the active tool, while clicking-and-holding, or
right-clicking, shows a menu of all the tools in the group.
Alternatively, the active tool can be changed using the scroll
wheel.
In gimp_button_menu_position(), position the menu at the same
height as the button, instead of half-way down. This is mostly a
stylistic choice, but it works much better for tool-button menus,
added in the next commit.
Move the logic for translating a tool identifier to a corresponding
action name to GimpToolInfo. It's currently only used in
tools-actions.c, but the next commits will use it in tool buttons.
Allow creating GimpToolInfo objects with a NULL menu label, and do
that for GimpOperationTool. The previous commit effectively
removed it from the Preferences tool editor, and this commit also
removes it from the action search.
Add tool-group support to GimpToolEditor, used to organize tools in
the Preferences dialog, including creating, rearranging, and
deleting groups. Also, major cleanup.
In the default implementation of
GimpContainerTreeView::drop_viewable(), handle the case where the
source and/or destination viewables are not direct descendants of
the tree-view's container, but rather of one of its subcontainers.
Allow calling gimp_scanner_new_string() with a NULL `text` and a
negative `text_len` (which is interpreted as 0), instead of
requiring `text_len == 0` in this case. This allows passing a
negative `text_len` unconditionally to infer the length, even when
the string may be NULL.
Add a new Gimp::tool_item_list list, in addition to
Gimp::tool_info_list. The latter may contain arbitrary tool items,
including tool groups, and is intended for use in the UI (namely,
the toolbox and the preferences tool editor).
In gimp-tools, use Gimp::tool_item_list for representing the UI
tool order (while still using Gimp::tool_info_list as a flat list
of all GimpToolInfo objects), and add support for saving and
loading tool groups to/from toolrc.
Introduce file-version tracking in toolrc, and drop its contents on
version mismatch, or when new tools are introduced. This is
slightly disruptive, but merging new changes with existing toolrc
files is non-trivial, and it doesn't happen very often.
Add support for a sysconf toolrc file, which is used if there's no
user toolrc file (i.e., on first use). If neither file is found,
the hard-coded flat tool order is used. This commit doesn't
provide a default toolrc file, but the next commits will.
Make the gimp-tools serialization and deserialization functions
public, for use in GimpToolEditor in the next commits.
... if not using unique names
Add a new GimpContainer::get_unique_names() virtual function, and a
corresponding gimp_container_get_unique_names() function, which
determines if the container uses unique names for its objects.
Override get_unique_names() in GimpList, to return the corresponding
property.
In gimp_container_deserialize(), don't merge new objects with
existing objects sharing the same name if the container doesn't use
unique names.
Add GimpToolGroup as a new subclass of GimpToolItem, representing a
collection of tools. The end goal is to display tool groups using
a single button in the toolbox.
Tool groups are not recursive: they can only contain individual
tools, not other groups. Each group has a single "active tool",
normally the most-recently-used tool of the group, which is
activated when clicking on the tool's button.
Add GimpToolItem as a common base class for toolbox items.
Derive GimpToolInfo from GimpToolItem, representing an individual
tool. The next commits add support for tool groups, represented by
an alternative subclass of GimpToolItem.
Most of the tool-info properties remain in GimpToolInfo, however,
GimpToolItem takes care of tool-item visibility.
Changed the reflection method to find the middle of the slice the
user is drawing on, and reflecting on that. This reflects the slice
in place, making it easier to rotate it to the intended location.
This fix preserves the order the dabs are drawn on the
slices, to be counterclockwise.
Fixed the brush transform, by setting the reflect output variable,
and calculating accordingly.
(cherry picked from commit ed6517f094)
When dowscaling an image (or a layer group), empty layer groups
can be discarded as a result of their new dimensions being too
small, since we're calculating their new dimensions according to
their fake 1x1 dimensions. However, these dimensions are purely an
implementation detail and shouldn't affect the result, and neither
do we show a warning for them.
Instead, simply avoid discarding empty layer groups.
(cherry picked from commit b99a2631ef)
Restrict last commit's workaround to layer groups only (which is
the only relevant case ATM), since it negatively impacts the warp
tool, which does rely on the ability to perform (accurate) partial
updates with filters to improve performance. It's only a temporary
hack anyway.
(cherry picked from commit 18870975b8)
When a drawable has filters attached, they may influence the area
affected by drawable updates. Currently, we ignore that, updating
the original region regardless. This can lead to drawable updates
not affecting the correct regions. This couldn't be triggered
until now, but since layer groups can now have a transform op
attached as a filter, updates to their sublayers -- which can
happen while the transform tool is active -- run into this problem.
Fix it for now by simply updating the full drawable region when the
drawable has filters. This is a very conservative approach -- we
don't even bother checking if we're only dealing with point
filters, as this change only influences transformed groups right
now. Ultimately, we need to rely on node invalidation to drive
updates, which takes this into account.
(cherry picked from commit 8be0e646bc)
Add a new "Preview linked items" option to the transform-grid
tools. When this option is enabled, together with composited
previews, the transform preview includes all linked layers/channels
when transforming a layer/channel. Note that paths aren't included
for now.
Ultimately, we'd probably want to cut down on the various preview
options and enable this by default, but let's make this optional
for now.
This commit also improves composited-preview clipping in some
cases.
(cherry picked from commit d24713349d)
Add a new GimpImage::linked-items-changed signal, which is emitted
whenever the set of linked items in an image changes.
(cherry picked from commit 7d6737fe9a)
In gimp_tile_handler_validate_buffer_set_extent(), suspend tile
validation while calling gimp_gegl_buffer_set_extent(), so that if
the call triggers clearing of partial tiles, these tiles don't get
unnecessarily validated.
(cherry picked from commit fcc1c3d380)
Using any clipping mode other than ADJUST is currently broken for
layer groups, since each layer in the group is clipped
individually, instead of clipping being applied to the group as a
whole. Ultimately, we should fix that, but for now, simply disable
clipping for layer groups, by overriding GimpItem::get_clip() to
always return ADJUST.
(cherry picked from commit 203bc9d893)
Don't disable color-to-alpha for grayscale drawable, since the
operation is applicable to grayscale images (in particular, it
doesn't add color where there was none), and since we no longer
distinguish between layers and channels according to the drawable
format when updating the filters actions.
... (used to add one automatically)
In GimpFilterTool and gimp_drawable_apply_operation(), use
gimp_drawable_filter_set_add_alpha() to add an alpha channel when
applying an operation that specifies "needs-alpha" to a drawable
that can have alpha.
Don't disable gegl:color-to-alpha (which has "needs-alpha") when
the drawable doesn't have an alpha channel, if one can be added.
In GimpFilterTool, move all the drawable-filter option setup to a
new gimp_filter_tool_update_filter() function, and call it whenever
the drawable-filter's options need to be updated. This avoids
duplicating logic in various places.
Add a new GimpDrawable::supports_alpha() virtual function, and a
corresponding gimp_drawable_supports_alpha() function, which
determine if the drawable supports an alpha channel. The default
implementation returns FALSE, and GimpLayer overrides it to return
TRUE.
The crop-to-result and crop-with-aspect transform-boundary
algorithms seem to consistently fail in some cases, and spit out a
warning, which can be too verbose if it triggers the debug dialog.
Demote the warning to a g_printerr(), with an eye to just dropping
these algorithms altogether.
(cherry picked from commit 0103fe2c19)
Add a "Synchronous preview" option to the transform-grid tools,
which renders the composited preview synchronously. This reduces
the lag for painting the preview, but can harm responsiveness for
bigger images, where rendering the preview is slow.
This is mostly an experimental option for now; it will become more
interesting once we have mipmap rendering.
(cherry picked from commit 52cd27f0d3)
In gimp_tile_handler_validate_validate_tile(), when validating a
partial tile with negative coordinates, make sure to adjust the
result of the modulo when calculating the tile-realtive coordinates
so that they're non-negative, to fix the tile-data pointer offset.
(cherry picked from commit d39822bcd7)
Add a "Composited preview" option to all transform-grid tools,
which displays the transform preview as part of the image
composition (i.e., as it would actually look when applying the
transformation, keeping the layer at the right position in the
stack, and with the right layer mode), instead of using an overlay.
This option is off by default, since it's generally slower to
render than an overlay, due to the lack of mipmap rendering. We're
also still using an overlay when transfoming a selection, and not a
whole layer.
In GimpTransformGridTool, when transforming a drawable, freeze the
drawable's preview while the tool is active, so that its ancestors'
previews don't get unnecessarily updated in response to hiding it.
In GimpDrawableFilter, add a
gimp_drawable_filter_set_override_constraints() function, which
allows bypassing certain constraints applied to the filter, based
on the drawable type and state.
Yes, this is a bit of a hack, added mostly as a quick-and-dirty way
to allow us to add filters to layer masks that affect their
bounding box, in preparation for composited transform previews.
Add an optional "format" parameter to gimp_drawable_merge_filter(),
which specifies the format to use for the output, possibly changing
the drawable's format.
In GimpDrawableFilter, add a gimp_drawable_filter_set_add_alpha()
function, which allows the filter to add an alpha channel to the
drawable when committed (by passing an appropriate format to
gimp_drawable_merge_filter()).
Change the default implementation of
GimpDrawable::get_bounding_box() to return the drawable source
node's bounding box, instead of the drawable's item bounds. This
allows filters to affect the size of all drawables, including, in
particular, layer masks.
Change GimpLayer's implementation of get_bounding_box() to return
the intersection of the layer's own bounding box, and the layer
mask's bounding box (if it has one), and update the layer's
bounding box when the mask is enabled/disabled, or when its
bounding box changes.
... by synchronously flushing the group's projection. This is
necessary for pass-through groups, since their projection is
normally flushed asynchronously.
(cherry picked from commit 7f84f10154)
In gimp:buffer-source-validate, invalidate the node in response to
GimpTileHandlerValidate::invalidated, added in the previous commit,
in addition to GeglBuffer::changed.
(cherry picked from commit bb8ee0e686)
Add a new GimpTileHandlerValidate::invalidated signal, which is
emitted when a region of the buffer is invalidated. This would
allow us to properly invalidate the graph in response; this
normally happens in response to GeglBuffer::changed, but this
signal is not emitted when a region is merely invalidated.
(cherry picked from commit 3ea391602e)
Add a "clip" property to GimpCanvasTransformPreview, specifying the
transform's clipping mode, and clip the preview accordingly.
In GimpTransformGridTool, sync the tool's clipping mode with the
preview's clipping mode.
(cherry picked from commit 7b2e6b7595)
Add a "Unified interaction" option to the 3D Transform tool, and a
corresponding "unified" property to GimpToolTransform3DGrid. When
active, all three interaction modes of the grid (camera, move, and
rotate) are available simultaneously, regardless of the active
dialog page. In this mode, the inner and outer regions of the item
are used for moving and rotation, respectively, and the vanishing-
point is controlled through through a handle.
(cherry picked from commit 30132fc2da)
In GimpToolTransform3DGrid, fix the test for determining which side
of the plane is facing the viewer, affecting the direction of
rotation when rotating around the local Z axis.
(cherry picked from commit bcaaa453c4)
When ordering tools according to an existing toolrc file (which
is always present in a pre-existing profile), preserve the default
placement of newly-added tools, instead of always adding them to
the bottom of the list.
(cherry picked from commit 58d04375c9)
... brush does not have transparency
In the PAINT_MASK_TO_COMP_MASK paintcore-loops algorithm, used when
painting incrementally, multiply the paint mask values by the paint
opacity. Previously, the paint opacity was ignored, breaking
various dynamics affecting the opacity.
(cherry picked from commit 9fe33702fb)
Always enter relative adjustment mode when right-clicking an
unfocused compact GimpSpinScale, instead of showing the context
menu, since it otherwise leaves little room to enter relative mode
in narrow spin scales. The context menu can still be activated for
focused spin scales.
In GimpSpinButton, adjust the scroll step in response to modifiers:
normal scrolling uses the step increment, Ctrl uses the page
increment, and Shift scales the step increment down by the ratio
between the page and step increments (up to the minimal precision
of the spin button).
This applies to all spin buttons used in GIMP, including spin
scales.
(cherry picked from commit ac8bf47fa6)
In gimp_gegl_apply_cached_operation(), use gint64 for storing the
total and processed pixel counts used for reporting progress, to
avoid overflowing when applying an operation to a large image.
(cherry picked from commit f1c448e0f4)
GimpSpinScale now always grabs focus in response to a button press
in compact mode. However, like before, the left button is always
used for absolute adjustment, even when pressed over the text,
instead of controlling the text cursor.
The right button is now used both for relative adjustment, and to
select the entire text. Alternatively, the same can be achieved
with Shift+left-button.
The middle button has no special function.
Regardless, if a button-press event over the text triggers a
context menu, this overrides any of the above.
In plug_in_compat.pdb, when wrapping an op node inside a graph, set
the op node as the graph node's underlying operation. This allows
gimp_gegl_apply_operation() to perform certain optimizations.
(cherry picked from commit e74994feaf)
In plug_in_compat.pdb, don't add child nodes to nodes containing an
op, since this turns them into graphs and discards the op.
Instead, add a new wrap_in_graph() helper function, which takes a
node op and wraps it in a simple "input -> op -> output" graph.
Use the graph as the container for child nodes, and as the node
passed to gimp_drawable_apply_operation(). (This is similar to
what we used to do before commit
afdd573136, except that we now pass
the parent node to gimp_drawable_apply_operation(), instead of the
op node).
(cherry picked from commit 8b7bafa43a)
Add a boolean "compact" style property for GimpSpinScale. When
TRUE, the widget uses a narrower layout, and the different upper/
lower-half behavior is gone. Instead, the behavior depends on the
mouse button used: left-click is used for absolute adjustment
(similar to the upper-half behavior), middle-click is used for
relative adjustment (similar to the lower-half behavior), and right
click is used for manual value entry (similar for clicking on the
text area).
Add a new "Compact sliders" toggle to the Interface prefernces, to
control the spin-scale style. Apply the style globally through the
themerc file, and update it when the option changes.
Use the compact style by default, because otherwise no one would
find it. Theming in GTK3 works differently, and spin scales in
master need more work regardless, so this stays in 2.10 for now.
Add a new 3D Transform tool, based on GimpToolTransform3DGrid,
added in the previous commit. The tool UI provides a notbook with
three tabs, corresponding to the three GimpToolTransform3DGrid
modes:
Camera - allows setting the primary vanishing point, as well as
the camera's focal length, expressed either directly, or as the
camera's angle of view, relative to the whole image or the
transformed item. By default, the vanishing point is aligned
with the item's center, and the angle of view is fixed relative
to the item; this essentially means that each item is transformed
using a local perspective, independent of its position and size
relative to the image. A global perspective can be achieved by
using a common vanishing point and focal length (or an image-
relative angle of view).
Move - allows moving the item using X, Y, and Z offsets.
Rotate - allows rotating the item using X, Y, and Z Euler angles.
The order of rotation of the different axes can be controlled by
a set of numbered buttons next to the sliders, and the rotation's
pivot can be controlled using a pivot selector.
Add a new GimpToolTransform3DGrid tool widget, subclassed from
GimpToolTransformGrid, which can be used to perform 3D
transformations.
The widget can be in one of three modes:
CAMERA - allows adjusting the primary vanishing point by moving a
handle.
MOVE - allows moving the object through dragging.
ROTATE - allows rotating the object through dragging.
By default, controlling the transformation through dragging applies
to the X and Y axes. Holding Shift (or setting the "constrain-
axis" property) restricts the motion to only one of the axes.
For the MOVE and ROTATE mode, holding Ctrl (or setting the "z-axis"
property) allows controlling the Z axis instead.
For the same modes, holding Alt (or setting the "local-frame"
property), applies the adjustments in the object's local frame of
reference, instead of the display's global frame of reference.
Add a boolean GimpTransformGridTool::dynamic-handle-size property,
which controls whether the handle sizes are adjustment dynamically
according to the grid's size, or remain fixed. This property is
TRUE by default, to maintain the current behavior.
In GimpToolTransformGrid, allow setting "inside-function" and
"outside-function" to a new NONE value, performing no
transformation when dragging the respective area.
GimpPivotSelector is a 3x3 grid of toggle buttons, used for
selecting a natural pivot position (e.g., for a transform) relative
to an item: its center, its corners, and the midpoints of its
edges.
The tool dialog of generic-transform tools (the Unified,
Perspective, and Handle Trasnform tools) shows the current
transformation matrix. Although we might as well show *something*
in the dialog (we can't get rid of it altogether, as it provides
the common tool actions), this information is probably meaningless
for most users, and isn't directly editable anyway.
Reduce the size of the matrix, to make it less prominent, and free
up some space.
Add a boolean 'compress' parameter to
gimp_transform_grid_tool_push_internal_undo(). When TRUE,
successive undo steps added rapidly are compressed into a single
step.
In the various subclasses, compress undo steps for dialog changes,
since we push an undo step for every intermediate change for those
(such as while dragging a spin-scale). In contrast, we only push
tool-widget undo steps upon button release, hence there's no need
to compress them.
In gimp_transform_grid_tool_push_internal_undo(), only flush the
image when undo/redo availability for the tool changes, instead of
for every undo step. This speeds things up when many undo steps
are pushed in succession, which usually happens when using the tool
GUI.
In GimpSizeEntry, the value corresponding to 0%, as per
gimp_size_entry_set_size(), may be non-zero. This works correctly
when using the size entry in percentage mode, but not when using
precentage as part of arithmetic.
Fix this by adding an 'offset' parameter to eevl's unit-resolution
callback, which can be specifies a constant value to add as part
of unit conversion, after scaling the converted value by the
conversion factor. In GimpSizeEntry, use this parameter to offset
percentages by their lower bound.
Add GRAY* to the list of supported image types.
(cherry picked from commit 38cccaac49)
(not really a cherry-pick, but nice to see the resp. commit from
master)
...format version 10.
Simply allow the parser to read version 10, seems to work
with the brushes in issue #2862.
(cherry picked from commit c39d8fde33)
Which is a linear transform of xyY that is more perceptually
uniform, and so well-suited for eventually adding chromaticity
diagrams to GIMP color tools. ACES documentation uses this color
space instead of xyY for showing chromaticity diagrams. Moving
forward I expect other venues also will start using Yu'v' as
the advantages over xyY chromaticity diagrams are fairly obvious.
(cherry picked from commit bb660c5821)
Adds a number of modifier keys to the layer dockable's new "Merge Down"
button to access further functions, and adds among them a new action to
merge visible layers using the dialog's last values, akin to those
accompanying the New Layer and Add Layer Mask dialogs.
Modifier keys are bound as follows:
Shift -> Merge layer group
Ctrl -> Merge visible layers
Ctrl + Shift -> Merge visible layers from last used values
The Merge Down button is kept sensitive even when the current layer
can't be merged down to allow access to these functions
(cherry picked from commit a11ada4ce2)
As they are both mutually exclusive and serve an almost identical
purpose, the "Merge down" and "Anchor Layer" are given mutually
exclusive visibility in menus, and the anchor button is replaced
with a merge down button in the Layers dockable whenever there is
no active floating selection
(cherry picked from commit f539fc78c0)
...MyPaint brushes dialog
In gimp_tag_entry_assign_tags(), don't add/remove tags while iterating
tag_entry->selected_items, because that might change the list. Instead,
make a temporary deep copy of the list and iterate the copy. Spotted
by Massimo.
(cherry picked from commit ff32fe9f5d)
Must call gimp_action_init() from gimp_action_impl_init() or the
signal handlers to update label and tooltip will ever be installed.
Found by Massimo.
(cherry picked from commit 45ad58dff4)
... property name validation.
Previous commit fixed the parameter name validation in core code. This
commit fixes the source error in the plug-in code.
... property name validation.
GLib tightened its GParamSpec name validation, as it used to only check
that the first letter was a letter, which triggered this issue, though
the crash could have also happened with the former lax rules too (commit
30e630c9df792cf36cdb1cceb3daefbde1dc898a).
I opened a merge request in GLib to make the validation code into a
public function. In the meantime, let's just copy-paste the validation
code into ours and when a plug-in attempts to create a procedure with
invalid parameter or return value names, GIMP will just output an error
and refuse to install the procedure instead of crashing.
See: https://gitlab.gnome.org/GNOME/glib/merge_requests/1302
As mentioned in issue #1777, exporting non-animated WebP images was
only keeping the current layer.
Mimick file-gif-save.c: display the encoding settings pop-up earlier
so that gimp_export_image() can merge the layers unless "As Animation"
is enabled. Call gimp_image_get_layers() directly in save_image() in
case the layers were merged (for clarity because layers are used only
for animations).
(cherry picked from commit 8f828d1899)
The second parameter should be GStatBuf*, which will be defined to be
the right struct depending on the actual platform. Using `struct stat*`
was good on Linux but was outputting warnings on other platforms (at
least on Win32).
(cherry picked from commit 6bc6a07b7e)
Actual patch contributor wants confidentiality to avoid leaking
proprietary information or whatever (I am not sure either what to be
scared of as it's all good and harmless to me, but let's respect the
request). See also #4246 for more details.
(cherry picked from commit 370499676f)
My previous test (commit 41285813a5) was a bit misinformed. So it turns
out bug #4185 is for all platforms and the broken libheif versions are
1.5.0 and 1.5.1 only.
So my new test (platform independent) is: prefer libheif versions with
profile support, except 1.5.x; then prefer lower versions without
profile support; and only as last resort accept 1.5.x versions (but
output a warning).
(cherry picked from commit f051e6d238)
Known bug in libmypaint dependency. It has been fixed in libmypaint
1.4.0, which we cannot hard require unfortunately (Debian testing still
at 1.3.0).
Still let's make add a warning so that packagers are aware of the issue
and update when possible.
(cherry picked from commit 5da252ca18)
Replace the "Heif >= 1.4.0" line in the summary output by a comment in
the "Heif" line explaining this is about profile support.
Also add a >= 1.6.0 test and output a warning for Windows and macOS (cf.
bug #4185).
(cherry picked from commit 41285813a5)
I am not touching the translation, only the formatting for the Keywords
field in desktop file. As requested by a translation comment, all
translations of this field need to end with semicolon too (without, we
get validation warnings).
(cherry picked from commit 053fbd7da5)
... or copied RGB channel
In gimp_drawable_merge_filter(), make sure the drawable's source
node is constructed before applying the operation. The
construction of the source node connects the drawable's filter
stack to the udnerlying source node (usually, the buffer-source
node), which we rely on when calling
gimp_gegl_apply_cached_operation(), since we pass
connect_src_buffer == FALSE. Otherwise, the operation is applied
to an empty input, instead of the drawable content.
(cherry picked from commit 0e29fc1b21)
In gimp_histogram_view_update_bins(), don't update the view's
range if there's no histogram or the histogram is empty, to avoid
discarding the existing range. Additionally, improve the range
readjustment when the number of bins changes.
(cherry picked from commit 0c899394b4)
We are running gimp_image_set_imported_file() when saving, with NULL to
drop the tie with the imported file. Let's only change the default
resolutions when we actually set an imported file.
Also set the `resolution_set` flag even when it doesn't change the
current values (hence no undo or signals), for instance setting from 300
to 300 PPI. In such case, even though nothing changes, the resolution
has to still be considered as explicitly set.
In the reporter case, any one of these 2 fixes is enough.
See also commit fef9b1d2a3 (set to 72 PPI as default for imported files
only) and commit a8f552da2f (set imported file to NULL).
(cherry picked from commit 417bf199c8)
I made the various static arrays in headers declared as extern and
defined in a separate implementation file, with additional size constant
when necessary (since G_N_ELEMENTS() cannot be used on partially
defined arrays).
Note that this is better than the original implementation, yet I am not
saying this is ideal either. I am not fond of such code organization and
think a better one could be done. But it would require to dive deeper
into this plug-in and I don't want to right now, nor have the time.
At least now it stopped shouting all these warnings!
(cherry picked from commit 31cbc7e0e6)
This cleans just a third of the warnings in this metadata plug-in. It is
a very bad practice to define static const strings in a header file like
this, especially if this header is included in several files. Let's make
these macros.
Also why are these header tags sometimes used with the const name (now
macros), sometimes directly with the string literals? I fixed some of
these, but more string literals are lying around.
Remaining warnings are similar, about const string arrays. If really we
want this, we should declare these extern and define them in a separate
implementation file. This whole plug-in should be really reorganized and
cleaned in depth.
(cherry picked from commit 024a919c77)
In the Bucket Fill tool, when using line-art mode, use a
GimpImageProxy as input for the GimpLineArt object, instead of
using the image direclty, when the line-art source is "all visible
layers". Set the proxy's show-all mode according to the active
shell, so that the line-art uses the full image projection,
including out-of-canvas regions, when in show-all mode.
(cherry picked from commit 43a1c33ecf)
... which corresponds to the shell's show-all mode. We'll listen
to its "notify" signal in the bucket-fill tool.
(cherry picked from commit 02654b0ac0)
In GimpLineArt, add support for arbitrary input-buffer extents,
by shifting/unshifting the input/output buffers before/after
passing them to the main algorithm, so that the algorithm keeps
working with buffers whose top-left corner is at (0, 0).
(cherry picked from commit bce96eb690)
In GimpImageProxy, implement the GimpPickable interface, so that
the proxy can be used as both a viewable and a pickable for the
image projection, with direct control over the show-all mode. This
will allow us to use a GimpImageProxy as input for a GimpLineArt.
(cherry picked from commit 0e02795128)
We're going to have GimpImageProxy implement GimpPickable, so that
it can be used as either a viewable or a pickable proxy for an
image.
(cherry picked from commit 8d8cc12f40)
Add an internal gimp_image_get_preview_format(), which returns the
format to use for preview buffers, and use it in both
gimpimage-preview and GimpImageViewable, to reduce duplication.
(cherry picked from commit 74009c8b1e)
In gimp_config_deserialize_fundamental(), cast integer token values
to the target value type *before* negating them, to avoid
performing unsigned negation, which can result in a positive value
when cast to the target value type (in particular, when the target
value type is float/double).
(cherry picked from commit 38fff3b6b3)
In particular, if the shebang is `#!/usr/bin/env lang` and we have not
registered a specific interpreter for `lang`, the system should leave
the env tool search the right interpreter for us. We only bypass env
when we set our own explicit interpreter.
(cherry picked from commit 9e844ae1d7)
Slight modification from master commit: not applying to
palette-to-gradient.py plug-in.
GTimeVal, as well as g_file_info_get_modification_time(), have been
deprecated in GLib 2.62. Use g_file_info_get_attribute_uint64()
instead.
(cherry picked from commit 549a606b2f)
Add an n_components parameter to gimp_histogram_clear_values(),
which allows to set the new component count when clearing the
histogram. This is useful to seed the histogram with the correct
number of channels, for display purposes, before starting an async
histogram calculation. We use this in GimpHistogramEditor, to
avoid resetting the view's channel back to "Value" each time the
active drawable changes.
(cherry picked from commit eb6f544c18)
In GimpHistogram, get rid of the "n-channels" property and
corresponding gimp_histogram_n_channels() function. The former
returned the actual number of channels, but this wasn't too useful,
as channel values may not be sequential; the latter returned the
number of components. Instead, add an "n-components" property and
a corresponding gimp_histogram_n_components() function, both of
which return the number of components. Furthermore, add a
gimp_histogram_has_channel() function, which determines if the
histogram has a given channel; this allows for simple testing for
channel availability, which was done wrong in various places.
Adjust the GimpHistogram code for the changes, and clean it up,
fixing a few bugs.
Adjust users of GimpHisotgram for the changes. In particular,
in GimpHisotgramView, fix the channel-availability test when
setting the view's histogram (which happens whenever the active
drawable's preview is frozen), to avoid erroneously swithcing the
view's channel back to "Value" when a non-RGB channel is selected.
(cherry picked from commit fc17f0ed0c)
Tested in a VM. Minimized window is properly deiconified and showed to
the front. Though a window in the back (not minimized) is not moved to
the front.
(cherry picked from commit 2f01751907)
Swapped arguments: height is passed to width. width is passed to height.
Please check the function in /app/core/gimpbrush.c at line: 606
void
gimp_brush_transform_size (GimpBrush *brush,
gdouble scale,
gdouble aspect_ratio,
gdouble angle,
gboolean reflect,
gint *width,
gint *height)
New images should obviously still default to the template pixel density
(defaulting to 300.0 PPI when no specific template is selected).
Loaded images though should use a more conservative default of 72 PPI,
first because this is what other software defaults to when no density is
set (so we should keep consistent when possible), and this is also what
the Exif standard (I checked both last version 2.32, and older 2.3)
recommends when no resolution is set.
Technically we differentiate a loaded from a newly created image by
whether or not an imported_file has been set. Of course, any explicitly
set resolution will always override whatever default.
(cherry picked from commit fef9b1d2a3)
… different layer size/location used.
We need to use the source coordinate space when generating the first
fill buffer, then transform to the target layer coordinate space when
applying the drawable filter.
(cherry picked from commit 16d9c1f00d)
In gimp_page_selector_add_frame(), if "gimp-frame" icon cannot be loaded
(which should not happen, but reality can always strike back!), we want
to abort from gimp_page_selector_add_frame() immediately.
Also as a consequence, its return value might be NULL, hence should be
freed with g_clear_object() instead.
This happened here because of broken meson rules (which didn't install
this icon) and ended up in forever looping errors when loading a
multi-page PDF (pages are shown in frames in a dialog):
> (file-pdf-load:12348): GdkPixbuf-CRITICAL **: 11:59:28.513: gdk_pixbuf_copy_area: assertion 'src_pixbuf != NULL' failed
(cherry picked from commit 9dcdf37ab3)
I had this warning when cross-building for Windows 64-bit:
> libgimp/gimpui.c:187:52: warning: passing argument 2 of
> 'gdk_win32_window_foreign_new_for_display' makes pointer from integer
> without a cast [-Wint-conversion]
> note: expected 'HWND' {aka 'struct HWND__ *'} but argument is of type 'guint32' {aka 'unsigned int'}
(cherry picked from commit cf6dae6f83)
See #3996.
This was a warning raised by the Coverity scan on one of the lines. I
fix also in the same time other arithmetics mixing int and double.
Better be thorough.
The specific warning was on:
> circ = 2.0 * G_PI * (private->width / 2)
where the division was integer, which was probably not intended. Of
course that error (display item only) was likely barely visible anyway,
still…
(cherry picked from commit c809e221ec)
Though the description of the POINTER type clearly tells of the new type
size, it was still refered as 32-bit only in this introductory text.
Let's fix this.
(cherry picked from commit 35f55ef07a)
Restore the behavior of gimp_gegl_apply_operation() prior to
11629fde66 when src_buffer is NULL:
keep the existing operation-node input, instead of using an empty
input. Unlike gimp_gegl_apply_cached_operation(),
gimp_gegl_apply_operation() doesn't have an explicit
connect_src_buffer parameter.
This fixes empty output when merging layers.
(cherry picked from commit 076d9b2a28)
In GimpFilterTool, don't provide a clipping option for layers with
no alpha channel, and always clip the result to the layer bounds,
since the extended regions of the result usually require alpha to
be meaningful.
Similarly to last commit, the ideal solution would be to
automatically add an alpha channel as necessary.
(cherry picked from commit 4b58e178a5a4206cd84ae6402a967862897f14bb)
Alawys clip a floating selection to its base layer, if the layer
has no alpha channel. This avoids arbitrarily filling the extended
regions of the layer with, or compositing the floating selection
against, black color.
This is a temporary solution. Ideally, we'd automatically add an
alpha channel to the layer as necessary.
(cherry picked from commit 7a8c79e7e75812d683430be163950b68a3d3498a)
In gimp_gegl_apply_cached_operation(), add a boolean
connect_src_buffer parameter, which determines whether to connect
the source buffer to the operation-node's input, or to use its
existing input. In gimp_drawable_merge_filter(), pass FALSE for
connect_src_buffer, so that the existing filter-node input is used.
This produces an equivalent result, however, it avoids invalidating
the filter node, and dropping cached data as a result. In
operations that cache larger areas than the ROI, this avoids
reprocessing already-cached data when processing the rest of the
operation.
Additionally, in gimp_gegl_apply_cached_operation(), use an empty
input for the operation if src_buffer is NULL and
connect_src_buffer is TRUE; previously, we'd use the operation-
node's existing input when src_buffer was NULL. Furthermore, crop
the operation-node's input to the destination rect when crop_input
is TRUE, even if connect_src_buffer is FALSE.
(cherry picked from commit 11629fde66)
When the bounding box of a floating selection changes, update the
bounding box of the associated drawable, since floating selections
are no longer clipped to the drawable's bounds in general.
(cherry picked from commit ec6bbd1937)
When attaching a floating selection to a layer, don't clip the
floating selection to the layer's boundary, and instead resize the
layer to include the entire floating selection when it's anchored.
As per the last commit, this can be prevented by locking the
layer's position.
(cherry picked from commit 64b979c2f3)
When applying a filter to a layer whose position and size are
locked, avoid resizing the layer to the result size in ADJUST mode.
We do this by always returning GIMP_TRANSFORM_RESIZE_CLIP in
gimp_item_get_clip() when the position is locked, and properly
updating the drawable-filter's clip mode, and the filter-tool's UI,
when the position lock changes.
(cherry picked from commit 6ed6cd78d8)
In GimpSourceCore, when "sample merged" is enabled, derive the
source pickable from the source drawable's image according to the
paint-core's show-all flag manually, instead of using
gimp_paint_core_get_image_pickable(), which uses the destination
image, and would therefore only work when the source and
destination images are the same.
In GimpSourceTool, override GimpPaintTool::paint_prepare() to set
the paint-core's show-all flag according to the source display,
rather than the destination display.
(cherry picked from commit aa02f1f35c)
... which is called when starting to paint, before the tool's
paint-core is started, allowing the tool to configure the core.
Move the call to gimp_paint_core_set_show_all() to the default
implementation of paint_prepare().
(cherry picked from commit ffd6c2eda2)
In gimp_gegl_apply_cached_operation(), when applying a non-point
filter with the same source and destination buffers, render the
result to a temporary buffer to avoid chunking artifacts. We'd
previously duplicate the source buffer instead (with commit
35729ee02a erroneously copying the
cached results to the source/destination buffer before duplicating
it, causing this bug), but we now use a temporary result buffer
instead; this has roughly the same overhead, but would allow us to
keep the original operation-node input when committing a drawable
filter in a future commit, which would avoid dropping any cached
data.
(cherry picked from commit 88c6f8296d)
Add internal gimp_image_{freeze,thaw}_bounding_box() functions, and
use them in gimp_image_reorder_item() to avoid updating the
bounding box multiple times while moving a layer across group
boundary, to prevent flickering.
(cherry picked from commit a6ebbfe317)
In GimpImage, update the image's bounding box in response to the
layer container's "add" and "remove" signals, instead of during
gimp_image_{add,remove}_layer(), so that the bounding box is
properly updated when moving an existing layer inside/outside of a
layer group, instead of only when adding/removing a new layer.
Even though moving a layer across group boundary doesn't change the
overall image bounding box, it does change the group's bounding
box, affecting the image bounding box. It's therefore necessary to
update the image bounding box again when the layer is re-added to
the layer stack, so that the bounding box doesn't get stuck in an
intermediate state.
(cherry picked from commit 2a753170b9)
Though it may have started as an unofficial document, it is clearly now
an official one (which should be obvious since it is in our source
repository, but apparently some people get misled by the historical
"Status" text to think this to be somehow unofficial).
So first of all, change the s/official/unofficial/ mention.
Secondly, add a small paragraph explicitly telling that the document is
complete (and meant to be), to the best of our knowledge. This document
is a detailed, full and exhaustive written "specification" of the XCF
format up to GIMP 2.10.x (even though the normative spec is still the
code itself). Now we are humans, we may have missed something, and if
so, this is just to be considered as any other bug, and reported to us
nicely to be fixed.
(cherry picked from commit 80e2e0a508)
Pass the swap-compression option set in the preferences down to
plug-ins, so that they use the same swap-compression algorithm as
the main app.
(cherry picked from commit 5cc289b642)
Add a new "Swap compression" option to the preferences, allowing
explicit control over the tile-swap compression algorithm.
Previously, control over swap compression was only possible through
GEGL command-line options/environment variables. Since the GEGL
API to list all available compression algorithms is still private
for now, we currently only list the three predefined compression
levels -- "best performance" (the default), "balanced", and "best
compression" -- and a "none" option, to disable compression
altogether. Selecting a custom compression algorithm is possible
by entering its name manually.
(cherry picked from commit 1664ecbf1d)
When in "show all" mode and canvas padding is disabled, have the
"layers-new-from-visible" action create a new layer from the full
image content, rather than just the canvas content.
(cherry picked from commit e7479cad47)
... which is similar to gimp_display_shell_get_pickable(), however,
it returns the projection, rather than the image, only when
gimp_display_shell_get_infinite_canvas() is TRUE, i.e., when the
shell is in "show all" mode *and* canvas padding is disabled.
(cherry picked from commit 71f42f6675)
In GimpRectangleSelectTool, when creating the rectangle widget as a
result of clicking inside an existing selection, update the
selection at the click, so that the tool's effects are applied
immediately, without having to further modify the selection.
(cherry picked from commit 7d2e872f4f)
In GimpBufferSourceBox, dup the selected buffer (and flush the
pickable to make sure it's fully rendered) instead of using it
directly in the source node. This avoids chunking artifacts when
the buffer's content depends on the filter output, such as when
using the affected layer, or a dependent projection, as input.
(cherry picked from commit 9f85efd825)
I wrote down the wrong option name (based on some Gaussian Blur specific
option). My mistake was to make a quick check in GIMP itself instead of
properly looking at the relevant commit message and code change.
Thanks to Sabri Ünal for raising this issue.
(cherry picked from commit 46e96a413d)
So many exciting changes in 2.10.14, it's hard to choose what to list,
since AppData notes need to stay short. :-)
(cherry picked from commit 8cdcaa4ef1)
and "Mention Show All option in the appdata changelog".
This reverts commit 57f5861ec4
and commit f203e92aa2.
The master AppData file is the one in master branch and should be kept
in sync. Even for 2.10.x release, this should have been pushed to master
then cherry-picked to gimp-2-10 (or the opposite as long as both
branches are synced).
Now I need to revert these to fix branch divergence. I will merge back
the wording by prokoudine in a later commit.
See equivalent commit ccc8224aa9 in master
(couldn't cherry-pick as code changed too much with new API obviously).
Let's also hide these procs even in gimp-2-10, because that's how much
these don't really make sense for a core plug-in IMO.
Commit 283ec1da0f previously pushed had some coding style bugs, which
unfortunately couldn't be fixed before pushing because the platform
doesn't allow it and the original contributor is not available lately.
Let's fix these.
(cherry picked from commit 8fa7b5bc74)
Add an option to keep the normal canvas padding in "show all" mode,
instead of extending the checkerboard pattern indefinitely. This
is useful when wanting to show the image content beyond the canvas,
while still keeping the focus on the canvas; further commits will
extend this mode to behave in more view-related cases as if "show
all" wasn't enabled.
Add a new 'View -> Padding Color -> Keep Padding in "Show All"
Mode" toggle, which controls this behavior, with a corresponding
default-value option in the preferences, under "Image Windows ->
Appearance".
Add a new mnemonic-clashes tool, which checks for mnemonic clashes
in menus. This tool can be invoked directly from the shell. It
takes an optional parameter which limits the search to a specific
type of menus, according to their xml tag (in particular, "menu"
for regular menus, and "popup" for popup menus).
(cherry picked from commit a2a7fc993c)
... after commit 2c9a8a567b. Don't
use the same function as a handler for GimpContext::display-changed
and GimpContext::image-changed -- their signatures are different.
(cherry picked from commit 1b3c1fb9cb)
In GimpNavigationEditor, make sure to clear the editor's shell when
the last image is closed, even though the corresponding display is
stil alive, so that we don't needlessly extend the lifetime of the
image. This is necessary after the recent GimpImageViewable
changes, since the editor now (indirectly) holds a reference on the
image.
(cherry picked from commit 2c9a8a567b)
When exporting to a format that supports layers, but doesn't
support layer masks, merge layer groups with a mask before applying
their mask, since masks can't be applied to layer groups.
(cherry picked from commit 643279bd31)
In gimp_group_layer_mask_changed(), avoid recalculating the group's
bounding box if it hasn't been calculated yet, since, not only is
this unnecessary in this case, but it causes the group's mask to
be erroneously clipped upon duplication, when set by
gimp_layer_duplicate() while the group is still empty.
(cherry picked from commit 184762cd81)
Add action labels missing after replacing stock items with icon names
and replace "<control>" shortcut designation with "<primary>"
(cherry picked from commit 32afd4cb3e)
... by adapting GimpPerspectiveClone to handle buffers with
arbitrary extents. Note that the tool doesn't seem to work well in
"sample merged" mode to begin with, but this is unrelated.
(cherry picked from commit 19c693a937)
... by using gimp_paint_core_get_image_pickable() in
GimpSourceCore, and adapting it to handle source buffers with
arbitrary extents.
(cherry picked from commit c5bf595fe6)
GimpPaintCore operates indipendently of a display, and hence needs
to be explictly told when operating in "show all" mode, affecting
the result of paint tools operating in "sample merged" mode. Add
gimp_paint_core_set_show_all() for that purpose, and call it,
passing the current display's "show all" mode, in GimpPaintTool.
This controls which pickable (the image itself, or its projection)
is used as the sampling source, as per
GimpPaintCore::saved_proj_buffer, and as returned by the new
gimp_paint_core_get_image_pickable() function.
(cherry picked from commit 2523808e4a)
In the bucket-fill tool, allow using the tool outside the canvas
bounds with "sample merged" active in "fill similar colors" mode,
when the current display is in "show all" mode. Additionally,
ignore "sample merged" in "fill whole selection" mode, on which it
has no effect.
(cherry picked from commit 17f8cff6f6)
paste as brush, paste as pattern, select to new brush, select to new pattern
fill selection outline, fill path, stroke selection, distort, rounded rectangle
indexed color conversion, merge visible layers, new guide, new guide (by percent)
image properties, newsprint, fractal explorer, sample colorize, new layer
metadata editor (just a button), spyroplus (only common buttons)
Update the image-projection priority rect to the current display's
viewport when the display becomes active, so that the right region
is rendered first when switching between different displays of the
same image.
(cherry picked from commit 582930aa61)
In the transform tools, when transforming the entire image in show-
all mode, don't crop the preview and the transform bounds to the
size of the canvas.
Add a show_all parameter to gimp_image_pick_color(), which, when
TRUE, allows picking colors outside the canvas bounds in sample-
merged mode. Forward the display's "show all" mode through this
parameter where applicable (in particular, in the color-picker tool
and the pointer dockable).
When the image's alpha channel is invisible, paint regions outside
the image contents as black, instead of using a checkboard pattern.
This is especially notable when viewing the image in "show all"
mode.
... to avoid unnecessarily updating their previews while dragging,
and, in particular, to avoid updating the image's GimpImageViewable
size in show-all mode.
In GimpNavigation{Editor,View}, show the full image contents when
the corresponding display is in "show all" mode. Additionally,
when the display's "show canvas boundary" is active, show the
canvas boundary in the navigation view as well.
Add a new GimpImageViewable class, which acts as a proxy viewable
for an image. Unlike the image itself, whose preview is always
restricted to the size of the canvas, a GimpImageViewable provides
a show-all property, which controls whether the preview includes
the full image contents. We're going to use GimpImageViewable as
the source viewable for GimpNavigationView.
Add a "show canvas boundary" display option, and a corresponding
"View" menu item and default-apperance preferences option. When
enabled (the default), the canvas boundary is shown as an orange/
black dashed line in "show all" mode.
In "show all" mode, the image is thought to be "infinite"; this
commit improves the overall scrolling/zooming behavior in this mode
according to this assumption. In cases where a specific image size
is needed (e.g., for the scrollbar bounds, fit-image-in-window,
etc.), the image's full bounding box is used; however, in cases
where a center point is needed (e.g., for the zoomed-out scrollbar
bounds, center-image-in-window), the canvas center, rather than the
bounding-box center, is still used.
... which specifies whether to clip the viewport to the canvas
(previously, it would always be clipped). Use the appropriate
value in all callers, depending on the shell's "show all" mode. In
particular, this commit avoids clipping the image projection's
priority rect to the canvas in "show all" mode.
Add a "show all" mode to GimpDisplayShell, controlled through a
corresponding "View -> Show All" menu item. When enabled, the
entire image content is displayed, instead of cropping the image
to the canvas size. More generally, the display behaves as if the
canvas were infinite. The following commits improve the overall
behavior in this mode.
Add a prefernces option to control the default "show all" state.
In GimpImage, make sure the image's pickable interface keeps
behaving as before (i.e., restricted to the canvas size), even when
the image is in "show all" mode. In contrast, the image's
projection, when used as a pickable, *is* affected by "show all".
... which invalidates the entire image. This replaces all calls to
gimp_image_invalidate() with the full canvas size, since the image
content can now be larger than the canvas.
Add a "show all" mode to GimpImage, which, when active, causes the
image projection's bounding box to be adjusted dynamically to the
combined bounding box of all layers and the canvas. This mode is
controlled through the new gimp_image_{inc,dec}_show_all()
functions, which should be called by the display; a corresponding
display toggle will be added in the following commits.
Note that from the user's perspective, "show all" is a display
mode, rather than an image mode. The GimpImage "show all" mode is
therefore merely an implementation detail, and shouldn't have any
effect on displays that don't use "show all" mode, or the PDB.
The ability to use the image with or without taking its "show all"
mode into account will be facilitated by the next commits.
In GimpProjection, avoid erroneously invalidating the projectable's
preview when flushing the projection and there's nothing to be
flushed, if the chunk renderer is still running, and hence the
projection is not fully rendered yet.
In gimp_gegl_buffer_set_extent(), clear the full now-out-of-bounds
region of the buffer, instead of only full out-of-bounds tiles;
however, we still make sure to clear full tiles, instead of partial
tiles, as much as possible. This prevents (parts of) the old
content of the buffer from showing when it's enlarged again. This
is especially relevant for the image projection, once we add
support for a dynamically-expanding canvas in the following
commits, since the projection of a reexpanded buffer can be
temporarily rendered to the display before it's fully
reconstructed, exposing parts of the old content.
Fixes the error:
> Critical error: gimp_line_art_thaw: assertion 'line_art->priv->frozen'
This may happen in cases when we didn't actually freeze the line art at
pointer click, because we were in an invalid case (for instance,
clicking out of selection), hence we must not thaw the line art either
at button release.
(cherry picked from commit 6391b2bcff)
In GimpProjection, when the projectable's size changes, while its
offset remains the same, simply update the projection buffer's
extent, instead of allocating a new buffer and copying the contents
over.
(cherry picked from commit 1577174739)
... which sets the extent of a buffer with an assigned
GimpTileHandlerValidate, clipping the dirty region to the new
extent.
(cherry picked from commit b4ee9ff055)
.... as a drop-in replacement for gegl_buffer_set_extent(), which,
in addition to setting the buffer's extent, clears any now-out-of-
bounds tiles, to free memory.
(cherry picked from commit 90610ac87e)
Something during the port to gimp-drawable-edit (commit
233ac80de1) broke add-bevel.scm when
the thickness is high enough for the selection to become empty.
Add an explicit check for a selection while constructing the bump-
map layer.
(cherry picked from commit 21649c5eaa)
Change the tooltips of the "Image/Layer -> Transform -> Arbitrary
Rotation..." to make the two actions distinguishable in the action
search dialog, similarly to the other image/layer transform
actions.
(cherry picked from commit 9582cf7717)
Add a gimp-rotate-image-arbitrary action, and a corresponding
"Image -> Transform -> Arbitrary Rotation..." menu entry, which
activates the rotate tool in image mode (similarly to the
corresponding action for layers).
(cherry picked from commit 8bff415f59)
... so that the original transform-type of the rotate tool is
restored once the layer is rotated. Additionally, make sure to
set the tool's transform-type even if it's already active.
(cherry picked from commit 52ad37a2aa)
... which temporarily changes the transform-type of the tool,
restoring the original type once it's halted. To be used when
activating a transform tool through an action for a specific
transform type.
(cherry picked from commit f651db52fb)
Add a new "Image" transform type to the transform tools, in
addition to the existing "Layer", "Selection", and "Path" transform
types. The "Image" mode transforms the entire image, rather than a
single item. In tools with a preview, the preview shows the
transformed image projection. The clipping mode controls how the
canvas is clipped during the transform; in particular, the ADJUST
clipping mode resizes the canvas to fit its transformed size.
(cherry picked from commit e4990bee7b)
In GimpCanvasTransformPreview, use a GimpPickable, instead of a
GimpDrawable, as the preview source, so that we can use it with the
image projection, rather than just with drawables.
(cherry picked from commit 6023f97509)
... which controls whether or not the image is rendered by the
shell. We'll use this to hide the image while showing its
transform preview in the next commits.
(cherry picked from commit 539d666ae2)
Add a new gimp_image_transform() function, which transforms the
entire image, including all layers, channels (including selection
mask), vectors, guides, and sample points, according to a
transformation matrix. The canvas is resized according to the
clip_result parameter, the same way drawables are resized during
transformation; the layers are resized using ADJUST mode
regardless.
(cherry picked from commit c45f1b4148)
... which takes the symmetry axis as a parameter, instead of hard-
coding the axis to the middle of the image, and which additionally
takes the clipping mode as a parameter, controlling whether to clip
or resize the canvas. Note that the actual canvas size never
changes, but it may be offset when flipped around an off-center
axis, without clipping.
Implement gimp_image_flip() in terms of gimp_image_flip_full().
(cherry picked from commit ae080f06f9)
In the various PDB transform functions, avoid erroneously creating
a floating selection when transforming the image mask, and rather
transform the mask normally.
Remove the special clipping-mode handling for channels throughout
the transform (and drawable-filter) code, and rather use
gimp_item_get_clip(), added in the previous commit, instead. As
mentioned in the previous commit, we only modify the clipping mode
in top-level code, while having lower-level code use the clipping
mode as-is. This not only hides the actual clipping-mode logic
from the transform code, but, in particular, allows code performing
transformation internally to use arbitrary clipping modes.
Also, this commit fixes a bunch of PDB bugs all over the place :)
Add a new GimpItem::get_clip() virtual function, and a
corresponding gimp_item_get_clip() function, which return the
actual clipping mode to be used when transforming (or applying a
filter to) a given item, given the original clipping mode. This
applies only to whole-item transformations (i.e., when not creating
a floating selection), and should be used by the top-level code
applying the transformation, rather than by the actual
transformation code, so that the item can be transformed using a
different clipping mode internally.
Provide a default implementation that simply returns the input
clipping mode, and override for GimpChannel (to always return CLIP)
and for GimpVecotrs (to always return ADJUST).
(cherry picked from commit d5cdcc6c02)
In gimp_palette_mru_add(), if the added color doesn't match an
existing color, don't look for two duplicate existing colors (which
has quadratic complexity), since there shouldn't be any under
normal circumstances (as we're not adding duplicates to begin
with).
(cherry picked from commit e60829767e)
My previous commit was bugged. Fix it and simplify the code a bit. No
need to check for existence for non-versionned include directory on
Windows. Just add the non-versionned dirs at the end, without other
condition that the target platform being Windows. This way, whether the
headers are installed in the versionned or non-versionned dirs, they
will be found.
In GimpPaintbrush, calculate grad_point in
_gimp_paintbrush_motion() independently of any stroke, and pass
its value down to GimpPaintbrush::get_paint_params() at each
stroke, so that the color is the same for all strokes, even when
using a color/random dynamics.
(cherry picked from commit 95429ad704)
In GimpFilterTool, add a new "clipping" option, which can be either
Adjust or Clip. This option is controllable for layers, when
there's no selection mask.
When set to Adjust, which is used by default, the filter's output
may extent past the drawable's boundary, and the drawable will be
resized to match the output when committed.
(cherry picked from commit eaec9443c3)
In GimpDrawableFilter, add a new gimp_drawable_filter_set_clip()
function, which controls whether the filter clips the result to the
drawable's boundary, or extends it past it. The latter is only
possible for layers, when the selection mask is empty.
(cherry picked from commit b7f53262fc)
Add a new "clip" parameter to gimp_drawable_merge_filter(). When
set to FALSE, the function resizes the drawable to the bounding box
of the filter's output, instead of clipping the output to the
drawable's boundary.
(cherry picked from commit 89a9cf7e49)
In gimp_gegl_apply_cached_operation(), copy the cached results to
the destination buffer *before* reconnecting the operation node, as
this may cause the cache to be cleared (see commit
gegl@4347255cd9d5031e6757c70fdde5c63539d5f508).
(cherry picked from commit 35729ee02a)
... similarly to gimp:layer-mode, however, assume the destnation
(backdrop) is not included when the layer's opacity is 1, and
there's no mask.
(cherry picked from commit 998f89e3cb)
In GimpGroupLayer, when recalculating the group's size as a result
of a change to one of the child layers (now including in response
to a child layer's GimpDrawable::bounding-box-changed signal),
calculate the group's bounding box (the bounding box of all its
child layers' bounding boxes) alongside its logical bounds. Like
in GimpLayer, use the logical bounds as the bounding box if the
group has a mask.
This bounding box is passed to the group's projection, via
GimpGroupLayer's GimpProjectable::get_bounding_box()
implementation, resulting in a buffer whose extent is the same as
the bounding box.
(cherry picked from commit ad1f3d20fb)
In GimpProjectable, replace gimp_projectable_get_size(), which only
returned a width and a height, with
gimp_projectable_get_bounding_box(), which returns a full
rectangle. This allows projectables to have an arbitrary bounding
box, not limited to a (0, 0) top-left corner.
Adapt GimpProjection, creating a buffer with corresponding extent
to the projectable's bounding box.
Adapt GimpImage and GimpGroupLayer.
(cherry picked from commit 8ff43942d6)
Implement GimpDrawable::get_bounding_box() for GimpLayer, by
returning the bounding box of its source node. If the layer has a
mask, we simply return its logical boundary, since the layer can't
extend past the mask.
(cherry picked from commit 7a05d15f7e)
Maintain the bounding box of drawables (i.e., the bounds of their
actual rendered content) separately from their logical boundary (as
shown in the UI).
The bounding box is calculated through the new
GimpDrawable::get_bounding_box() virtual function, which has a
corresponding gimp_drawable_get_bounding_box() function; the
default implementation simply returns the drawable's logical
boundary. The bounding box is specified in drawable coordinates,
i.e., it's not affected by the drawable's offset.
The bounding box is recalculated through
gimp_drawable_update_bounding_box(), which should be called
whenever a change may affect the bounding box (for example, when
setting a new buffer, as done implicitly by GimpDrawable's
::set_buffer() implementation, or when a drawable filter's
properties change, as will be done by GimpDrawableFilter in a
following commit). When the bounding box changes, the affected
regions of the drawable are updated, and the
GimpDrawable::bounding-box-changed signal is emitted.
When gimp_drawable_update() is called with negative width/height
values, the entire drawable's bounding box is updated, rather than
only its logical boundary.
Likewise, GimpDrawableStack and GimpLayerStack are adapted to use
the bounding box, instead of the logical bounds, when updating the
drawable's area.
(cherry picked from commit 153cb33eec)
In GimpDrawable::set_buffer(), and the corresponding
gimp_drawable_set_buffer_full() function, take a bounds rectangle,
which specifies both the drawable's new offset and its new size,
instead of only taking the new offset. In
gimp_drawable_real_set_buffer(), set the item size according to the
rect dimensions, instead of the buffer dimensions. The rect's
width/height may be 0, in which case the buffer's dimensions are
used.
Adapt the rest of the code.
We do this in preparation for maintaining the drawable's bounding
box separately from its logical bounds, allowing the drawable
content to extend beyond its bounds.
(cherry picked from commit 3afdd7c5c2)
... as a drop-in replacement for gegl_buffer_dup(), which COWs all
tiles of the source buffer, including ones that aren't fully
included within buffer's extent.
(cherry picked from commit 5798cefe1b)
In gimp_gegl_buffer_copy(), assume that the area outside the abyss
is empty, and so, when the abyss policy is NONE, allow data otuside
the source/destination abyss to be copied, by temporarily modifying
the abyss. This allows tiles that aren't fully contained within
the abyss to be COWed, unlike gegl_buffer_copy(), which has to be
more general.
(cherry picked from commit 69ce5e7e02)
The latter is broken and doesn't guarantee a decimal point with the
current bug. Also, g_ascii_dtostr() doesn't need the format parameter
and produces nicer output.
(cherry picked from commit c0fb66254e)
A number without a decimal point can be put into a gdouble just fine,
no need to refuse them. Moreover, g_ascii_dtostr() serializes doubles
without fractional part without a decimal point, and we are soon going
to use it.
(cherry picked from commit 2c97bc8327)
In gimp_gegl_apply_[cached_]operation(), use a longer iteration
interval (resulying in bigger chunks) when processing the op, than
the iteration interval used for rendering the projection. In
particular, use an even longer interval when processing area
filters, since their may be particularly sensitive to the chunk
size (see, for example, issue #3711). Likewise, use the asme
longer interval when not showing progress indication, since we
don't need to stay responsive in this case (but don't avoid
chunking altogether, to reduce the space required for intermediate
results).
This allows us to process an op faster when committing a filter,
while still remaining responsive (if overall slower) during
preview.
(cherry picked from commit 5a500b4a12)
... which determines if a node is an area filter operation. If the
node is a meta op, we conservatively return TRUE, as it may involve
an area-filter op.
(cherry picked from commit f6c4e4912a)
Add an assigned-threads variable to the dashboard's misc group,
showing the number of worker threads which currently have work
assigned. See commit
gegl@fc532f06773bd292c86abee31ac18f62e26d39df.
(cherry picked from commit e92732f7cf)
When translating a layer group, avoid separately updating the
original area of the child layers before translating them (as per
the fix to issue #3484), as this results in quadratic time
complexity w.r.t. to the maximal subgroup nesting level. Instead,
simply defer the updating of the group's offset until *after*
translating the child layers, so that their original area isn't
clipped by the parent, while their new area is still properly
updated even if the parent's size changes (see comment in code).
(cherry picked from commit ebb3ec4925)
The librsvg API was being called in an incorrect order. One cannot
call rsvg_handle_get_dimensions() until after rsvg_handle_close() is
done.
(cherry picked from commit b2027c40b7)
Improve my previous commit: I added babl_init|exit() for
"file-pdf-load-thumb". But these was actually also missing from
non-interactive calls to "file-pdf-load", since the initialization was
done as part of gimp_ui_init() so far.
Just run them down the call stack around the needed part. It's not a
problem if it's called double (for the interactive code path).
(cherry picked from commit 443c171f8d)
This is run as part of gimp_ui_init() in the normal "file-pdf-load"
calls, but such calls have been forgotten for the thumbnail load
procedure.
Also the GimpRunMode is only a parameter in "file-pdf-load". For
"file-pdf-load-thumb", the first parameter is directly the filename. The
fact it might have used to work is chance as it were only tested against
GIMP_RUN_INTERACTIVE, which is 0, so the test would end up FALSE, which
is what we want for thumbnail loading. Anyway now we get a proper call
(thumbnail loading always considered non-interactive).
(cherry picked from commit e0a24a27de)
Add an active-thread variable to the dashboard's misc group,
showing the number of active worker threads. See commit
gegl@6a3a6314d4d4cd668e0f6164afc0fde8b9c7c001.
(cherry picked from commit 2cc77e6927)
In gimp:gradient, fix dithering to correspond to how we actually
round float values to 8-bit. In particular, this avoids
introducing noise when a component is fixed at 0 or 1 along a
segment.
(cherry picked from commit e22fcc8942)
carve-it.scm, chrome-it.scm: apply slightly modified patch from Carol
Spears which replaces hardcoding round brush names by creating a brush
on the fly and setting its radius.
Also fixed both scripts to not use deprecated color API which is
even completely gone from master.
(cherry picked from commit 3d049f565a)
This improves commit bbd5ebbe8a. Several parameters did not need to go
inside draw_layer(). In particular this function should not take care of
filling return values on errors. It should just return a success boolean
with a GError which is processed on the main function. This also allows
proper shortcut to end the loop earlier on the first error.
Also the layer index parameter does not need to be a pointer since it
never requires updates.
Finally declare variables in smaller scopes for cleaner code.
(cherry picked from commit 5b2d89f794)
Added a recursive loop to draw layer children in layer groups. Text
layers in layer groups are now exported correctly.
(cherry picked from commit bbd5ebbe8a)
Whereas normal layers of dimension 0x0 are definitely broken, group and
text layers depend on their contents, which will be able to resize the
layer appropriately and fix whatever rendering. This commit allows to
salvage such layers, hence make XCF loading even more resistant to
certain form of file corruption.
This commit (and the previous one) are not theoretical but the result of
discovering some old corrupted file, with an empty group of size 0x0
(saved by GIMP itself, because of some old bug). Rather than destroying
these layer groups, this just allows us to reopen them without any kind
of loss!
(cherry picked from commit 06be074650)
If the problem occurs at one of the first layer, we may end up loading
nearly nothing even though there may be a whole lot of other data in
good state. So instead keep track of the number of failed layer and
channel loading to still display an error popup at the end, because we
still need to alert the user something went wrong. Yet damages are
limited.
Also make sure that layer paths are fixed when some layers could not be
loaded, hence stored paths end up wrong.
(cherry picked from commit 2045fdd2a3)
Make the returned values of g_list_length() a gint to avoid implicit
type conversion converting a possibly negative integer numberator into
unsigned int (which ends as a huge unsigned int instead of being
negative).
Found by Massimo!
(cherry picked from commit a6ad02a60a)
gsapi_new_instance() now expects a pointer to a NULL-initialized
pointer. Initialize "void *instance" with NULL. Found by massimo.
(cherry picked from commit bbcc7ca5f5)
- move use of deprecated function to very few places
- indentation, formatting
- fix insane variable names, it's now much more readable
(cherry picked from commit 8ac6ec2a00)
by plain pixel region code, copied right out of gimpregioniterator.c.
Makes porting to GEGL easier and GimpRegionIterator unused.
(cherry picked from commit 775abb03f3)
...for gimp_context_set_antialias(antialias)
Mention gimp_context_set_antialias() in the stroke docs, and mention
the stroke functions in the antialias docs.
(cherry picked from commit 7a589951c9)
When the remote volume can't be mounted by GIO, continue as if the
file procedure couldn't handle URIs and try downloading/uploading the
file manually.
(cherry picked from commit f370596d04)
Change all action callbacks so they can be invoked by a GAction:
- add GimpActionCallback typedef:
void (* cb) (GimpAction*, GVariant*, gpointer)
- change all action callbacks to the GimpActionCallback signature
- add "gimp-activate" and "gimp-change-state" signals to GimpAction,
with the same signature as the resp. GAction signals
- remove all other custom action signals and only use the new
GimpAction signals
- pass around appropriate GVariants containing booleans, int32,
strings
- badly hack around to force a GimpProcedure pointer into a
uint64 variant
- remove all G_CALLBACK() casts from all action callbacks,
they all have the same signature now
(cherry picked from commit 3b6b3fc189)
heif_chroma_interleaved_24|32bit are deprecated values replaced by
heif_chroma_interleaved_RGB(A).
Also we allocated a HEIF context twice (i.e. leaking it).
Finally it's better to initialize heif_image and heif_encoder variables
to NULL because these may not be set if creation functions fail (and
it's better to fail with NULL than with garbled unset contents).
(cherry picked from commit f4af95ab95)
- Add the quality slider in a frame under the "lossless" checkbox,
making the relationship more obvious.
- Make the whole frame contents insensitive when "lossless" is checked
and not just the slider. Once again, it makes the relationship more
obvious.
- Add a mnemonic to the "Lossless" checkbox and "Quality" slider.
(cherry picked from commit 7f76430090)
Same as WebP or jpeg: follow explicitly assigned profile TRC; convert
default (non-assigned) profile to sRGB, except if work format is 8-bit
linear.
(cherry picked from commit 5d6baf5f85)
GIMP_BUTTON_PRESS_DOUBLE press event would be called before the second
release event happens hence the tool control would not be properly
halted. Just pass through the gimp_selection_tool_start_edit() check for
any press events other than GIMP_BUTTON_PRESS_NORMAL.
(cherry picked from commit 8ccd49ac78)
Step one: get rid of all those deprecation warnings that make
it hard to see any other warnings:
- add a lot of dummy API to GimpAction, GimpActionGroup, GimpUIManager
etc. which simply forwards to the deprecated GTK functions, they
will all go away again later
- rename GimpAction to GimpActionImpl
- add interface GimpAction that is implemented by all action classes,
creates a common interface and allows to remove some duplicated
logic from GimpToggleAction and GimpRadioAction, and at the same
time adds more features
(cherry picked from commit 86e07c16b5)
Merged to gimp-2-10 to keep the diff to master as small as possible
This new capacity was created just 3 commits ago (9933f46f85).
The point was that the real fix is to remove the implication
HANDLE_LAYERS => HANDLE_ALPHA, but this breaks public API behavior,
which is why I didn't go with it.
Still it just felt wrong to add a NEEP_OPAQUE capability when it should
be the same thing as not setting HANDLE_ALPHA. After discussion on IRC,
we decided that this implication was basically a bug, and since in all
core plug-ins, when HANDLE_LAYERS was set, we were also setting
HANDLE_ALPHA, no core plug-in code even has to be changed. As for
third-party plug-ins, let's assume that none has been relying on this
wrong assumption.
(cherry picked from commit 667b4d71c9)
G3/G4 compression does not support transparency, yet in multi-layer
export, gimp_export_image() capability GIMP_EXPORT_CAN_HANDLE_LAYERS
implied GIMP_EXPORT_CAN_HANDLE_ALPHA. I guess multi-layer TIFF is more
for multi-page (at least with G3/G4 which is apparently a fax format, so
it makes sense) than actual multi-layer.
So I use the new GIMP_EXPORT_NEEDS_OPAQUE_LAYERS capability from
previous commit for this particular use case of export layers + G3/G4
compression.
Also it is better to run gimp_export_image() *after* the option dialog,
as we do for other formats, with variable capabilities depending on
which options was chosen, instead of running it before then after
merging layers when user chose not to export layers. This is duplicating
the purpose of gimp_export_image().
(cherry picked from commit f9fd818c3d)
Currently capability GIMP_EXPORT_CAN_HANDLE_LAYERS implies
GIMP_EXPORT_CAN_HANDLE_ALPHA. Though in many cases, multi-layer implies
alpha for basic compositing, our export plug-ins sometimes use the
concept of "layer export" for multi-pages or collection files.
Additionally sometimes alpha may not even be supported at all whereas
layers are. This will be the case in the next commit which will make use
of this new capability.
(cherry picked from commit 9933f46f85)
file_open_location_response(): guard against g_file_new_for_uri()
returning NULL (which it shouldn't) and an error being NULL (which it
shouldn't either for the same reason). Spotted by Massimo.
(cherry picked from commit cf8148df5e)
...gimp_size_entry_set_resolution: assertion 'GIMP_IS_SIZE_ENTRY (gse)'
failed
In gimp_tool_options_manager_tool_changed() make sure the new tool's
tool options GUI always exists, so tools can access it even if the
tool options dockable is not currently open.
(cherry picked from commit c3752ba743)
Found in my stashes, I have no idea why I even bothered but it just
needed a minor fix to work, so here we go. Stupid port that always
uses 8 bit and kills higher bit depths.
(cherry picked from commit 57ac8cfa7e)
If the comment doesn't UTF-8 validate, leave valid UTF-8 at the
beginning intact. Also fix character range comparison to use guchar
instead of gchar
(cherry picked from commit f7413d70dd)
so gimp_curve_equal() doesn't fail on random uninitialized padding
bits. Fixes finding previously used settings in the curves tool (they
were piling up just by re-applying a previously used setting).
(cherry picked from commit 4c58386ead)
Don't clear the preset combo right after a preset was selected.
Instead, clear it as soon as any change is made to the settings in the
dialog. This way the last chosen preset's name stays in the combo as
long as the current settings are identical to the preset.
(cherry picked from commit 0afcaefec5)
Use gimp_image_metadata_load_finish() and pass the right flags
depending on whether comment and profile were loaded. Also, set the
profile before creating the layer so its space is correct
automatically.
(cherry picked from commit e2bacf918c)
...always AdobeRGB!
Change all file plug-ins to never call gimp_image_metadata_load_finish()
with the GIMP_METADATA_LOAD_COLORSPACE when they loaded a color profile.
This keeps gimp_image_metadata_load_finish() from assigning a profile
from DCT even if the loaded profile was GIMP's built-in sRGB.
(cherry picked from commit a08293dc74)
Since this requires libheif 1.4.0, released end of February 2019, this
commit should not go into the gimp-2-10 branch right now.
(cherry picked from commit 22e14e0b9b)
...doesn't work
Rename the labels to "built-in sRGB color profile" and "built-in
grayscale color profile" because that's what the option does, it never
converted to the preferred profiles from preferences.
(cherry picked from commit d67f4604aa)
...always AdobeRGB!
Enable the code in gimp_image_metadata_update_colorspace() which syncs
the DCF information to the image's actual color profile, at least as
good as it can, and otherwise sets it to "unspecified".
Also fixes issue #301.
(cherry picked from commit c4ee350f02)
Since this requires libheif 1.4.0, released end of February 2019, this
commit should not go into the gimp-2-10 branch right now.
(cherry picked from commit 22e14e0b9b)
Cherry-picked now anyway... If we allow new featues in 2.10, we must
also allow for a few updated dependencies.
Instead of treating any unspecified TIFF channel as non-premultiplied
alpha, let's now ask the user (in non-interactive case, we continue
defaulting to non-premultiplied channel and outputing a message). The 3
choices are: premultiplied, non-premultiplied (which is the default so
you can just hit Enter and get same result as previously) and channel.
It's still not perfect as it still assumes that an alpha channel will
necessarily be the first extra channel (though the spec does not mandate
such assumption). Let's say for now that it is enough. Using extra
channels for the alpha channel only is most likely the most common usage
(actually the spec only has specific types for such usage).
(cherry picked from commit 7cf98231f1)
Add gimp_image_metadata_update_pixel_size(), _bits_per_sample(),
_resolution() and use them from gimp_image_set_metadata() and from
various places in gimpimage.c which had identical copies of the same
code.
Also add gimp_image_metadata_update_colorspace() which syncs the color
space stored in the image's metadata with the color space of the
image's actual color profile. Call the function from the right places.
The body of gimp_image_metadata_update_colorspace() is currently
disabled because the syncing of color space information is
controversial, see issue ##3532 and issue #301.
(cherry picked from commit b9829eddfe)
This commit adds a new preview called "Grayscale", allowing to see the
resulting mask in black and white. The previous preview is now called
"On color" and allow users to choose the color and opacity, instead of
imposing only 4 colors (red, green, blue, grey).
(cherry picked from commit d6bcb16b0b)
When using a selection modifier Altr+Ctrl|Shift, we want to commit the
selection. If I do it too late though, and if the polygon was not closed
yet, the computed coordinates for the floating selection end up (0, 0)
because it is based on the selection coordinates (yet an unclosed
polygon does not create a selection yet). So commit the tool from within
GimpSelectionTool instead, as soon as we confirmed that the class is
going to take over with SELECTION_MOVE or SELECTION_MOVE_COPY.
Note: ability of quick copying|cuting an unclosed polygon is very useful
as it removes the additional step for a case where anyway committing the
selection was a prerequisite.
(cherry picked from commit 50f8cb8542)
... selection is committed;
Fast copy|cut-paste modifiers in selection tools were not working with
the Free Select tool, even when the polygon was closed. The reason was
that GimpPolygonSelectTool was not properly chaining up with the parent
implementation for oper_update(), and then upon a button press, we need
to check to call gimp_selection_tool_start_edit() to see if the action
should not be handled by GimpSelectionTool.
Of course, since we don't necessarily want all child class of
GimpPolygonSelectTool to support these modifiers (typically we may not
want these in the Foreground select tool), I set allow_move to FALSE,
then set it to TRUE only in the GimpFreeSelectTool subclass.
(cherry picked from commit c9a91b32bc)
Add a "gboolean edge_lock" parameter to GimpChannel::feather() and a
"Selected areas continue outside the image" toggle to the "Feather
Selection" dialog, just like they exist for shrink selection and
border selection. At the end, convert the boolean to the right abyss
policy for gegl:gaussian-blur.
(cherry picked from commit aace6b179b)
Note that I am using twice TIFFErrorHandler type. This is because
TIFFWarningHandler does not exist, despite what the docs says and
upstream code actually uses twice the same handler type.
(cherry picked from commit de866d8815)
Our TIFF loading code was not taking into account the case when extra
channels were stored in the TIFF file while ExtraSamples field is not
set. Yet as a side effect of a later channel count, we were setting
`alpha` to TRUE while `save_transp_pixels` was left uninitialized (hence
undefined behavior).
For now let's make sure we have no undefined behavior. When the
ExtraSamples field is missing and at least one extra channel is stored,
we will consider the first extra channel as non-premultiplied alpha
(this is also what we were doing when ExtraSamples was set to
"Unspecified data" and apparently according to Massimo, it would be a
common behavior in other software).
Note that it is an improvement from previous code (no undefined
behaviour anymore, instead we handle explicitly the TIFF error). Yet
this is not perfect yet. Ideally we should pop-up a dialog asking what
to do with this extra channel: either open as a channel (no alpha), or
as premultiplied or non-premultiplied alpha.
(cherry picked from commit b090bc5213)
... tiling window manager.
Completing commit e6364ffa81 by additionally making sure the search
dialog is non-modal. Otherwise it prevents positionning it wherever we
want and it stays in the center, potentially hiding the canvas and
darkening the main window.
(cherry picked from commit aa1171ada2)
In gimp_group_layer_translate(), when translating a nested group
layer, call gimp_drawable_update_all() to update the child-layers'
original area *before* updating the group's offset, at which point
the group parent's size is updated, causing subsequent area-updates
during translation to be clipped to the parent's new bounds,
preventing the original areas from being properly cleared.
(cherry picked from commit 4a20a75dc3)
Add a new GimpDrawable::update_all() virtual function, and a
corresponding gimp_drawable_update_all() function, which updates
the full contents of the drawable. Unlike calling
`gimp_drawable_update (drawable, 0, 0, -1, -1)`, which updates the
entire drawable area, gimp_drawable_update_all() only updates the
area that has actual content. While the default implentation does
simply update the entire drawable area, GimpGroupLayer overrides
this function to recursively update its child layers, rather than
the its entire area.
(cherry picked from commit 3e5cbb03d9)
Some blend funcs depend on constants from the specifc color space we are
operating in and needs the space or operation propagated to the worker function
of the operation as discovered in issue #3451.
This commit propagates the operation, leaving the specific blend functions
needing it to call gegl_operation_get_source_space or similar without needing
that overhead for the rest.
(cherry picked from commit 8e90468308)
While we tend to default to sRGB for 8-bit max formats (such as JPEG or
WebP) when no explicitly-assigned profile was set, there is no need to
do so for PNG too. Indeed since we have the ability to export 16-bit
PNG, let's consider this is ok to export 16-bit linear data when writing
GIMP's default linear profile.
Moreover let's follow the profile's (fallback to storage's) TRC also
when exporting to a specific precision (as chosen manually in the
dialog), not only when sticking to "Automatic", unless we are downsizing
a high bit depth work image to 8-bit without a manually assigned profile
(the only case we forcefully export as sRGB data, hence convert the
profile if linear storage).
(cherry picked from commit 24ed5870ad)
... in JPEG export.
Same as the WebP export, which is quite similar (8-bit max format), when
no profile was explicitly set, we want to convert any data from storage
format to non-linear (unlike when exporting high bit depth formats, such
as TIFF).
We only make an exception for 8-bit linear. This commit adds this
exception.
(cherry picked from commit 0461022198)
Similarly to other export dialogs, we don't consider anymore metadata or
profile writing as being advanced options. Since these were the only
options shown in our current WebP export dialog, I removed the expander
altogether and moved everything out.
See also commit 540cfa9611.
(cherry picked from commit 26ba915ca5)
Profile and output linearity decision was doubled as save_layer() and
save_animation() and I realize that I forgot to update the
save_animation() one in earlier commits.
To avoid code copy-paste and divergence, I added an internal
webp_decide_output() function which I use in both aforementionned calls.
(cherry picked from commit 6712228e5e)
Same as other formats, we make sure that an explicitly set profile TRC
is always followed. When no profile is set, we always export as sRGB
when there is precision downsizing to avoid shadow posterization, since
WebP stores 8-bit max per channel (as far as I know, or at least as far
as we implemented it in our plug-in).
We only take the storage format into account when it is 8-bit linear
with profile export. In such case, we avoid conversion from 8-bit linear
to 8-bit sRGB.
This is different to TIFF export for instance, where we fallback on
following storage format TRC as we are able to export all sort of
precisions, hence with minimum quality loss.
(cherry picked from commit 2a1eabc177)
Same as we did for PNG and JPEG, we want to always export data with the
TRC of a profile manually assigned, and in particular NOT the curve of
the storage in GIMP (i.e. you may work on 32-bit linear, yet if you
assigned a sRGB TRC profile, this is what you should export). The
storage format will only dictate the exported data TRC when writing out
the default profile (i.e. no explicit profile assignement).
As a last case, when no profile is saved, we always export as sRGB.
As for the export precision, we always follow the storage one's, except
sometimes for 8-bit images. We promote 8-bit images to 16-bit if and
only if the storage does not match the export data linearity, to avoid
too much quality loss during format conversion.
(cherry picked from commit 8d9e70011d)
Blacklist the "tools-offset" action in the GUI, and only keep
"filters-offset", to avoid duplication. Update gimp:offset's
description, so that "filters-offset" gets a proper tool-tip.
(cherry picked from commit 42d4255262)
Add a new GimpFilterTool::region_changed() virtual function, which
gets called whenever the filter region changes, either due to a
change to the tool's "region" option, or a change to the image
mask.
Override GimpFilterTool::region_changed() in GimpOperationTool and
GimpOffsetTool, instead of listening to a change to the "region"
option in GimpTool::options_notify(), so that the tools are
properly updated when the image mask changes.
(cherry picked from commit 066827e23c)
In gimp_filter_tool_get_drawable_area(), when the image mask
doesn't intersect the drawable, return a minimal area, instead of
an empty/invalid area.
(cherry picked from commit 428ee0e2ad)
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
(cherry picked from commit 3a4a00c71e)
Implement gimp_drawable_offset() in terms of gimp:offset, added in
the previous commit. Other than avoiding duplication, this also
allows gimp_drawable_offset() to respect the current selection and
component mask (see issue #39.)
(cherry picked from commit 5b2f3980bd)
Add a new gimp:offset operation, which implements equivalent
functionality to gimp_drawable_offset(), in preparation for adding
an interactive offset tool.
To simplify things, add a GIMP_OFFSET_WRAP_AROUND value to the
GimpOffsetType enum, to avoid the need for a separate wrap-around
flag. This makes the gimp-drawable-offset procedure parameters a
little superfluous, but whatever.
(cherry picked from commit 40fefb6076)
In file-tiff, when not saving layers, avoid duplicating the image
to create the merged version if it's already been duplicated, and
make sure to delete the duplicated image otherwise.
(cherry picked from commit 8831ef2ea0)
Make sure to update the drawable after committing the Warp tool, if
high-quality-preview is disabled, and we use a non-nearest sampler.
Necessary after commit d928a80b7f.
(cherry picked from commit 2da5cb562d)
...even when not supposed to
Don't use gimp_config_copy() to set the tool options from the ones
stored in the preset. Instead, add utility function
tool_manager_copy_tool_options() that only copies properties of
GimpToolOptions and its subclasses.
Simply set the tool, copy the tool options' context properties, then
copy the tool options' own properties and done. Much more obvious and
works.
(cherry picked from commit a14834e336)
Simplify GimpDockbook's signal connect/disconnect to
GimpGuiConfig::size-changed a lot, most likely to a point where some
connection doesn't get leaked, so this bug is probably fixed.
In gimp_drawable_merge_filter(), add an "update" parameter, which
specifies whether to update the affected region of the drawable
after applying the filter. Avoid updating the drawable when
commiting a GimpDrawableFilter (and manually update the drawable if
filter application was cancelled), and when anchoring a floating
selection, since in both cases the relevant region of the drawable
has already been updated.
(cherry picked from commit d928a80b7f)
Connect GimpDisplayShell to GimpImage::mode-changed and update its
cached color transforms. Also get rid of a duplicate conection to
GimpImage::precision-changed.
(cherry picked from commit a1aa179436)
No idea why the artifacty never appeared on 2.10, the code was just as
broken as in master...
In gimp:mask-components, add an "alpha" property, which controls
the masked-in alpha value in case there's no aux buffer. Set it to
0 by default, so that gimp:mask-components behaves normally in the
absence of an aux buffer (as if the aux buffer was empty). Set it
to 1 in the image's visible-mask node, to maintain the current
alpha-component visibility behavior.
This fixes incorrect results when the output bounding box of a
drawable filter is smaller than the drawable, which can lead to a
NULL aux buffer being fed to the filter's gimp:mask-components
node.
(cherry picked from commit 6425bf820a)
On a second thought... nope :) We'll fix it another way.
This reverts commit 60947b7a34826657395ca485d334ccb302106e07.
(cherry picked from commit 3766af9ac9)
In GimpOperationLayerMode and GimpOperationReplace, make sure we
don't return a NULL output buffer, or forward a NULL input buffer,
but rather create an appropriate empty buffer in this case. This
avoids wrong results when the layer-mode op's output is connected
to the aux input of a subsequent op, as a result of the op behaving
differently with a NULL aux buffer (in particular, this can happen
when a drawable filter's output bounding box is smaller than the
drawable.)
(cherry picked from commit 8fcac3298c)
...when generating "TRC variants"
When creating a new profile with different TRC from an existing
profile, keep all the original profile's description, model,
manufacturer and copyright strings around, but prefix them with "GIMP
from " or similar to indicate that they are different. Also make sure
we don't prefix strings with GIMP stuff multiple times when profiles
are generated repeatedly.
(cherry picked from commit 3cad4aa4c2)
Add "gboolean push_undo" parameters to gimp_image_parasite_attach()
and _detach() and use the API also from undo, instead of implementing
attaching/removing manually and forgetting about the signals.
Fixes updating of the image properties color profile page.
(cherry picked from commit 710cfc1f47)
gimp_image_parasite_attach(): when we detected that a builtin profile
is about to be attached, actually bail out after removing the old
profile, instead of continuing to attaching the builtin profile
anyway. Gah...
(cherry picked from commit 07ffef38c3)
This commit adds support for moving together an intersecting pair
of guides using the Move tool, by dragging the guides at their
point of intersection. This is useful when the guides are used to
mark a point, rather than a pair of lines (e.g., as is the case for
the mandala symmetry guides, which mark the symmetry's point of
origin).
Add gimp_image_pick_guides(), which can return a set of guides,
rather than a single guide. The API allows an arbitrary set of
guides to be returned, but, in practice, at most two intersecting
guides are returned, as per the above.
In GimpMoveTool and GimpGuideTool, add support for moving multiple
guides together, and, in GimpMoveTool, use gimp_image_pick_guides()
to potentially pick multiple guides.
(cherry picked from commit 1e95481feb)
...to the Configure Keyboard Shortcuts dialog
Add the button, based on an old patch from Sven Neumann, and make the
buttons in the keyboard shortcuts and input devices dialogs look and
behave the same.
(cherry picked from commit 04b69e2494)
In gimp_gegl_apply_[cached_]operation(), add support for output
buffers whose extent's top-left corner is not (0, 0). This is
needed by the previous commit.
(cherry picked from commit a6393e6c55)
In GimpSourceCore, when applying a symmetry transform to the source
content, combine the transform op with translation to the paint-
buffer coordinates, so that subclasses (namely, GimpClone and
GimpHeal) can use the op to apply the transformation directly from
the source buffer to the paint buffer in a single step. This is
both more efficient, and avoids incorrect symmetry transforms when
the paint buffer is cropped to the bounds of the drawable.
(cherry picked from commit a701032b4e)
Remove the GimpSymmetry::get_operation() virtual function, and
instead implement gimp_symmetry_get_operation() by returning an
appropriate gegl:transform node based on the matrix returned by
gimp_symmetry_get_matrix(). The returned node is owned by the
caller; since we no longer use the node's identity for caching
trnasformed brushes, we no longer cache the transformation nodes.
Remove the function's paint_width and paint_height parameters, and
instead return a transformation that should be applied at the
center of the brush. This simplifies the application of the
transformation in the Clone and Heal tools, as per the next commit.
Remove the implementation of GimpSymmetry::get_operation() from all
its subclasses, which should now only implement
GimpSymmetry::get_transform().
(cherry picked from commit 60a3965020)
... which returns the brush transform corresponding to a given
GimpSymmetry stroke as a GimpMatrix3, as per
gimp_symmetry_get_transform().
(cherry picked from commit cd7bcd081b)
Add GimpPaintbrush::get_color_history_color() virtual function,
which should return the color to be added to the color history upon
painting, if any. The default implementation returns the
foreground color, when not using a pixmap brush or color-from-
gradient.
Override this function in GimpEraser, to return the background
color when the affected drawable has no alpha channel, instead of
overriding GimpPaintCore::paint() for this purpose. This avoids
erroneously adding both the background and foreground colors to the
history.
(cherry picked from commit 86f4d4d41d)
As suggested by LRN, change gimp_sigfatal_handler() on Windows to
dstinguish between fatal and non-fatal exceptions so we don't abort on
each minor hickup.
(cherry picked from commit 679fd5f231)
In GimpClone and GimpHeal, use gimp_gegl_apply_operation(), instead
of gegl_node_process(), to apply the symmetry transform, which both
performs chunking and avoids aliasing problems.
(cherry picked from commit 024bc4cd3f)
Call gimp_projectable_structure_changed() when the image's profile
changes so the projection buffer gets reallocated.
(cherry picked from commit 1e07f00a95)
(Picking this is not strictly needed, but did it anyway because it
doesn't hurt and this commit is hard to miss if we finally merge space
invasion to stable).
...-last positioned- monitor
Use gimp_dialog_factory_position_dialog() in GimpColormapEditor and
GimpPaletteEditor so the color dialogs appear where they were before.
(cherry picked from commit 765abcd316)
which is the logic that used to be in color_area_color_clicked()
factored out to proper API. It makes sure that a dialog that was
visible before (and was only hidden not destroyed) appears at the same
point on the same monitor as before. See issue #1093.
(cherry picked from commit ebb6b08e62)
In GimpPaintbrush, factor out the code responsible for determining
the current dab's paint parameters and content to a new
GimpPaintbrush::get_paint_params() virtual function.
Derive GimpEraser from GimpPaintbrush, instead of directly from
GimpBrushCore, implementing get_paint_params() appropriately.
This allows GimpEraser to reuse the paint-buffer content across
dabs, improving performance.
(cherry picked from commit aba4eef916)
Use gimp_symmetry_get_transform() instead of
gimp_symmetry_get_operation() throughout the paint code, where
possible. This allows us to combine the symmetry transform with
the ordinary brush transform, simplifying the code, improving
performance, and avoiding multiple resamplings. This also fixes
the paint-buffer size when using mandala symmetry with non-round
brushes, avoiding artifacts.
(cherry picked from commit b63af476bd)
Add a GimpSymmetry::get_transform() virtual function, and a
corresponding gimp_symmetry_get_transform() function, which return
the brush transform corresponding to a given symmetry stroke in
terms of the rotation angle and reflection flag (in contrast to
gimp_symmetry_get_operation() which returns the same transforation
in terms of a GeglNode). This would allow us to simplify, fix, and
improve the painting-code perofmrnace in the next commits.
Implement GimpSymmetry::get_transform() in its various subclasses.
(cherry picked from commit e0f2a6f1be)
Similar to JPEG export (commit c5f7bac2ba)
as discussed with Ell. GIMP should follow and save as-is any *assigned*
profile. We only make a decision about whether to convert from storage
precision to another format when the profile is the default GIMP one.
...in a color image/colour image
gimp_edit_paste_get_layer(): only use the pasted-to drawable's format
with alpha if this is really a floating paste, use the image's layer
format with alpha for "as new layer" cases.
(cherry picked from commit 1f57675a46)
...when overwriting existing text
gimp_text_tool_enter_text(): when replacing a selection, use the text
properties from the text style editor for the entered text, otherwise
the style of the text before the selection will be used.
(cherry picked from commit 1a691f77e6)
Extend last commit to also disregard the composite space when the
layer mode is trivial and only the source region is included in
compositing, since, in this case, the source color is unmodified.
(cherry picked from commit c2021d3c5b)
In gimp_layer_mode_get_format(), disregard the requested composite
space when selecting the format, if the input layer mode is alpha-
only, and the requested composite mode is not UNION, since, in this
case, the layer mode doesn't combine the layer/backdrop colors, and
rather only modifies the alpha of one of them. This allows us to
use the preferred format, avoiding gamma conversion.
This particularly improves the performance of the Eraser tool in
perceptual images.
(cherry picked from commit a5962e4049)
In gimp_drawable_transform_get_effective_clip(), always return
RESIZE_CLIP when the input drawable is the image mask, since the
presence of a selection doesn't matter in this case. This avoids
erroneously displaying a result-size warning when transforming the
selection using any of the selection tools.
(cherry picked from commit 1c91578bb2)
In configure.ac, improve backslash escaping in the compiler
version string. Backslashes are currently not properly escaped in
our Windows builds, leading to spurious (and, in particular, non-
UTF8) characters in the compiler version string.
(cherry picked from commit 04f9281bdd)
Initialize GimpBacktrace earlier on in the startup process, so that
the Windows backend installs the thread-name exception handler
early enough to catch threads created before app_run() (in
particular, the GEGL worker threads).
(cherry picked from commit 853d91b8e4)
In GimpPaintbrush, avoid refilling the paint buffer at each dab if
the paint color/pixmap hasn't changed, as gimp_paint_core_paste()
no longer modifies the buffer since the commit before last.
Additionally, fix color-from-gradient dynamics when the image has a
profile.
(cherry picked from commit edc99531e6)
In GimpBrushCore, replace the private
gimp_brush_core_transform_pixmap() function with a public
gimp_brush_core_get_brush_pixmap() function, which, similarly to
gimp_brush_core_get_brush_mask(), returns the transformed brush
pixmap, and can be used by subclasses.
(cherry picked from commit fcd19a2aeb)
We now have enough machinery in gimppaintcore-loops to avoid
modifying the paint buffer in gimp_paint_core_paste() in the no-
applicator case, by using the same set of algorithms as
gimp_paint_core_replace(). Other than reducing the number of
different code paths we have, this is both more efficient, and
allows us to reuse the paint buffer across dabs, as done in the
following commits.
Implement gimp_paint_core_replace() in terms of
gimp_paint_core_paste(). We keep the two functions separate, since
their implementation is still differnet when using an applicator.
Suppress the paint-buffer-modifying algorithms in
gimppaintcore-loops, but keep them around; using the same logic for
normal painting as we use for REPLACE painting is possible due to
the fact that all our current non-REPLACE modes treat alpha values
and mask values interchangeably. In the future we might have modes
that distinguish between alpha and mask values, requiring the old
algorithms.
(cherry picked from commit f24bca5156)
In gimp_brush_core_get_paint_buffer(), when allocating a new paint
buffer, clear the old buffer *before* allocating the new one, to
reduce the amount of simultaneously allocated memory.
(cherry picked from commit bea1a44672)
Add a tile-alloc-total varaible to the dashboard's memory and misc
groups, showing the total amount of memory used by the tile
allocator (see commit
gegl@137e66e45138e8316f6403e53e8aa9a02ad523e7.)
(cherry picked from commit cf54f790fd)
... in LCh colorspace
In gimptoolbox-color-area, when setting the context's background
color in response to a color-dialog change, block the right signal
handler, to avoid re-setting the color dialog's color, which would
cause the GtkAdjustment's "value-changed" signal (assuming it was
the source of the change) to be restarted if the new value doesn't
match the current one exactly, which can happen due to conversion
errors.
(cherry picked from commit c7a29e5f98)
Int casting results to truncation. First this is a bit counter-intuitive
as we usually expect rounding to the nearest integer. Moreover with the
new GUI updates on curve and curve tool, we end up with a mismatch as
the new Input/Output spin buttons where indeed showing rounded integers
whereas the coordinate indicator was showing truncated integers.
Make all these show same rounded value.
GIMP should not convert assigned profile to sRGB just because we stored
as linear on the XCF. In other words, we should not look at the image
precision to decide whether to export as linear (previously only 8-bit
linear images), but at the profile TRC. There are basically 3 cases:
(1) We don't save a profile, then convert to sRGB whatever the source
precision (because readers would assume sRGB for a no-profile jpeg).
(2) We save the default profiles: convert to sRGB because it's usually
a better choice for 8-bit formats and even working at 32-bit float
*linear* doesn't mean you want to export as 8-bit int *linear*. As the
image creator made no explicit export choice, we make an acceptable
default one.
(3) We save an explicitly assigned profile: keep the profile TRC, don't
convert!
Note that this apparently won't work perfectly right now, as GIMP
replaces the original TRC with the linear default TRC when converting to
linear. So the expected TRC is lost in such case when you have not
explicitly reset the correct profile. Yet this is on GIMP side and this
part of the issue should be fixed with the space invasion merge. For
now, this is how the plug-in should work.
This is based on my late discussion with Ell. Please everyone, and Ell
especially, review! :-)
In windows-actions.c, connect to GimpDisplayShell's "notify::title"
and update the action label when it changes.
(cherry picked from commit c9b10ff3bf)
windows_menu_display_query_tooltip(): bail out if "image" is
NULL. Can't happen currently but did happen temporarily while hacking
on related code. Better safe than sorry.
(cherry picked from commit 3bf2a3c166)
In GimpFilterTool, properly clean up the controller's widget weak-
pointer and signal-handlers upon destruction, to avoid invalid
memory access when the widget is destroyed, if the widget outlives
the controller.
(cherry picked from commit 068df34a27)
In the vairous gimp_gegl_create_foo_node() functions, set the
parent node's underlying operation node, so that
gimp_gegl_apply_cached_operation() avoids duplicating the source
buffer when applying these nodes (all underlying operations are
currently point ops.)
(cherry picked from commit 928e5957e3)
Apparently Microsoft added just recently the feature to install user
font (as opposed to system-wide fonts), without administration rights
(yes, only now, how crazy is that?). Right now GIMP does not see fonts
there.
We have an upstream report at fontconfig where such a default search
path should happen.
See: https://gitlab.freedesktop.org/fontconfig/fontconfig/issues/144
Until it gets fixed there, let's just add the user fonts dir ourselves
in GIMP. This code should get killed later.
Notes:
- I renamed various DEFAULT_* data macros to GIMP_DEFAULT_* because
DEFAULT_PALETTE was conflicting with another macro in Windows API!
- Also I removed the DATADIR macro set under app/config/ because it is
also conflicting and anyway we use it in no files on this level.
- This is not perfectly tested on Windows. Please everyone with Windows
access, could you build and test if it works fine before release?
(cherry picked from commit 88f97aedef)
Several of our own translations of the Windows installer are unused
because Inno Setup corresponding translations are marked "unofficial".
This mostly means that the language files for these are probably old and
unmaintained, hence outdated. And these files are not bundled together
with Inno Setup release (though still hosted in their repo).
Nevertheless it doesn't make sense that we would just waste the work of
our translators here. Maybe Inno Setup localization is not complete, so
what? At best it could even encourage translators to contribute upstream
to Inno Setup. Let's just enable all our current localizations of the
installer and see how it goes!
(cherry picked from commit 01f258faec)
The export code was checking the existence of a profile variable which
was never set. In other words, it seems we were always converting TIFF
pixels to non-linear, even when we were also exporting a linear profile.
Note that is not useful anymore to check profile existence as we now use
the effective profile (which always exists). So we just have to check if
the "save profile" option is on.
(cherry picked from commit 062195117c)
In GimpFreeSelectTool, flush the image when committing the tool, if
the seletion is created at the time of the commit (i.e., if the
polygon is not closed prior to the commit).
(cherry picked from commit 71c624c5ab)
In gimp_selection_tool_start_change(), increase the priority of the
idle source used for hiding the selection so that it's run before
the canvas is redrawn, to avoid flickering the previous selection.
(cherry picked from commit 3369958525)
In GimpFreeSelectTool, use gimp_selection_tool_{start,end}_change()
to create the selection as soon as the polygon is closed, and
update it when the polygon, or the relevant tool-options, change,
similarly to GimpRectangleSelectTool.
(cherry picked from commit 476833b553)
We currently derive GimpForegroundSelectTool from
GimpFreeSelectTool, which prevents us from making changes that are
limited to the free-select tool.
Factor out the common free-select and foreground-select logic into
a new GimpPolygonSelectTool base-class, and derive both from this
class.
(cherry picked from commit afab7deaa3)
Move GimpRectangleSelectTool's image undo/redo logic to
GimpSelectionTool, by adding a pair of
gimp_selection_tool_{start,end}_change() functions. These
functions should be called by subclasses before/after changing the
selection, having the functions take care of undoing/redoing the
existing selection as necessary. This allows us to reuse this
logic in other selection tools, specifically, the free-select tool.
(cherry picked from commit 4612105e52)
In gimp_container_tree_view_clear_items(), temporarily unset the
tree-view's model before clearing it, so that name editing is
stopped beforehand. Otherwise, name editing is stopped once the
corresponding item is removed from the store, causing us to rename
the wrong item.
(cherry picked from commit bb8648a2e9)
In gimp_open_dialog_set_image(), use a weak pointer for storing the
current image, to avoid a segfault in file_open_dialog_response()
if the active image at the time of the open action has been closed
before confirming the dialog.
(cherry picked from commit b01113741e)
In the Curves tool, explicitly set the point-coordinate spin-
buttons' width-chars, so that their size remains fixed when their
range changes.
(cherry picked from commit 8fc94184a8)
In the Curves tool, when the image precision is greater than 8-bpc,
use a 0.00-100.00 range for the point-coordinate spin-buttons,
instead of a 0-255 range.
(cherry picked from commit be719f9070)
Allow setting the type of GimpCurve control-points to either SMOOTH
or CORNER. Smooth points produce a smooth curve, while corner
points produce a sharp curve (previously, all points were smooth).
In GimpCureView, display corner points using a diamond shape,
instead of a circle.
In the Curves tool, allow changing the curve's point types.
(cherry picked from commit 33e47c85a2)
Add input/output spin-buttons to the Curves tool, which allow
setting the selected point's coordinates numerically.
(cherry picked from commit 5140d903b8)
In GimpCurve, replace the use of a fixed-length control-point array
with a dynamically-sized array. Adapt GimpCurve's interface, and
the rest of the code.
In addition to simplifying the code, this fixes a bug where the
curve object could be broken by moving the mouse too fast (yep...),
and allows more accurate point placement, both in the GUI editor,
and through canvas interaction in the Curves tool (see issue #814).
(cherry picked from commit b6d829a1b2)
In GimpCurveView, when holding down Ctrl while adding/dragging a
point, snap the y-coordinate to the original curve (at the start of
the drag). This is particularly useful for adding points along the
curve, without changing their y-coordinate.
Likewise, have the coordinate indicator show the snapped
coordinate.
(cherry picked from commit 8357c9ad64)
In GimpCurveView, when dragging an existing curve point, don't
immediately move the point to the cursor position uppon button
press, but rather move it relative to its current position as the
cursor moves. This allows selecting a point without moving it, and
adjusting its position more easily.
Additionally, when the cursor hovers above a point, or when
dargging a point, have the coordinate indicator show the point's
position, rather than the cursor's.
(cherry picked from commit 0b9737a3ed)
Add an "Incremental" option to the Dodge/Burn tool, which,
similarly to the Paintbrush, Pencil, and Eraser tools, applies the
effect incrementally as the pointer moves.
(cherry picked from commit 83184d1626)
... linear itself AND if we export the profile.
Implement similar logics to WebP export as I did to JPEG in my previous
commit.
(cherry picked from commit b9458f8a6e)
... linear itself AND if we export the profile.
In most cases we want to save 8-bit image formats (here JPEG) as
non-linear, even though the work image may have been linear itself (yet
with higher bit depth). The reasons are shadow posterization on low bit
depth, and the fact that JPEG compression was designed for perceptually
uniform RGB and introduces shadow artifacts with linear RGB (see #1070,
message by Elle Stone). The only exception is when the creator was
working explicitly on 8-bit linear (not higher bit depth) AND if we
export the profile (otherwise most loaders around assume sRGB). In such
a case, let's consider the creator knows what one is doing and keep the
exported image linear.
Similar logics is already used in PNG exporter (though a bit of a
variant since PNG supports 16-bit so it is instead: 8-bit linear without
profile is promoted to 16-bit non-linear, and kept 8-bit linear with
profile).
(cherry picked from commit 5f4cf53519)
... produces incorrect result.
Similar to previous fixes to JPEG and PNG exporters. Here WebP always
export 8-bit per channel colors, so let's always keep it non-linear.
Simply when the original data was linear, if we save the profile,
convert it to sRGB before exporting.
(cherry picked from commit 7a4b313b12)
... linear XCF.
When choosing a specific pixel format (other than "Automatic"), we
always export as non-linear. Therefore if we were going to save a linear
profile, make sure we also convert it to sRGB too.
(cherry picked from commit c5fae74ac1)
... produces jpeg in linear color space.
The problem was that we were anyway always exporting to non-linear while
attaching a linear profile. A first approach would have been to export
in linear instead when the work image is linear, as proposed by mitch in
a first version of the patch. Yet as Elle Stone notes, it is not a great
idea to export 8-bit images as linear.
Instead let's continue to always export as non-linear, as we were
already doing. Yet when we also save a profile, and this one was
originally linear, let's convert it to sRGB TRC before exporting.
(cherry picked from commit 8594275bb7)
Only seek back to after the end of the actual brush if a following
pattern was *not* found. Got this logic wrong in the original port of
the plug-in code.
(cherry picked from commit 40863bffdd)
It is written in a translator comment and is important because it breaks
some automatic validation tools along the way to packaging. Thanks for
following the translation comments! :-)
In GimpRectangleSelectTool, update the selection upon changes to
the "antialias", "feather", "feather-radius", "round-corners", and
"corner-radius" options, so that they take effect immediately,
without having to change the selection bounds.
(cherry picked from commit 2da6cefa3f)
Since recently, one can also install the new "libmypaint-v1" branch. It
is not so different, but has several fixes. Among them, it fixes
building with recent automake.
(cherry picked from commit 1028345b7b)
... for "Edit/Preferences/Default Image"
In GimpTemplateEditor, don't use gimp_prop_enum_combo_box_new() for
the "Precision" combo-box, and rather synchronize the combo-box and
the template manually, since we only want to update the "Gamma"
combo-box according to the precision when it changes through the
UI, and not when the template's precision otherwise changes.
This fixes an issue where we'd always set the default gamma value
when resetting the editor's template, overwriting the template's
original gamma value.
(cherry picked from commit 033082dd9a)
In GimpChunkIterator, avoid preparing the current rect before
merging it back to the iterator's region, to save some work.
Additionally, strengthen the iterator's invariants and simplify
code.
(cherry picked from commit c95502266a)
Set the priority of the image window's UI-manager update idle
slightly higher than the projection idle priority, so that the
image actions are updated during projection rendering.
(cherry picked from commit 50aaeef6a0)
In gimp:fill-source, align the result rect to the drawable buffer's
tile grid, so that all tiles are COWed for solid-color fills.
(cherry picked from commit fa31854a66)
In GimpTransformGridTool, avoid producing non-finite coordinate
and angle values. In particular, this fixes a crash in
gimp_transform_grid_tool_get_cursor() as a result of a NaN angle
value being converted to a negative integer, hitting an assert.
(cherry picked from commit be7906c05c)
In GimpViewable, don't invalidate the preview when thawed, unless
there was an explicit call to gimp_viewable_invalidate_preview()
while it was frozen. This avoids invalidating the previews of an
invisible drawable's ancestors when the drawable's preview is
frozen/thawed.
(cherry picked from commit 9dabad4cb9)
When freezing/thawing a top-level drawable's preview, only freeze/
thaw the image preview if the drawable is attached.
(cherry picked from commit de36e33347)
Add GimpViewable::preview_{freeze,thaw}() virtual functions, which
get called when the viewable's preview is frozen/thawed. Implement
the functions in GimpDrawable, recursively freezing the parent
drawable's preview (or the image's preview, for top-level
drawables) while the drawable's preview is frozen. For layer
masks, freeze the associated layer's parent.
This avoids updating layer-group/image previews while painting on,
or applying a filter to, a descendant layer. This both reduces
lag, and fixes a discrepancy between the layer's preview, which
isn't updated, and its parents' previews.
(cherry picked from commit e2ea2e4a82)
This was actually more of a feathering feature I added earlier, and we
already have a function for that: gimp_gegl_apply_feather(). This is
using a gaussian blur, just as what I was doing anyway. This commit also
adds the "Feather Radius" scale, similar to other tools with the
"Feather Edges". So that makes it consistent (and more useful as you can
adapt to your needs).
(cherry picked from commit d821b088e2)
Add a GTK+ patch providing a "popup-style" combo-box style
property, allowing to manually control the combo-box popup-style.
Use the LIST style for all combo-boxes in our system-wide gtkrc
file; this only has effect if GTK+ was built with the above patch.
Add a GTK+ patch that makes sure that list-style combo-box popups
are never narrower than their content. This fixes the popup width
when using the System theme on Windows, for combo-boxes whose popup
cell-layout is wider than the combo-box cell-layout. It is also
required for the next commit.
Include the system-wide gtkrc file, in addition to the user-
specific gtkrc file, in the generated themerc file, instead of
copying the former into the latter when creating the user's
gimpdir. This allows us to modify the system-wide gtkrc file, and
having the changes take effect in existing installations.
In gimp_drawable_edit_fill(), when performing a non-direct fill,
use a GimpDrawableFilter with gimp:fill-source, added in the
previous commit, instead of using gimp_drawable_apply_buffer() with
an intermediate fill buffer. This avoids allocating a full-size
fill buffer, which may occupy a lot of space in pattern fills.
(cherry picked from commit 234f76b6fb)
Add a new gimp:fill-source operation, which can act as a source
node for fill operations, instead of a fill buffer. The op takes
a GimpFillOptions object, a drawable, and a pattern offset, and
uses gimp_fill_options_create_buffer() to produce its output.
This allows performing the entire fill operation in chunks as a
graph, instead of allocating a full-size fill buffer, which can
can occupy a lot of space for pattern fills.
(cherry picked from commit 6b0337e384)
In gimp_drawable_fill_buffer(), when the fill-source is a pattern,
avoid going through an intermediate buffer when there's no profile
transform, and use the destination-buffer format for the
intermediate buffer, instead of the pattern format, when there is a
profile transform.
(cherry picked from commit 3c1634ee0d)
Add gimp_fill_options_get_format(), which returns the format to be
used for the fill buffer; this is the same format used during
compositing. Use this format in gimp_fill_options_create_buffer(),
instead of the drawable format.
This fixes the result of fill operations when the fill color/
pattern is not representable in the drawable format, and speeds up
color fills by avoiding color-conversion for the fill buffer during
processing.
(cherry picked from commit 245a17c79f)
In GimpDrawableFilter, use
gimp_gegl_node_set_underlying_operation() to the the input
operation node as the underlying operation of the filter node.
(cherry picked from commit b0dfc1e7c7)
In gimp_gegl_apply_cached_operation(), use the underlying
operation, as returned from
gimp_gegl_node_get_underlying_operation(), for testing whether the
operation is a point operation, for the purpose of avoiding
duplicating the input buffer. Likewise, avoid duplicating the
buffer when the underlying operation is a source operation.
(cherry picked from commit 213b126c6e)
... which allow setting/getting the "underlying operation" node of
a graph node. For example, GimpDrawableFilter constructs a complex
graph around a given operation node, which would be the underlying
operation of the graph. This allows querying the properties of the
underlying operation, given only the graph.
In recursive cases, gimp_gegl_node_get_underlying_operation()
returns the most-nested underlying operation; when no underlying
operation has been set, gimp_gegl_node_get_underlying_operation()
returns the input node.
(cherry picked from commit eb5e473665)
In gimp_drawable_real_apply_buffer(), use GimpChunkIterator to blit
the applicator's output to the drawable's buffer in chunks, to
minimize the space used for intermediate results.
(cherry picked from commit 8f845d3a51)
In GimpChunkIterator, redajust the target area at each step,
instead of at each iteration, to adapt more quickly to the current
processing speed. To avoid creating uneven chunks as a result,
only change the chunk height at the beginning of rows, unless the
resulting area would be more than twice as big as the target area.
(cherry picked from commit e904b71242)
In GimpProjection, store the priority rect in image coordinates,
and only convert it to projectable coordinates when initializing
the chunk-iterator's priority rect. This allows us to preserve the
priority rect across projectable structure/bounds changes.
(cherry picked from commit 9d80ccc3e6)
In gimp_drawable_merge_filter(), don't disable the filter
applicator's output-format conversion node if the output format is
different than the drawable's format, since it may change the
result.
(cherry picked from commit 30da2f3d6f)
In gimp_drawable_merge_filter(), disable the filter applicator's
cache and output-format conversion nodes before processing the
uncached region of the filter, so that the result is written
directly to the drawable's buffer.
(cherry picked from commit 733a6ec01c)
... immediately after an image precision change
When flushing a projection, make sure it has a buffer, instead of
bailing if it doesn't. We rely on the image projection's "update"
signal to update the display after certain operations that free the
buffer, which would previously fail to happen, and cause subsequent
flushes to be ignored until the buffer is explicitly accessed.
This fixes commit b07f810273.
(cherry picked from commit 106df3b794)
In gimp_group_layer_get_size(), make sure to always set *width and
*height, even when the group is empty, so that when the function is
called through gimp_projectable_get_size() by the group's
projection, the correct size is reported. This makes sure we
update the correct area when the group becomes empty.
(cherry picked from commit a712308f20)
In gimpchannel-select, move some of the common functionality of the
various gimp_channel_select_foo() functions to gimpchannel-combine.
Furthermore, don't special-case CHANNEL_OP_INTERSECT, but rather
pass it over to gimpchannel-combine, which is now prepared to
handle it in all functions, as per the previous commits.
In gimpchannel-combine, factor out the common functionality of the
various gimp_channel_combine_foo() functions into a pair of
gimp_channel_combine_{start,end}() functions, which are called
before/after the actual gimp_gegl_mask_combine_foo() function,
respectively. In particular, these functions deal with calculating
the new channel bounds. Previously, the various
gimp_gegl_mask_combine_foo() functions would implicitly invalidate
the channel bounds (since commit
d0ae244fe8), rendering the bounds-
recalculation code ineffective. This avoids manually recalculating
the bounds in many cases, speeding up selection operations.
(cherry picked from commit 8e77347cac)
Simplify code, use gimp_gegl_buffer_copy() for CHANNEL_OP_REPLACE
when possible, improve value clipping, and parallelize processing.
(cherry picked from commit a227c8e94d)
Improve gimp_gegl_mask_combine_ellipse_rect() -- the funciton
responsible for rendering ellipse/rounded-rectangle selections.
Most notably, this commit significantly improves the function's
performance, by identifying whole tiles, whole rows, or parts of a
row, that are fully inside, or fully outside, the ellipse, and
filling them in bulk, instead of calculating the anti-aliasing
value at each pixel, which is now only done along the
circumference.
This commit also improves anti-aliasing, by more accurately
approximating the distance from a pixel to the ellipse, and by
normalizing the distance according to the pixel's cross-section
length in the direction of the said point. In particular, we
guarantee that pixels that are fully inside/outside the ellipse
have a value of 1/0, respectively, facilitating the aforementioned
optimization.
Additionally, this commit fixes various edge cases where several
primitives coincide at a single pixel (in the rounded-rectangle
case), adds support for CHANNEL_OP_INTERSECT, and parallelizes
processing.
(cherry picked from commit 1044342393)
... which takes a GimpPrecision, and determines if its values are
bounded to the [0,1] range (which is currently only true for
integer precisions).
(cherry picked from commit d7f12c9d26)
Don't assume that "toggled" signal means that toggle status actually
changed.
Though issue #3133 got fixed with my previous commit, let's make sure we
never create several GBinding for the same GimpChain by always checking
existence of a previous one after a "toggled" signal.
Also only create a GBinding object if one doesn't already exist.
(cherry picked from commit 9042e85f3c)
... clicking a GimpChain.
Since commit c0c055b4e9, gimp_chain_button_set_active() emits the
"toggled" signal. There is no need to emit it separately from
GimpOperationTool when setting presets with
gimp_operation_tool_set_config().
In particular, since the "toggled" signal was even sent unconditionnally
here, our code was ending creating several GBinding for the same 2
adjustments, which was creating an infinite loop.
(cherry picked from commit 03dc24455a)
"binding" data can be set to NULL. Do not assume it is a proper object.
Also I was tempted to use g_object_set_data() to simply free the
GBinding object on setting a new data, but such object will also be
freed when the widget is destroyed by default. So that would also end up
in double destruction. Instead just keep current logics.
This CRITICAL was reported in #3133 but this is not the main bug.
(cherry picked from commit af6760b3c9)
In an animated WebP, chances that layers/frame have the same size is
high. It is uneeded to free then malloc again a buffer at each frame,
unless we need more allocated memory.
This is probably not so significant, but still feels nicer.
(cherry picked from commit 0b68ce8182)
In GimpTransformGridTool, extend the functionality of the
"Readjust" button, such that if the transformation is already
adjusted to the view (i.e., when the button is clicked the second
time), readjust the transformation to the item bounds (as when
using the tool "normally"), and vice versa. This allows switching
back and forth between "normal" mode, and "adjusted-to-view" mode.
Additionally, disable readjustment when the current transforamtion
is invalid, and show an error when readjustment results in an
invalid transformation.
(cherry picked from commit a3fa3b6181)
In gimp_tool_gui_set_response_sensitive(), silently ignore non-
existent response IDs, instead of emitting a CRITICAL, to match the
behavior of GtkDialog and GimpOverlayDialog. This simplifies code
with optional dialog responses.
(cherry picked from commit 92216a635a)
This argument should actually say "Do not store premultiplied channel
values", which is what the TIFF spec calls "Unassociated alpha" (vs.
"associated alpha" when values are stored premultiplied by alpha).
Now I can see where the current description is coming from, which is
that any color with alpha 0 (totally masked) ends up as RGBA value (0,
0, 0, 0), in other words, the color information is completely lost. Yet
this label is not very helpful to understand what the checkbox really
does. I decided to not just change it altogether as people would have
gotten used to this for years, but at least adding completary
information in API and tooltip in GUI.
When the "wrap" property of a GimpSpinButton is TRUE, wrap-around
out-of-range values entered through the spin-button's text entry,
instead of clamping them. Since we're using GimpSpinButton
everywhere since last commit, this applies to all our angle-entry
spin buttons (including spin scales).
(cherry picked from commit 8b3c7ae193)
Not sure what this @image_types parameter of gimp_install_procedure() is
used for. Exporting was working find with INDEXEDA image even when not
advertized by this function. Let's update this anyway.
In the unified-transform, scale, and perspective tools, take the
maximal transform-grid handle size into account when readjusting
the transform, so that the handles themselves are fully within view
under arbitrary rotation, rather than just the corners.
(cherry picked from commit 46e16e175c)
s/THREAD_MODE_ABOVE_NORMAL/THREAD_PRIORITY_ABOVE_NORMAL/
Thanks to Sylvie Alexandre for noticing and searching this.
(cherry picked from commit ebc3ef3c5e)
Do not take "Sample merge" into account when picking colors in a
single-layer image. The reason is to be able to get the index
information on indexed image. This information is lost otherwise when
using the whole image as a pickable.
Of course, other exceptions are possible, when you'd pick exactly a
colormap color, but I don't think it's worth making the code
extra-complicated for these. My previous commit will anyway already
select the right color in the colormap on common cases. Though it will
still fail to select the right index when several indexes store the same
color, on a multi-layer image, if you check "Sample merged" while the
right index was not the first one amongst the duplicates.
(cherry picked from commit 31b2b55b28)
The colormap saves colors as unsigned char, which can be very inaccurate
compared to high precision colors. When adding colors from GimpRGB into
the colormap, use the original value to fill the colormap palette
instead of making a round trip conversion from double to uchar, then
back to double.
This also fixes a direct bug I encountered when adding the current
foreground color in the image colormap. Yet the GimpFgBgEditor or the
GimpColorHistory would still show the color out-of-gamut in cases when
the returned RGB after the roundtrip was not close enough to the
original RGB (even despite using an epsilon in GimpPalette code).
(cherry picked from commit f1cca8ee2e)
In GimpTransformGridTool, reset both transform directions in
response to the "Reset" button, so that the overall transformation
is restored to the identity. Previously, we would only reset the
active transform direction (possibly compensating in the opposite
direction, if both directions are linked). This was intentional,
but it's probably a bit too confusing, especially in conjunction
with the newly added "Readjust" button. Let's just go back to
resetting everything.
(cherry picked from commit 2c67b29190)
Implement GimpTransformGridTool::radjust(), added in the previous
commit, in various transform tools:
The unified-transform, scale, and perspective tools readjust the
transformation such that the grid is centered relative to the view,
and its handles are fully within view under arbitrary rotation.
The rotate tool readjusts the transformation such that the pivot is
centered, and the grid is unrotated, relative to the view.
(cherry picked from commit 5e5118c1db)
Add an optional GimpTransformGridTool::radjust() virtual function,
which subclasses can implement to radjust the transformation based
on the current state of the display, such that it's easy to
control. This is especially useful when the image is zoomed-in,
and the transform handles, which are initially across the layer
bounds, are out of view.
When a transform tool implements radjust(), show a "Readjust"
button in the tool GUI. While readjusting the transformation, we
modify the opposite transformation such that the overall transform
remains unchanged, as if both transform-directions were linked, so
that only the transform grid is readjusted.
(cherry picked from commit 5055dd10d5)
In GimpToolGui, add gimp_tool_gui_add_button() and
gimp_tool_gui_add_buttons_valist(), which allow adding dialog
buttons after construction.
(cherry picked from commit b23fae86f0)
Line-art computation can take a long time, and it's therefore
desirable for it to be interruptable. While we do cancel the line-
art async when its result is no longer needed, most parts of the
computation don't respond to the cancelation request, leaving the
async operation running in the background, blocking subsequent
async operations.
Implement cancelation support of line-art computation, by passing
down the async object to the various functions, and periodically
checking for its cancelation at various points. When the async is
canceled, we quickly abort the operation.
Even though cancelation now happens relatively quickly, some parts
of the computation are still uninterruptable and may incur some
latency, so we avoid waiting for the async opration to be aborted
after cancelation, as we did before.
(cherry picked from commit d8e69d66bc)
... so that performance logs can be recorded during long-running
async operations, without those operations blocking the
finalization of the log.
(cherry picked from commit 652a2a90cf)
... which is equivalent to gimp_parallel_run_async_independent(),
except that it takes an additional "priority" parameter, which
specifies the task's priority, with 0 being the default priority,
and lower values indicating higher priority. Unlike
gimp_parallel_run_async_full(), the priority parameter doesn't
directly control the task's priority in a queue, but rather, we use
it to control the priority of the task's dedicated thread, on
supported platforms (previously, all independent async tasks would
run with low priority.)
Use low priority when loading fonts, which can take a long time, to
keep the existing behavior.
(cherry picked from commit fa2e4dcce0)
Remove gimp_item_tree_clear(), added in last commit, and move its
code to gimp_item_tree_dispose(). Likewise, in
gimp_image_dispose(), use g_object_run_dispose() on the image item-
trees, instead of gimp_item_tree_clear().
(cherry picked from commit b0de51b6bf)
Add gimp_item_tree_clear(), which removes all the items of a
GimpItemTree, and clear the layers/channels/vectors item trees in
gimp_image_dispose(), *before* finalizing the image, so that the
corresponding items' desctructors are called while the image is
still alive. In particular, this allows the destructors to safely
call gimp_item_is_attached(), which happens when the image has a
floating selection, since commit
8d4e5e0ff7.
(cherry picked from commit d7e3a1e226)
... in GIMP 2.10.9 from git
In gimppickable-contiguous-region's pixel_difference() function,
which is used, among other things, by the select-by-color and
fuzzy-select tools, when selecting by LCh/HSV hue, treat a pair of
colors as inifinitely far apart if one of them has positive chroma/
saturation, and the other has chroma/saturation that's very close
to 0; conversely, treat a pair of colors as equal if both of them
have chroma/sautation that's close to 0.
As a result, when the seed color is saturated, gray pixels are
never selected, while when the seed color is desaturated, all, and
only, gray pixels are selected.
(cherry picked from commit 9886b69dac)
When clicking on a line art pixel, only this pixel gets colored, which
is fine for actual (original) line art pixels. But on generated ones
(closure pixels, which are internal only), you end up with a single
pixel colored while the whole surrounding area is empty. This feels like
a bug (even though it was not one technically) as you have no way to
guess you are clicking on a closure pixel.
Instead, when this happens, simulate clicks on all neighbour pixels,
hence potentially coloring all surrounding regions, which is most likely
what you wanted.
(cherry picked from commit f310db6c21)
Commit bc187cc5cc was a bit wrong as it was possible to get some race
conditions when changing settings quickly in a short time frame.
(cherry picked from commit 3a317e72aa)
On various property changes, only recompute the line art when the
property actually changed. Also add a gimp_line_art_bind_gap_length() to
avoid computing twice the line art when changing both type of closure
(splines and segments) together, as is currently the case.
(cherry picked from commit c0996241f6)
… Bucket Fill tool options.
This will provide feedback when the line art closure is being computed,
which may be useful on big images where it may take some time. Otherwise
painter may be left hanging without knowing what takes time.
(cherry picked from commit bc187cc5cc)
In the warp tool, use the gegl:map-relative node to calculate the
affected drawable area to which the filter is cropped, to account
for box filtering.
(cherry picked from commit daa09ef602)
Add a "real-time preview" option to the warp tool, which, when
toggled, causes the preview to be rendered synchronously during
motion. This is slower, but gives better feedback.
(cherry picked from commit a93af839fe)
The "spacing" option of the warp tool used to be handled by the
gegl:warp op, and have little effect. Instead, implement it in the
warp tool directly, having the same effect as the other paint
tools.
Having a properly-working "spacing" option allows us to use EXACT
motion mode without cirppling down performance, which means that
the stroke now follows the pointer exactly, even when processing
takes a while.
Decrease the default "spacing" value to 10.
(cherry picked from commit e8a39d5c49)
In the warp tool, use the gegl:map-relative node to calculate the
invalidated drawable area when the displacement field changes, to
account for box filtering.
(cherry picked from commit aa91528084)
In the warp tool, set scroll-lock to TRUE, so that the image isn't
scrolled when click-dragging outside the canvas, like the rest of
our paint tools.
(cherry picked from commit 6acedc7ebb)
In gimppaintcore-loops, fix the CanvasBufferIterator algorithm
helper-class so that it may appear more than twice in the
hierarchy, and integrate it into the normal dispatch-dependency
system, instead of having dependent algorithms inherit it directly.
(cherry picked from commit 03810861d2)
Fix gimp:mask-components to use full-oapcity value for the alpha
component when it's masked-in and there's no "aux" input, so that
the image is rendered with full opacity when the alpha channel's
visiblity is toggled off, as per bug #143315.
(cherry picked from commit 6419ed3246)
In GimpTransformGridTool, fix weak-pointer initialization for the
out-of-bounds selection-boundary canvas item, to avoid a CRITICAL
when initializing the tool in transform-selection mode for a fully
out-of-bounds selection, and a subsequent segfault when re-
initializing the tool.
(cherry picked from commit 1e739675a4)
Add "Constrain handles" and "Around center" options to the
perspective-transform tool's GUI, which are similar to the
corresponding options of the unified-transform tool. Both of these
options can already be controlled using Shift and Ctrl,
respectively, through the transform-grid widget, so we might as
well provide GUI toggles for them.
(cherry picked from commit ac4b0fe9f1)
In GimpToolTransformGrid, use the transformed center-point of the
original polygon as the position of the center-point handle, and as
a snapping point for the pivot when "cornersnap" is TRUE, instead
of using the center-point of the transformed polygon. These two
points are different for non-affine transformations.
Furthermore, when "use-pivot-handle" is FALSE, use the center-
point as the reference point when transforming around the pivot,
instead of the pivot itself, which might not be set. In
particular, this fixes transformation around the pivot in the
perspective tool.
Don't explicitly set the center-point as the pivot in the scale
tool, since this commit makes it unnecessary.
(cherry picked from commit cdc5782b3c)
In gimp_pickable_contiguous_region_by_color(), add a small epsilon
to the threshold value, to allow for small errors due to the input
color and pickable pixel-colors being converted to the common
format through different paths.
While we *could* special-case threshold == 0 when the input color
comes from the same pickable, as is the case for the select-by-
color tool, and perform an exact comparison in the original format,
in the more general case the input color can come from an arbitrary
source, such as a plug-in.
(cherry picked from commit a6c79770c3)
In gimp_gegl_create_flatten_node(), explicitly set the output
format of the background gegl:color node according to the composite
space, so that no conversion is required during compositing.
(cherry picked from commit ebf2c2fef1)
In gimp_image_merge_layers() -- the internal function used by the
various layer-merging/flattenning functions -- process the merged-
layer graph in chunks, using gimp_gegl_apply_operation(), instead
of in one go, using gegl_node_blit_buffer(). Processing in chunks
better utilizes the cache, since it reduces the size of
intermediate buffers, reducing the chances of hitting the swap when
merging large images (see, for example, issue #3012.)
Additionally, this allows us to show progress indication. Have the
relevant gimpimage-merge functions take a GimpProgress, and pass it
down to gimp_image_merge_layers(). Adapt all callers.
(cherry picked from commit e83d8ac4f2)
Streamline the various action_data_get_foo() functions, by having
each function only match the action data directly against its
specific type(s), and use the other functions to match the action
data against their corresponding types, instead of having each
function directly exhaust all possible matches.
Other than reducing depulication, it fixes certain cases in which
some action_data_get_foo() functions would fail to find a match,
even though one exists, since they failed to exhaust all the
options.
(cherry picked from commit 914200f3ad)
In GimpSmudge, avoid copying the brush's dab to the paint buffer
when using a pixmap brush if the flow parameter is 0 -- it has no
effect in this case.
(cherry picked from commit fb5987fd57)
Reimplement gimp_brush_core_color_area_with_pixmap(), which copies
the brush's dab to the paint buffer when using a pixmap brush, in
terms of gimp-gegl-loops. This simplifies the functions,
parallelizes processing, and transparently handles float brushes.
Replace the "mode" parameter of the function with an "apply_mask"
parameter, which specifies whether to apply the brush's mask to
the dab as part of copying. Avoid applying the mask in
GimpPaintbrush; previously, we would erroneously apply the mask
twice when using the paintbrush tool: once when copying the
dab to the paint buffer, and again when pasting the paint buffer
to the canvas.
We still apply the mask in GimpSmudge, which results in the same
double-application behavior, however, this might be less practical
to fix.
(cherry picked from commit 5b09af4390)
In gimp_temp_buf_{ref,unref}(), and
gimp_temp_buf_create_{buffer,pixmap}(), accept a const GimpTempBuf
argument.
(cherry picked from commit 0a1e62768a)
Just the GimpData::save() and ::copy() part that is needed to
duplicate and rename them, the image-to-pipe logic from the export
plug-in remains to be ported.
(cherry picked from commit aee097fa97)
Commit dc069e424a removed the
assumption that 1-bpp PCX files are B&W, in favor of using the
provided palette, which is (supposedly?) the correct behavior.
However, there are evidently B&W files that do not specify a
palette, resulting in an all-black image (i.e., a 2-color indexed
image, whose both palette entries are black). Since other
software, including older versions of GIMP, load such files
"correctly", let's fix this by falling back to a B&W palette when
the provded palette is uniform.
(cherry picked from commit 11defa4271)
Replace the use of the deprecated GeglNode::dont-cache property,
and GeglOperationClass::no_cache field, with GeglNode::cache-policy
and GeglOperationClass::cache_policy, respectively.
See commit gegl@7f24430cda0d8c3eff311868823d445edc2a4e12.
(cherry picked from commit 7489f0aece)
- don't clear the names of the individual brushes, we need them for
a load -> save roundtrip
- for the same reason, and for convenience, store the parameter string
in the object
- clean up gimp_brush_pipe_finalize()
(cherry picked from commit 4b456e6079)
of file-gbr-load, and add some layer handling magic that doesn't
change a thing for simple brushes, but is needed for loading brush
pipes.
(cherry picked from commit 3b89ae40d0)
In GimpOperationTool, update the options scrolled-window size
request whenever the size of the options box changes, instead of
only when constructing the GUI, since the options layout may change
dynamically through GUM, or through a custom GUI.
In gimppaintcore-loops, unsuppress the
COMBINE_PAINT_MASK_TO_CANVAS_BUFFER algorithm (partially
reverts commit b717ead1abd487f663668ac131883dff0ffe4557.)
In gimp_paint_core_paste() it's always used together with
CANVAS_BUFFER_TO_PAINT_BUF_ALPHA, which matches a combined
algorithm, preventing it from being called, however, it can still
be called through gimp_paint_core_replace(), which uses it
together with CANVAS_BUFFER_TO_COMP_MASK, which doesn't have a
combined algorithm. We can, however, filter out
CANVAS_BUFFER_TO_PAINT_BUF_ALPHA whenver
COMBINE_PAINT_MASK_TO_CANVAS_BUFFER is matched (since the combined
algorithm will be matched beforehand when both algorithms are
included).
(cherry picked from commit 6fe57a946b)
In gimp_drawable_filter_sync_affect(), don't mask-out the filter's
alpha component when the drawable doesn't have an alpha channel,
since this is no longer necessary -- we now explicitly convert the
output to the drawable format as part of the graph -- and it
prevents the gimp:mask-components node from becoming a NOP.
(cherry picked from commit af2c7d1b33)
In gimp_drawable_get_active_mask(), when the drawable doesn't have
an alpha channel, set or clear the mask's alpha bit, according to
the state of the other bits, so that it never gets in the way of a
fully set/clear mask. The value of the alpha bit doesn't matter
when there's no alpha channel, however, having a uniform mask
allows us to skip component masking altogether.
Additionally, provide a default implementation for
GimpDrawable::get_active_mask() which returns a full mask, and
remove the equivalent implementation for GimpChannel.
(cherry picked from commit 1b900bfa16)
Remove the mask_components_onto() gimppaintcore-loops function, and
the GimpPaintCore::comp_buffer member. Instead, in
gimp_paint_core_paste() and gimp_paint_core_replace(), use the
MASK_COMPONENTS algorithm, added in the previous commit.
(cherry picked from commit c7d8d9ba2e)
In gimppaintcore-loops, add a new MASK_COMPONENTS algorithm, which
masks the output of compositing into the destination buffer,
according to a component mask. The algorithm uses the same code as
gimp:mask-comopnents, and can be used as part of a
gimp_paint_core_loops_process() pipeline, instead of using a
separate function.
(cherry picked from commit 08fa46ea41)
In gimppaintcore-loops, add a CompBuffer algorithm helper-class,
which provides access to the output buffer used for compositing,
to be used by the DO_LAYER_BLEND algorithm instead of the
destination buffer.
CompVuffer itself doesn't provide the storage for the buffer; this
is rather the responsibility of the algorithms that use it. The
TempCompBuffer algorithm helper-class provides temporary storage
for the compositing buffer, and can be used by algorithms that need
a temporary buffer.
(cherry picked from commit 858f30a609)
In gimppaintcore-loops, use {Mandatory,Supressed}AlgorithmDispatch,
added in the previous commit, to mark certain algorithms as always
occuring, or never occuring, in all hierarchies.
(cherry picked from commit b717ead1ab)
In gimppaintcore-loops, add MandatoryAlgorithmDispatch and
SuppressedAlgorithmDispatch class templates, which implement
dispatch functions suitable for algorithms which are always part of
the hierarchy, or never part of the hierarchy, respectively. Using
one of these classes as the dispatch function for a given algorithm
verifies that the algorithm is/isn't included in the requested-
algorithm set, but doesn't otherwise increase the number of
instanciated hierarchies, since only one of these cases has to be
handled.
(cherry picked from commit fc7ffc71a3)
In gimppaintcore-loops, remove the individual-algorithm convenience
functions, which are merely wrappers around
gimp_paint_core_loops_process(), and aren't used anywhere anymore.
This allows us to avoid instanciating certain algorithm-hierarchies
which aren't used in practice, as will be done by the following
commits.
(cherry picked from commit 95761db557)
Add specialized versions of gimp:mask-components for 8-, 16-, and
32-bpc formats, to improve efficiency, and to preserve the contents
of masked-out components exactly.
Provide public functions for format-selection and processing, which
we'll use in the painting code, instead of reimplementing component
masking.
(cherry picked from commit ee156b8fd6)
In gimp_gegl_apply_cached_operation(), when the source and
destination buffers are the same, avoid duplicating the source
buffer when the applied operation is a point operation, since
applying it in chunks from/to the same buffer is not a problem in
this case.
(cherry picked from commit 0d21f2469b)
... which takes a GeglNode, and determines if the associated
operation is a point operation.
Use in GimpFilterTool, instead of performing the same check
manually.
(cherry picked from commit 918f2e75bd)
When the result of compositing has an alpha value of 0, the
corresponding color value is not mathematically defined.
Currently, all out layer modes opt to preserve the destination's
color value in this case. However, REPLACE mode is different
enough to warrant a different behavior:
Unlike the other layer modes, when the compositing opacity
approaches 0 or 1, the output color value approaches the
destination or source color values, respectively, regardless of the
output alpha value. When the opacity doesn't approach 0 or 1, the
output color value generally doesn't approach a limit as the output
alpha value approaches 0, however, when both the destination and
source alpha values are equal, the output color value is always a
simple linear interpolation between the destination and source
color values, according to the opacity. In other words, this means
that it's reasonable to simply use the above linear interpolation
for the output color value, whenever the output alpha value is 0.
Since filters are commonly combined with the input using REPALCE
mode with full opacity, this has the effect that filters may now
modify the color values of fully-transparent pixels. This is
generally desirable, IMO, especially for point filters. Indeed,
painting with REPLACE mode (i.e., with tools that use
gimp_paint_core_replace()) behaved excatly as described above, and
had this property, before we switched gimp_paint_core_replace() to
use the common compositing code; this created a discrepancy between
painting and applying filters, which is now gone.
A side effect of this change is that we can now turn gimp:replace
into a NOP when the opacity is 100% and there's no mask, which
avoids the compositing step when applying filters. We could
previously only apply this optimization to PASS_THROUGH mode, which
is a subclass of REPLACE mode.
Note that the discussion above concerns the UNION composite mode,
which is the only mode we currently use REPLACE in. We modify the
rest of the composite modes to match the new behavior:
CLIP_TO_BACKDROP always preserves the color values of the
destionation, CLIP_TO_LAYER always preserves the color values of
the source, and INTERSECTION always produces fully-zeroed pixels.
(cherry picked from commit 27e8f452b3)
Remove gimp_gegl_replace(), which is not used anywhere since the
last commit. It's redundant with the rest of our compositing code,
in particular, gimp:replace and gimp:mask-components.
(cherry picked from commit d2f8413173)
Remove gimp_drawable_replace_buffer(), which is no longer used
anywhere since commits ddb69b77a7 and
3451ffb62c. This eliminates
redundancy, since all compositing is now done through the layer-
mode code.
Furthermore, gimp_drawable_replace_buffer() used the drawable's
active-component array, whose layout depends on the image mode, as
an argument to gimp_gegl_replace(), which always expects an RGBA
component array, resulting in broken component masking in non-RGB
images.
(cherry picked from commit 2074accb60)
The algorithm to compute a zone area by following its border only works
well for fully closed zones. It may return negative values otherwise.
Let's just assume the created zone is big in this case (which may or may
not be the case, but this is the safe case as it does not prevent
closure creation).
(cherry picked from commit 0636c302a3)
(cherry picked from commit 582801ccc5)
(cherry picked from commit b44c2e9352)
(cherry picked from commit cdd686f752)
(cherry picked from commit 3b818f6a9b)
(cherry picked from commit c7d5438b49)
Note from reviewer: sorry, this was not squashed on master! Gitlab
failed to squash even though the "squash commits" checkbox was checked!
So it ended as a 5-commit 1-line change!
:-/
I realized that the same issue as for indexed images could also apply to
grayscale. If your fg/bg colors are not gray, it should not be expected
for them to be paintable. So let's give the out-of-gamut hint.
(cherry picked from commit 9090de96f2)
If a color is not within the indexed image's palette, we can consider it
to be out-of-gamut too (the gamut of such image being its palette).
This is a first step towards fixing #2938. Basically currently opening
indexed images is not made obvious and you can end up thinking GIMP is
broken as when you try to paint with a given FG or BG color, you may get
a completely different color on the canvas. And it is not obvious to
realize why. Now at least, the FG/BG color will tell you when the color
you are trying to paint with is not within the accepted palette.
(cherry picked from commit 7b4c96d03d)
There was no use to pack them on 2 lines. It was just making the FG/BG
widget overly huge, and the color picker button and hex entry very long.
This was just ugly. Also this dock is tall enough, so packing things
horizontally when it makes sense is better.
(cherry picked from commit 45adf9d0d7)
Add some comments and string docs as it is not that obvious to
understand the whole logics, invert the return value (returning TRUE
when the closure line is accepted, instead of the opposite) and rename
it to more appropriate gimp_line_art_allow_closure().
(cherry picked from commit c4beca8c90)
The initialization is sometimes done when switching tools (for instance
when selecting the active tool by command), not always on button press.
So the error output behavior was inconsistent, and worse, the tool was
sometimes not forbidden to run when it should have been.
Just run all the checks (layer groups, locks and whatnot) on button
press.
(cherry picked from commit 74cfd4fd95)
but only the actual saving code, not the export magic and dialog.
Add new internal procedure file-pat-save-internal which is not
registered as a file procedure and always works non-interactively on
the passed arguments and only saves the passed drawable. Use the new
internal procedure from the file-pat-save code and remove all file
writing code from the plug-in.
This way all pattern file writing code duplication is killed, while
the whole export mechanism is completely unchanged.
(cherry picked from commit b29ecfb5da)
In the applicator path of gimp_paint_core_replace(), actually use
the paint-core's applicator, instead of using
gimp_drawable_replace_buffer(). This improves speed, consolidates
code, and fixes some cases in which the latter is broken.
Furthermore, when using CONSTANT paint application-mode, use the
paint-core's undo_buffer as the compositing source, rather than the
drawable buffer, which is the correct behavior.
(cherry picked from commit 3451ffb62c)
In the applicator path of gimp_paint_core_paste(), use the paint
mask directly when combining it to the canvas buffer, rather than
using a copy of it, since it's not being modified.
Fix some comments.
(cherry picked from commit ba6713bbe1)
Implement the no-applicator path of gimp_paint_core_replace() in
terms of gimp_paint_core_loops_process(), using the algorithms
added in the previous commit, instead of using
gimp_drawable_replace_buffer(). This improves speed, consolidates
code, and fixes some cases in which the latter is broken.
Furthermore, when using CONSTANT paint application-mode, use the
paint-core's undo_buffer as the compositing source, rather than the
drawable buffer, which is the correct behavior.
(cherry picked from commit ddb69b77a7)
In gimppaintcore-loops, add CANVAS_BUFFER_TO_COMP_MASK and
PAINT_MASK_TO_COMP_MASK paint algorithms, which copy the canvas
buffer and the paint mask, respectively, to the compositing mask.
When there is an image mask buffer, the algorithms additionally
combine the copied mask with the mask buffer. When possible, the
algorithms use the canvas buffer/paint mask data directly as the
compositing mask data, instead of copying.
These algorithms are necessary in order to implement
gimp_paint_core_replace() in terms of
gimp_paint_core_loops_process(), which is done by the next commit.
(cherry picked from commit 183a55613e)
In gimppaintcore-loops, in the DO_LAYER_BLEND paint algorithm, and
in the CanvasBufferIterator algorithm helper-class, initialize the
iterator *before* initializing the base class, to make sure that
dest_buffer, or canvas_buffer, respectively and in that order, is
the primary buffer of the iterator. In particular, this avoids the
mask buffer being the primary buffer. This is desirable, since
most of the buffers we iterate over are tile-aligned to the dest/
canvas buffers.
(cherry picked from commit f9c072c328)
In gimppaintcore-loops, add a MaskBufferIterator algorithm helper-
class, which provides read-only iterator access to the mask buffer,
if one is used.
Use the new class in DoLayerBlend, instead of manually managing the
mask-buffer iterator.
(cherry picked from commit 44281ce2c4)
In gimppaintcore-loops, add a CompMask algorithm helper-class,
which provides access to the mask buffer used for compositing, to
be used by the DO_LAYER_BLEND algorithm instead of the image mask
buffer.
CompMask itself doesn't provide the storage for the mask; this is
rather the responsibility of the algorithms that use it. The
TempCompMask algorithm helper-class provides temporary storage for
the compositing mask, and can be used by algorithms that need a
temporary mask.
(cherry picked from commit e36847febb)
In gimppaintcore-loops, make the algorithm names, and the names of
the corresponding functions, more consistent.
(cherry picked from commit d23e239fed)
In gimppaintcore-loops, add finalize() and finalize_step()
algorithm functions, which get called at the end of processing the
entire area, and at the end of processing each chunk, respectively.
Algorithms can use these functions to clean up allocated resources.
(cherry picked from commit 4d2ce15400)
In gimppaintcore-loops, make the CanvasBufferIterator algorithm
helper-class self-contained, not having to rely on AlgorithmBase.
(cherry picked from commit 0d1f724112)
In the various gimppaintcore-loops algorithms, assign each
algorithm's iterator indices dynamically, rather than statically,
so that algorithms have more freedom in the way they initialize the
iterator.
(cherry picked from commit 9d1d21e716)
Add GimpData::save() implementation to GimpPattern, and change some
glue code to make patterns editable.
Also implement GimpData::duplicate() in GimpPatternClipboard, which
makes it possible to simply copy an area and duplicate the clipboard
pattern to create a new persistent pattern.
(cherry picked from commit e93fd73fac)
We currently have brush and pattern I/O code in both the core and
plug-ins. This commit starts removing plug-in code in favor of having
one copy of the code in the core, much like XCF loading and saving is
implemented.
Add app/file-data/ module with file procedure registering code, for
now just with an implementation of file-gbr-load.
Remove the file-gbr-load code from the file-gbr plug-in.
(cherry picked from commit a4e77e57f6)
gimp_brush_load_brush(): support legacy gpb brushes, and port a check
for gsize overflow what was added to the plug-in.
(cherry picked from commit 619f999280)
In GimpChainButton, emit the "toggled" signal whenever the chain
button's "active" property changes, either due to user interaction,
or programatically. Previously, it would only get emitted when the
button was actually clicked.
In particular, this fixes an issue where the aspect ratio of a
coordinates size-entry won't get updated when its chain button got
toggled programatically, as can happen with the scale tool.
(cherry picked from commit c0c055b4e9)
Again some missing context when requesting the strings (while they were
declared with context in static NC_()).
Also some mixup with some zoom actions strings declared with different
context in the same GimpEnumActionEntry.
(cherry picked from commit 6c5b6c6135)
Similar to master commit cb025cec64,
except that I just redid the search-replace as there were annoying
conflict merge (was easier to just redo massive search-replace).
See commit f8f3a74971.
The context change was basically a bug fix, and nothing changed in the
original string, nor its actual GUI context/usage. Therefore there is no
need to invalidate the translations (mark it "fuzzy", which would be
what would happen automatically after this change) for the 43 languages
which already translated these. Let's just search-and-replace all the po
files with the correct context.
For the record, I got the green light from several translators on
gnome-i18n ML so let's fix. :-)
(cherry picked from commit 7a5e5be35e)
The line art imaginary segments/splines are not added when they create
too small zones, unless when these are just too small ("unsignificant").
Why the original algorithm keeps such micro-zones is because there may
be such zones created when several splines or segments are leaving from
a same key point (and we don't necessarily won't to forbid this). Also
we had cases when using very spiky brushes (for the line art) would
create many zones, and such micro-zones would appear just too often
(whereas with very smooth lines, they are much rarer, if not totally
absent most of the time).
Also it is to be noted that the original paper would call these
"unsignificant" indeed, but these are definitely significant for the
artists. Therefore having to "fix" the filling afterwards (with a brush
for instance) kind of defeat the whole purpose of this tool.
I already had code which would special-case (fill) 1-pixel zones in the
end, but bigger micro zones could appear (up to 4 pixels in the current
code, but this could change). Also I don't want to use the "Remove
Holes" (gimp:flood) operation as I want to make sure I remove only
micro-holes created by the line art closure code (not micro-holes from
original line arts in particular).
This code takes care of this issue by filling the micro-holes with
imaginary line art pixels, which may later be potentially bucket filled
when water-filling the line art.
(cherry picked from commit 72092fbdbc)
Plug-ins are not prepared to handle high-precision brushes/
patterns, even when they're otherwise aware of high-precision
drawables, so make sure to always use compat formats when
communicating brush/pattern data to plug-ins.
Allowing plug-ins to handle high-precision brush/pattern data would
require some additional API.
(cherry picked from commit 82c449496e)
Older --enable-binreloc configure option had basically the same purpose
as the newer --enable-relocatable-bundle, though the old binreloc was
only used for gimpenv.c code.
As a consequence, commit 10ce702188 was still not working fine since
gimp_installation_directory_file() also need binreloc enabled (to be
actually relocatable).
Let's get rid of this whole mess, by implying we want binreloc code to
be used when --enable-relocatable-bundle is ON. We don't need the
m4macros anymore, since AM_BINRELOC was basically just checking that
`/proc/self/maps` was present. But anyway being present at compile time
does not mean it will be at runtime (nor the opposite). So this test is
not that useful. The binreloc code will anyway fallback gracefully to
the non-binreloc code (i.e. trying to use build-time install paths) if
the procfs is lacking at runtime.
(cherry picked from commit 4d84c1d7ee)
Avoid unnecessary calls to gimp_temp_buf_data_clear() in various
places, where either the entire buffer is being written to, or most
of it is, only requiring clearing the edges.
(cherry picked from commit 9d19e804ed)
Promote the precision of generated brushes to 32-bit float, and
modify brush preview generation, and gimpbrushcore-loops, to handle
float brushes. This avoids posterization in large brushes.
Note that non-generated brushes are still uint8.
(cherry picked from commit 8ef1113dee)
In GimpTempBuf, add gimp_temp_buf_lock() and gimp_temp_buf_unlock()
functions, which lock/unlock the buffer for data access. Unlike
gimp_temp_buf_get_data(), which returns a direct pointer to the
buffer's data, the new functions take a format parameter and may
return a temporary buffer, allowing the buffer to be accessed using
an arbitrary format.
(cherry picked from commit 12dde445c4)
In GimpTileBackendPlugin, avoid storing read/written tiles in the
libgimp tile-cache, since caching is already done by GEGL.
(cherry picked from commit 47dcd4b93a)
Add a GimpTransformGridTool::matrix_to_info() virtual function,
which should extract the tool-specific transformation parameters
given a transformation matrix, and the old parameter set (which is
needed in some tools, to derive the parameters that aren't encoded
in the matrix, such as the pivot point). The transformation matrix
can be any combination of matrices calculated by the tool, and
their inverses. Subclasses should only implement this function if
every such matrix can be mapped back to transformation parameters.
This is currently the case for all the transform-grid tools, except
for the shear tool (since it only supports shearing along one of
the horizontal or the vertical directions, however, the combined
matrix may require shearing in both directions).
When a transform-grid tool implements this function, show a chain-
button between the two transform-direction radio-buttons in the
tool options. When the chain-button is linked, whenever the
transform corresponding to the active direction is modified, adjust
the transform corresponding to the non-active direction such that
the overall transform remains the same.
One notable workflow that this enables is transforming a layer
while adjusting a different area than its boundary, by first
defining the area while the transform-directions are linked, and
then transforming the area while the transform-directions are
unlinked.
(cherry picked from commit 39e23267f7)
In GimpTransformGridTool, allow performing simultaneous forward
(normal) and backward (corrective) transforms, by having each
transform direction operate on an independent set of parameters.
In other words, whereas the transform-grid tools previously had a
single transform, which could be applied either normally or
correctively using the "direction" tool-option, they now have two
independent transforms, one applied normally and the other
applied correctively, which are toggled using the "direction"
option. The overall transform is the combination of the backward
transform, followed by the forward transform.
Another way to think about it, is that the tool transforms a source
shape into a destination shape. The source shape is defined by the
backward transform, and the destination shape is defined by the
forward transform. Wherewas previously only one of these shapes
could be controlled (the other shape always being the item bounds),
it's now possible to control both shapes in a single transform.
The next commit will allow modifying both shapes simultaneously,
making this even more useful.
Note that since both transforms start off as the identity, using
only one of the transform directions has the same behavior as
before.
(cherry picked from commit de8e81f81f)
... and corresponding gimp_chain_button_{get,size}_icon_size()
functions, which control the chain-button's icon size.
(cherry picked from commit 8d6c7e42bf)
Add an undo_desc field to GimpTransformToolClass, which subclasses
should set to the tool's default undo description. Provide a
default implementation for the get_undo_desc() vfunc, which returns
(a copy of) undo_desc. This simplifies transform tools that have a
static undo descrption, as well as provides a fallback when a
detailed undo description can't be generated (not currently
relevant, but will be used in the next commit).
(cherry picked from commit d549440650)
When rotating an item around its center using the rotate tool,
i.e., if the pivot point hasn't been moved, don't include the pivot
coordinates in the undo description.
(cherry picked from commit 44c8a1f274)
In GimpToolCompass, add a read-only "effective-orientation"
property, which returns the actual orientation of the compass; in
particular, if the "orientation" property is set to AUTO,
"effective-orientation" returns HORIZONTAL or VERTICAL, depending
on the current compass direction. In 3-point mode, the property
always returns AUTO.
(cherry picked from commit 40c0913178)
In GimpMeasureTool, don't try to access the "straighten" button
when halting the tool if it's NULL, which can happen when the
measure tool is selected upon startup, but is changed before its
tool-options GUI is constructed.
(cherry picked from commit 7fc5698f32)
In gimp_transform_matrix_generic(), apply the resulting matrix even
if the transformation is invalid, since GimpGenericTransformTool
relies on the matrix to properly update the transform-grid widget.
(cherry picked from commit 59ef222c7f)
In GimpTransformGridTool, when the "show-preview" tool-option
changes, don't take the transform validity into account when
deciding whether to hide the current layer -- it should only affect
the visibility of the preview, not the layer.
(cherry picked from commit 7ed512040e)
...1920*1980 resolution
In GimpOperationTool, make the generated GUI scrollable if it is
higher than half the monitor's workarea. This is meant as a last
resort for generated GUIs that do not have a custom constructor that
makes them usable using better layouts.
(cherry picked from commit b85d7c2334)
Fix previous commit.
Ahahah! Mitch, you didn't test your code before pushing! Bad boy! :P
(cherry picked from commit db00616888)
(Bad Jehan didn't pick this to 2.10)
gimplanguagestore-parser.c (parse_iso_codes): instead of
special-casing Windows and OS X, use ENABLE_RELOCATABLE_RESOURCES and
find the package relative to ${gimp_installation_directory}, so
relocating it works on all platforms (also flatpack, snap, whatever),
given the --enable-relocatable-bundle configure switch is used.
(cherry picked from commit 10ce702188)
In pygimp/plug-ins/Makefile.am, fix the rule for the generated
plug-in files, so that they're re-copied to the build dir upon
changes to the source plug-in files.
(cherry picked from commit 95044d86b3)
When initializaing the perspective-clone tool in paint mode, the
GimpDrawTool may already be active, causing the call to
gimp_draw_tool_start() to fail with a CRITICAL. Stop the draw tool
first, if active, to avoid that.
(cherry picked from commit 07d2d5af5a)
In GimpPerspectiveCloneTool, use PIXEL_CENTER cursor precision
while setting the source, and place the source-position handle at
the center of the selected pixel, rather than at its top-left
corner.
Additionally, disable the paint tool while adjusting the
perspective, so that the brush outline isn't shown, and the cursor
precision remains SUBPIXEL, even if the hard-edge option is
toggled.
(cherry picked from commit e5c9314a88)
... which can use to enable/disable certain aspects of
GimpPaintTool (in particular, brush-outline drawing). Should be
used by subclasses, to temporarily disable the paint tool while in
a non-paint mode (currently, this is only needed by the
perspective-clone tool; see next commit.)
(cherry picked from commit 05dd5029ee)
In GimpCloneTool, set the cursor precision to PIXEL_CENTER while
setting a source, and have GimpBrushTool snap the brush outline to
pixel centers.
(cherry picked from commit ef2818231f)
Fix the cursor precision of the cage-transform, foreground-select,
n-point deformation, and warp-transform tools.
(cherry picked from commit 158705e4ef)
gimp_plug_in_handle_proc_install(): print the procedure name when
bailing out of a wrong proc install call. For an obsolete full-path
menu label, also print the label. Original patch by Liam Quin.
(cherry picked from commit 07e3c1c15b)
In libgimp, add a note to gimp_install_procedure() stating that
passing a full menu path as "menu_label" is deprecated.
Pickle gimp.GroupLayer the same way we pickle gimp.Layer, so that
layer-group parameters can be properly saved.
All credit goes to Ofnuts :)
(cherry picked from commit b295a33aaf)
This plug-in failed to cross-build because these macros were not defined
in the `float.h` of my MinGW64 environment (and they are used in some
ilmbase headers). Just define them ourselves if they are absent. I do
this only on MinGW environment because these should really be defined on
Linux (and other UNIX-like, I guess?) and if they are not, we may have a
bigger issue.
(cherry picked from commit 7a7ecda4f1)
... tools' brush options.
After discussions, it turned out that many people disliked that the spin
scale for brush size (and some other options) get you fractional values.
How often do you actually need to get a 4.32 pixel-size brush? And even
how meaningful is it? On the other hand, you usually want a 4 or a 5
pixel size brush and it's nearly impossible to get (exactly) by dragging
the scale widget.
It is so annoying that some even resort to edit the value with keyboard!
So I am adding an optional "constrain" feature to GimpSpinScale. It will
still be possible to get fractional values when constraining is on, for
instance with keyboard edit (the arrow incrementation also will keep any
fractional part). So the interaction for such scales is simply reversed
so that you get integers easily, and fractional parts with a bit more
effort.
It is not turned on by default (some feature actually need precision and
we don't want to break the sliders for these) and for the time being, I
only applied it to all the brush settings in paint tools. Now that it
exist, we may want to apply this to more scales in various parts of
GIMP.
(cherry picked from commit bff3903f37)
... on macOS.
The debugger running on macOS is usually lldb and (from the reports we
get) it looks like lldb displays the tid as hexadecimal on macOS
(whereas lldb displays decimal tid on Linux! I know, it's confusing, yet
consistent with crash report experience!). So let's just do the same,
making it easy to quickly copy-search in order to look up the crashing
thread (without having to convert from decimal to hexa).
This is a bit of an approximation as I imagine we could have gdb on
macOS or whatever edge case. Let's say it's good for the common case and
still not an error otherwise (just a base conversion away).
(cherry picked from commit 8e0135362e)
When initializing a pygimp plug-in derived from gimpplugin.plugin,
only pass the plug-in's init() and quit() functions to gimp.main()
if the plug-in actually implements them, instead of passing the
default NOP versions. This avoids plug-ins that don't implement
init() from being registered as having an init function, causing
them to be run at each startup.
(cherry picked from commit 9851bc8962)
In gimp:gradient, when using adaptive supersampling, render the
gradient tile-by-tile, using an iterator, instead of row-by-row.
This significantly improves performance, while also avoiding the
assumption that gimp_adaptive_supersample_area() works row-by-row.
Additionally, when not using supersampling, use a single GRand
instance, since the separation to distinct seed and per-tile
instances, which was a threading optimization (commit
7f39e41254), is no longer needed.
(cherry picked from commit 2cd7938f02)
In gimp_adaptive_supersample_area(), use the scratch allocator for
temporary buffers, instead of the regular allocator.
(cherry picked from commit 33d5eb2090)
... from menus.
The script-fu version is still available through pdb (for scripts) and
even in the action search. But in menus, only the new Python version
will be shown. Also update the description and name of the old version
to make clear it is deprecated in favor of the new plug-in.
Finally rename the new version to simply "plug-in-spyrogimp" (dropping
the "-plus" part as we should consider it as a replacement rather than
as another plug-in, which the "plus" would imply). Anyway the old one
was called "script-fu-spyrogimp", so there is no name clash.
While at it, do some trailing whitespace cleaning in the new plug-in.
Comment by reviewer (Jehan):
This was submitted through gimp-developer mailing list, by the same
author as the original Spyrogimp in script-fu, but this time in Python.
It does more than the original plug-in, with some automatic preview (by
drawing directly on a temporary layer, not as a GEGL preview), and using
the current tool options (current brush, etc.). The new API is similar
yet different. The much evolved possibilities makes that I don't think
it is worth trying to map 1-1 the new API to the old one, so I just let
the old plug-in next to the new one, with a different name.
Note finally that the author also contributed a new Spyrograph operation
to GEGL, yet with the comment: "The GEGL spyrograph operation is very
basic, and untested from gimp. I intend to keep developing it, since I
thought that on-canvas interaction would be very user-friendly. However,
I am not sure I will be able to get it work in a way that makes the
on-canvas interaction interactive enough.
Even if I do, it will not do what the Python plugin can do. It will be
much more basic."
So let's just integrate this evolved version of Spyrogimp for now. :-)
See: https://mail.gnome.org/archives/gimp-developer-list/2018-September/msg00008.html
Before each release, we prepare now a <release> tag. Unfortunately some
details are not always well known for sure in advance, in particular the
date of release (plans are made to be broken!), and also the release
news URL (since the date is in the URL). So I usually leave them as TODO
and until now, I never forgot to update them just before release. But
there is always the risk of forgetting.
Now the test for the appdata files will also look for remaining "TODO"
in the file if and only if the micro version is even (which means it's a
release). So we won't ever forget to update the file as long as we run
`make check` on the last commit (which we always do obviously).
(cherry picked from commit c0fed5afd6)
It got disabled in commit 0492157dd2 because of a bug in appstream-util,
which has been fixed for monthes now. Let's just reenable it and assume
anyone who wants to run a `make check` on GIMP uses a recent
distribution with up-to-date system tools.
(cherry picked from commit f83271a39b)
Also remove '.' at end of some <li>. `appstream-util` does not like full
stops in item lists, when in `validate-strict` mode (we don't test in
this mode, but it is worth improving the warning list a bit).
(cherry picked from commit 7a7de5c61c)
Add a "markers" page to the performance-log viewer, which lists
the event markers contained in the log, and allows navigating
between them.
Update docs accordingly.
(cherry picked from commit dafb63fd66)
When a fill zone was a bit too segmented, you'd want to just stroke
across it. But it was leaving some pieces uncolored, even though the
pointer dragged through it! The exact motion mode allows more events.
Note: I don't set it in the similar color filling (where it could have
been useful too) mostly because it is harder to remove events then (even
if a point was already filled, it could still serve as a seed for more
filling if threshold > 0), thus implied too much processing. Anyway in
all my tests, it was more a problem for line art filling anyway.
(cherry picked from commit 9c13058d54)
In GimpToolRectangle, fix the type of the cornder_radius field, so
that non-integer radii are properly displayed.
In GimpRectangleSelectOptions and GimpToolRectangle, increase the
maximal corner radius.
(cherry picked from commit a472696012)
We were doing it all the wrong way, fixing one combo box object at a
time. So this commit basically reverses commits 68a33ab5bd, 6dfca83c2a
and a9a979b2d0 and instead runs the same code in the class code. This
way, all objects based on these base classes will have the fix from
scratch.
These improved various other drop-down lists (I found some of them, and
probably not all) as I fixed all GIMP custom widgets based on
GtkComboBox.
Note that it has to be run after filling the list apparently (I had the
problem especially with GimpIntComboBox if running in the _init() code,
then the list widget showed wrong).
(cherry picked from commit 1d984542e9)
gimp_heal_motion(): when sample merged is active, simply initialize
the paint buffer from the projection instead of the drawable.
(cherry picked from commit e269a837cd)
When clearing a channel, do nothing if the channel is already
empty; otherwise, align the cleared rectangle to the channel
buffer's tile grid, so that all affected tiles are dropped, rather
than zeroed. Furthermore, only update the affected region of the
channel.
(cherry picked from commit ac5e4f4c33)
In commit c71b4916af, I forgot to disconnect signals on the bucket fill
options at finalization, leading the software to crash on an
non-existing tool.
(cherry picked from commit 0a952a3429)
After discussion with Sébastien Fourey and David Tschumperlé, it was
decided that a better fix for the edge case raised in #2785 was to add a
keypoint anyway, even if the point and none of its neigbours have a
positive smoothed curvature, yet they have a positive raw curvature. In
such case, we use the local maximum raw curvature instead of the local
maximum smoothed curvature.
(cherry picked from commit aa04258620)
In the perofmance-log viewer, add header-bar buttons to clear and
invert the selection, and allow inverting the selection by ctrl-
right-clicking on the sample-selection area.
Update the docs.
(cherry picked from commit b74c33db5c)
Additionally to sample merge and active layer, now we can only use the
layer above or below the active layer as line art source.
The line art fill is meant to work on drawing lines. Though sample merge
still is ok in many cases, the more you fill with colors, the more the
line art computation becomes unecessarily complex. Also when you use a
lot of layers with some of them already filled with colors, it makes it
impossible to colorize some line art zones with the tool. Moreover you
just don't want to have to hide every layers out there to colorize one
layer (especially background layers and such as you may want to see the
result with your background).
Thus we want to be able to set the source as a unique layer, while it
not being necessarily the active one (because you want lines and colors
on different layers). In this case, I am assuming that the color and the
line layers are next to each other (most common organization).
(cherry picked from commit c71b4916af)
In GimpTileBackendPlugin, change the default tile multiplier,
specifying the ratio between the backend tile-size, and GIMP's
tile-size, from 2 to 1. Since we're reading/writing each GIMP tile
using a separate command anyway, using a large multiplier doesn't
provide any benefits, while it does have drawbacks. In particular,
it reduces the chance that a write operation will affect an entire
tile, which allows us to avoid reading the tile data from GIMP.
(cherry picked from commit a5e2945b68)
Add an internal _gimp_tile_ref_noinit() function, which increases
the ref-count of a tile *without* initializing its data (in
particular, without reading its data from GIMP, or zeroing it.)
Use this function, instead of gimp_tile_ref(), when storing a tile
in GimpTileBackendPlugin, to avoid unnecessarily reading the tile
data from GIMP.
(cherry picked from commit 5ffdb9aa41)
In gimp_projection_finish_draw(), clear the chunk iterator's
priority rect before finishing rendering, since it's not needed at
this point, and this is slightly more efficient.
(cherry picked from commit 9833da3431)
In GimpFilterTool, when the filter uses an on-canvas controller,
provide a toggle in the tool's filter-options dialog allowing to
toggle the controller's visibility. This allows getting the
controller out of the way when unneeded.
(cherry picked from commit 33c22ae2a3)
Add mew gimp_tool_widget_{get,set}_visible() functions, which allow
setting the visibility of a tool widget. While the widget is
invisible, it ignores all events.
(cherry picked from commit f1a7abaef9)
In GimpDrawTool, do nothing in the tool-widget signal handlers if
the draw-tool isn't active, to avoid CRITICALs due to a NULL
display. This can happen if a widget is set before the tool is
started.
(cherry picked from commit 34e6c8734b)
Add a GimpToolWidget::message signal, which can be emitted by tool
widgets to display a message, instead of using the ::status signal.
Add corresponding gimp_tool_widget_message[_literal]() functions.
(cherry picked from commit 1ac4b85ce0)
Several en_GB to en_US.
Also "Show a preview of the transform_grided image". "grided" should be
"gridded", but I also have a problem with the underscore. Should it be
"transform-gridded"? Even so, does it really make sense?
I chose to just read "Show a preview of the transformed image", which I
think is simpler and the most understandable (we don't need to leak the
implementation with a transform grid into the human read text IMO). If
anyone think that was not the right choice, feel free to propose
otherwise.
Thanks to Bruce Cowan for noticing these.
(cherry picked from commit f9c170dfbd)
This is sometimes asked, and myself also need to find it from time to
time. I may as well put the link inside the code comments, where it is
just easy to find!
(cherry picked from commit 005bc1406b)
In gimp_projection_chunk_render_start(), when the current
projection rendering is complete, but not finalized yet, and no new
rendering is started (since the current update region is empty),
make sure to invalidate the projectable's preview, since it
normally happens when rendering is finalized, which doesn't happen
in this case.
(cherry picked from commit 42845c9462)
In gimp_projection_chunk_render_start(), don't leak the current
update region when it's empty, but not NULL, and properly shut down
the idle source.
(cherry picked from commit 0e5de95760)
In GimpTileBackendPlugin, return NULL when fetching z>0 tiles,
instead of simply ignoring the z coordinate, so that the mipmapped
tile is rendered locally. Likewise, avoid storing z>0 tiles.
Note that this is suboptimal, since all the necessary level-0 tiles
need to be sent to the buffer as a result. Ideally, we should
extend the wire protocol to handle mipmapped tiles.
(cherry picked from commit d0ae39f017)
In the gradient tool, halt the gradient editor before committing
the filter, so that its image-flush idle source is removed before
applying the operation, to avoid flushing the image, and hence
restarting its projection rendering, during application.
(cherry picked from commit 2256ab22f7)
In gimp_tile_handler_validate_buffer_copy(), temporarily remove the
source buffer's validate handler, is exists, so that the subsequent
gegl_buffer_copy() can use fast tile copying, using the TILE_COPY
command. GEGL currently only uses TILE_COPY when the source buffer
doesn't have any user-provided tile handlers.
(cherry picked from commit f4750a0ae7)
In gimp_gegl_apply_cached_operation(), replace the use of
GeglProcessor with GimpChunkIterator, so that we use the same
chunking logic as for rendering projections. This has the
advantage of better chunk alignment to the tile grid and dynamic
chunk sizing, which improve performance.
Use chunking even when there's no progress indication, since it
generally results in better cache locality.
(cherry picked from commit 4110f7b7b1)
Factor out the region-chunking logic of GimpProjection into a new
GimpChunkIterator type, providing a generic mechanism for iterating
over a cairo region in discrete chunks. The iterator doesn't
perform any processing itself, but rather dispenses rectangular
chunks, which the user then processes.
Iteration is broken into intervals, the duration of which is
configurable. Each iteration begins with a call to
gimp_chunk_iterator_next(), after which
gimp_chunk_iterator_get_rect() should be called in succession to
fetch a rectangle to process, until it returns FALSE, which marks
the end of the iteration. Updates to the UI should take place in
the interval between iterations, but not during an iteration. The
iterator dynamically adjusts the chunk size according to processing
speed, in order to match the target iteration interval.
The iterator can be given a priority rectangle, which is processed
before the rest of the region. It can also be given a
representative tile rectangle, defining a regular tile grid;
dispensed chunks are aligned to the tile grid as much as possible.
(cherry picked from commit ba9ce34e10)
Though the layer list will also show updated, it is much easier to look
at the layer name in the status bar whose position never changes.
Anyway it makes sense to just show a temporary status info message
giving the picked layer name, making it all the easier to find the layer
you are looking for.
(cherry picked from commit 496bc02b49)
In GimpTool, track the last-seen pointer coordinates, modifier
state, and event time, during button_press() and motion() events
and use those to synthesize a button_release() event when
comitting/halting the tool, if the tool is still active, and a
matching button_release() event has not been received.
The paint tools (as well as other tools) require each
button_press() event to be matched by a button_release() event in
order to properly finish their operation, but one isn't organically
generated when switching tools due to a device change.
(cherry picked from commit 9b25611857)
It is most likely the same issue as old bug 769550 (on bugzilla), which
is fixed with GTK+ 2.24.32. Back then, this version of GTK+ had not been
released yet so we only added a warning in the configure script. See
also commit b7345863.
Now it has been a year since GTK+ 2.24.32 has been released and any
distribution can just upgrade a micro version of GTK+ for bugfix. So
let's just drop the warning and do a hard requirement to 2.24.32.
In gimp_display_empty(), clear the image of all contexts whose
display is the current display, so that, in particular, when
subsequently updating the action groups, which causes certain
actions to be activated, the image that used to be bound to the
display is not found through the user context. This avoids re-
validating the image projection when closing the last image,
postponing image destruction.
(cherry picked from commit 49e57f8d6e)
The problem was not happening with the master code of
gimpdisplayshell-tool-events.c, but I encountered it in gimp-2-10 with
the layer picking code.
Even then, it still works, but I need to protect calls to
gdk_event_get_axis() to avoid CRITICALs.
Instead of having layer picking only on paint tools with alt-click, make
it available everywhere with alt-middle click. Moving through layers is
also a way to navigate an image, so it actually makes sense to be with
other modifiers (panning, zooming, rotating), while making the feature
more generic (this is definitely useful whatever the selected tool).
(cherry picked from commit 4c337353a0)
If you click on a zone filled in several visible layers, you don't
necessarily want the top layer. You may want one below. With this
change, as long as you hold alt, you will loop through all candidate
layers from top to bottom (then looping back top when reaching the
bottom).
In a first alt-click, you will always end up to the top candidate.
(cherry picked from commit 90e9eb3fca)
When working with a lot of layers, it is common to have to switch easily
between layers. And having to go back to the layer list is annoying and
also sometimes not practical at all when you can't find easily the right
layer. This is a first step in an experiment for such a feature, worked
together with Aryeom as advisor (and originator of the feature idea).
For now I apply this only to paint tools, though we are considering
having it as a generic modifier too, working whatever the tool. Yet we
wouldn't be able to use alt-left click (as it is used already in some
tools).
How it works is simply that in any paint tool, alt-click allows to
switch to the topmost layer having a visible pixel at the clicked
position.
(cherry picked from commit 3b59e6f61e)
gimp_metadata_add() which is used to set blobs or EXIF, XMP and IPTC
on a GimpMetadata also needs the logic to set "multiple" tags in one
go, or it will lose all but the first one.
(cherry picked from commit 479fd5b24b)
...for a less cramped look
With a minimum width of 300 instead of 200 pixels, much less device
names are cut off and need horizontal scrolling.
(cherry picked from commit ee6b629fa3)
In the bucket-fill tool, don't pre-calculate the line art when not
using a line-art fill area. Also, misc. cleanup.
(cherry picked from commit 823d4a0d24)
We were not taking into account tags that can appear multiple times,
such as "keyword", they are handled by gexiv2 with the
get_tag_multiple() and set_tag_multiple() functions.
gimp_metadata_deserialize_text(): when deserializing our XML format,
check if a tag is already set on the metadata as "multiple" and if yes
retrieve it, append the new value and set it again.
gimp_image_metadata_save_finish(): take care of "multiple" values when
copying tags to new metadata created for saving.
This should preserve all values across an "import, edit, export".
Thing will still break when using the metadata editor, it doesn't
handle multiple values at all, but that code is very hard to
understand.
(cherry picked from commit d708ac0b21)
The scratch allocator has been moved to GEGL (commit
gegl@b99032d799dda3436ffa8c1cc28f8b0d34fb965d). Remove gimp-
scratch, and replace all its uses with gegl-scratch.
(cherry picked from commit 889e2e26ee)
In GimpHistogramEditor, when the drawable preview is frozen, don't
duplicate the main histogram as the bg histogram if calculation is
still ongoing, since this will block until histogram calculation is
complete. In particular, this creates a noticeable stall when
beginning a paint stroke while the histogram is being calculated.
Instead, defer the creation of the bg histogram to the completion
of the calculation of the main histogram.
(cherry picked from commit 471efee769)
When writing floating-point instrumentation variables in
performance logs, always use the C locale, rather than the current
locale.
(cherry picked from commit 626208b17c)
Set the "x-dpi" and "y-dpi" options on the GdkPixbuf set on the
clipboard. There is not much more we can do, getting that value across
the clipboard is out of our control, but at least we set the vlaues
now.
(cherry picked from commit a0263f40d0)
Add on-canvas GUI (simple lines) for circular, linear and zoom motion
blur. The restrictions in the interaction show pretty well that there
is room for improvement here, the line is just a bit too generic, but
it's better than nothing.
(cherry picked from commit 39406b83d3)
In gimp_histogram_editor_update(), cancel any ongoing histogram-
calculation async before restarting the idle source. The async
will have been canceled anyway when recalculating the histogram
once the idle source is run, but we can cancel it as soon as we
know the histogram is outdated.
(cherry picked from commit 5561da87e6)
In gimp_histogram_calculate_async(), align the copied region of the
drawable and mask buffers to the tile grid, so that all copied
tiles are COWed.
(cherry picked from commit d56d663eaa)
...have the same scaling
gimp_prop_widget_new_from_pspec(): when restricting the scale to the
actual op area for pixel-coordinate and pixel-distance properties,
only use the max value in the axis direction for pixel-coordinate; for
pixel-distance make sure we use the same value on both axes, simply
use MAX (area.width, area.height).
(cherry picked from commit 0a1ecdf4ee)
...closing this image while the file is being loaded
Ref the image around all calls to file_open_layers() and
gimp_image_add_layers() so it stays around even if the user closes the
display in the meantime.
(cherry picked from commit fc4add7c2b)
Fix xcf-load.c to correct out-of-range item offsets (simply set them
to 0), so XCF files that are broken this way can still be recovered.
This doesn't fix the original bug, just recovering the crash images.
(cherry picked from commit b9265e7cde)
Leaving the one without the surname. My surname is not a secret at all,
but I really don't consider it necessary anyway.
Well if some day, another dev came in with the same first name, it will
still be time to update this file. :-)
(cherry picked from commit be0d41e1ad)
I am unsure of the problem, but it is fixed by using
poppler_document_new_from_gfile() instead of giving the contents of a
GMappedFile to poppler_document_new_from_data().
Using GFile is anyway usually prefered so I don't dig up more and just
make this change.
(cherry picked from commit a89e503054)
Still a lot more to do but pushing WIP to not have it wasted if more
commits come in from others.
Also got rid of some global variables.
(cherry picked from commit ff2d22d915)
As correctly spotted by Royce Pipkins, the buffer for the drawable's
pixel lines was too small.
Also fix the plug-in to hardcode "R'G'B'[A] u8" so it won't misbehave
on high bit-depth images, and make it work on all sorts of drawables,
not only "RGB*" (it will still always export RGB images).
(cherry picked from commit 74c9d835e8)
None of our load plug-ins have such a checkbox, so this is not
consistent. Moreover one you uncheck it, you just can't get back the
dialog until next GIMP restart. That's very bad usability.
(cherry picked from commit 948608e658)
This commit fixes the following error:
> attempted to install a procedure with a full menu path as menu label,
> this is not supported any longer.
Instead, if we want new items in menu, we should use
gimp_plugin_menu_register(). I add the calls, yet comment them out,
since I don't think we want these various conversion calls into the
provided filters. The proper way for data conversion should be through
babl/GEGL.
(cherry picked from commit 67a80c8667)
This is still very broken and it doesn't load well. But at least it
compiles!
All build errors (and a few warnings though not all) fixed.
(cherry picked from commit df8a20956b)
The whole bucket fill specific enum stuff is on its way out, so let's
keep this one out of libgimp for now until we decide how to present
line art filling in the PDB.
(cherry picked from commit 368f2e596a)
In GimpTileHandlerValidate, when rendering a whole tile in respone
to a TILE_GET command, use gegl_tile_handler_get_tile() to get the
tile without preserving its data, so that we avoid unnecessarily
fetching the tile from storage, or copying its data during
uncloning.
(cherry picked from commit 78ed038fca)
...palette views despite selected color being in the currently
selected pallette
As suggested by Massimo, changing the color comparison EPSILON in
gimppalette.c from 1e-10 to 1e-6 fixes this, and is really small
enough.
Also, generally clean up color comparison epsilons:
- use a #define, not hardcoded values for all uses of
gimp_rgb[a]_distance()
- call the #defines RGB_EPSILON and RGBA_EPSILON
- make them all 1e-6 or larger
(cherry picked from commit abd7cbfc8d)
...text layer, not an image of the text
In gimp_edit_paste_get_layer(), when pasting as floating selection,
collapse the pasted layer into an ordinary layer only if it's a group
layer. There is nothing that speaks against having a floating text
layer, it works just fine.
(cherry picked from commit 8a4aacb52f)
In GimpDrawableTreeView, show an error message when attempting to
select a different drawable while the image has an active floating
selection. In GimpLayerTreeView, also blink the editor button-row
when this happens, as a hint that the floating selection can be
committed/canceled through the buttons (we already highlight the
relevant ones.)
(cherry picked from commit 070e10eda7)
This includes gimp-tool-cursors-x2.xcf and cursorname-x2.png files,
they are simply 72x72 upscaled versions of the 36x36 fies with no
changes.
Anyone can now improve on cursors without having to deal with the
bulid process.
(cherry picked from commit ad5bf1dee7)
If the scale factor is 2 or larger, look for cursor images named
"filename-x2.png" and use them instead. Guess HiDPI based on the
monitor resolution being > 250 ppi, ugly but so what.
Manually scale up the default cursor if there is no "x2" image, using
NEAREST interpolation, which looks better than smooth scaling on HiDPI
monitors.
Next: adding better HiDPI cursor images.
(cherry picked from commit 8ff8f1d442)
Show an error message, and blink the layers-dialog lock-box, when
attempting to clear/cut a layer with a locked alpha channel.
(cherry picked from commit e967e5fa9e)
In gimp_drawable_edit_fill(), if the fill only affects the alpha
channel, and if the drawable has no alpha channel, or the alpha
channel is masked out, do nothing, instead of unnecessarily
performing the fill, which has no effect.
(cherry picked from commit 6384ff01b6)
In gimp_gegl_apply_cached_operation(), intersect the cached rects
with the dest rect, so that we don't unnecessarily (if not
erroneously) copy cached regions outside the dest rect to the dest
buffer. This can happen when the op's applicator crop-rect changes
dynamically.
(cherry picked from commit d9b4ffe09e)
In the warp tool, set the drawable-filter's crop area to the
combined stroke bounds, so that, when comitting the tool, only this
area is processed, instead of the entire drawable area.
(cherry picked from commit e06c4643dc)
In GimpDrawableFilter, when updating the entire filter area, only
update the crop/preview area (as set by
gimp_drawable_filter_set_{crop,preview}()), instead of the entire
drawable.
(cherry picked from commit b846ffed19)
Add gimp_drawable_filter_set_crop(), which allows setting an output
crop rectangle for the filter; anything outside the rectangle
doesn't get filtered. The crop area is combined with the preview
area to determine the filtered area during preview, however, unlike
the preview area, the crop area remains in effect while committing
the filter.
Consequently, when merging a drawable filter, if the filter has a
crop, only process the cropped area.
(cherry picked from commit 5c27d14fdf)
We're going to use GimpApplicator's output crop for more than just
split previews. Rename gimp_applicator_set_preview() to
gimp_applicator_set_crop(), and add gimp_applicator_get_crop(),
which returns the output crop rectangle, or NULL if cropping is
disabled.
(cherry picked from commit 7534ae53d6)
In GimpFilterTool, show the region combo when applying a non-point
op, as well as when applying a position-dependent point op. The
result of non-point ops may depend on the choice of input region,
even if the op is not position-dependent.
(cherry picked from commit 7949fd9a28)
In gimp_drawable_apply_operation(), use a temporary
GimpDrawableFilter to apply the operation, instead of using a
shadow buffer. This renders and composits the op directly into the
drawable buffer, avoiding an intermediate buffer, requiring less
space and speeding up processing.
(cherry picked from commit b201f73562)
Remove the use_split_preview and use_result_cache parameters of
gimp_applicator_new(), and allow enabling/disabling the cache
(through gimp_applicator_set_cache()) and the preview crop (through
gimp_applicator_set_preview()) after construction.
Move the preview crop node after the result cache, and remove the
separate preview cache node. This eliminates an extra cache
buffer, reducing the space consumed by filters, and speeds up split
preview, since the cached result now includes the output
compositing.
(cherry picked from commit ab52dc6bca)
In gimp_drawable_merge_filter(), align the region copied to the
undo buffer to the drawable buffer's tile grid, so that the copied
tiles are COWed.
(cherry picked from commit cba4bc4781)
We now perform the conversion of filter output to the drawable
format as part of the individual filter nodes (see the last few
commits), so there's no need for another conversion after the
filter stack.
This reverts commit d6e0ca5054.
(cherry picked from commit 95393722cc)
Set the output format of floating-selection applicators to the
target drawable format. We're going to remove the global
GipDrawable convert-format node, which we use to get correct
previews for indexed drawables, so that each filter now has to do
its own format conversion.
(cherry picked from commit 0560c5a6fe)
In GimpDrawableFilter, set the applicator's output format to the
drawable format, so that the cache uses the drawable format, and so
copying the cached result to the drawble's buffer when comitting
the filter becomes much cheaper, and, in particular, doesn't
require reading tiles out of the swap. This notably improves
commit speed in large images, at the expense of requiring a few
extra conversions during preview.
(cherry picked from commit 8e57ee2265)
In GimpApplicator, add gimp_applicator_set_output_format(), which
can be used to explicitly set the format of the result. In
particular, this allows controlling the output cache format, which
can speed up the merging of cached filters.
(cherry picked from commit b93df0311f)
In GimpLineArt, use the "invalidate-preview" signal of the input
viewable, instead of its "painted" or "rendered" signals, for
asynchronously computing the line art. Subsequently, remove the
aforementioned signals from GimpDrawable and GimpProjection,
respectively. This simplifies the code, and reduces the number of
signals.
(cherry picked from commit ef9b1f6694)
This commit completely removes the "Edit -> Fade..." feature,
because...
- The main reason is that "fade" requires us to keep two buffers,
instead of one, for each fadeable undo step, doubling (or worse,
since the extra buffer might have higher precision than the
drawable) the space consumed by these steps. This has notable
impact when editing large images. This overhead is incurred even
when not actually using "fade", and since it seems to be very
rarely used, this is too wasteful.
- "Fade" is broken in 2.10: when comitting a filter, we copy the
cached parts of the result into the apply buffer. However, the
result cache sits after the mode node, while the apply buffer
should contain the result of the filter *before* the mode node,
which can lead to wrong results in the general case.
- The same behavior can be trivially achieved "manually", by
duplicating the layer, editing the duplicate, and changing its
opacity/mode.
- If we really want this feature, now that most filters are GEGL
ops, it makes more sense to just add opacity/mode options to the
filter tool, instead of having this be a separate step.
(cherry picked from commit ed7ea51fb7)
... in GimpBucketFillOptions for the line art algorithm.
Inside GimpLineArt, there are still 2 properties, but we don't show them
anymore in the Bucket Fill tool options. One of the main reason is
probably that it's hard to differentiate their usage. One is to close
with curved lines, the other with straight segments. Yet we don't
actually have any control on one or the other. All one knows is that you
can have "holes" in your drawing of a given size and you want them
close-like for filling. Only reason I can see to have 2 types of closure
is whether you'd want to totally disable one type of closure (then you
set it to 0). But this is a very limited reason for making the options
less understandable overall, IMO.
So for the time being, let's show up only a single option which sets
both properties in GimpLineArt. As patdavid says "it makes sense as a
first pass".
Also rename the option to shorter/simpler "Maximum gap length". Thanks
to patdavid and pippin for helping on figuring out this better label!
Finally I am bumping the default for the gaps to 100px. The original
values were ok for the basic small images used in demos, but not for
real life image where it was always too short (even 100px may still be
too short actually, but much better than the 20 and 60px from before!).
(cherry picked from commit 503775a5a0)
Improve the speed of gimp_gradient_get_color_at(), which is used by
gimp:gradient during processing when the gradient cache is too big,
by disabling type checking, and inlining and avoiding some function
calls.
(cherry picked from commit 93f4b18704)
Practically it means that the algorithm won't close line art anymore
with both settings at 0. This can nevertheless still be a very useful
tool when you have a drawing style with well-closed lines. In such a
case, you will still profit from the color flooding under the line art
part of the algorithm.
Moreover with such well-closed zones from start, you don't get the
over-segmentation anymore and the threaded processing will be faster
obviously.
(cherry picked from commit 0a2d066168)
Zlib is a "better" compression in the meaning that it is a more advanced
and complex algorithm than RLE. And in most cases, it should end up in
smaller file sizes. But as any algorithm, there may be cases when the
expectations are not met (worst cases or such). That's the nature of the
maths. Still we should not make the checkbox text over-complicated (it
is not the place to teach algorithmic), yet we can at least add a small
tooltip text.
(cherry picked from commit c3ac722995)
This was my initial choice, but the more I think about it, the less I am
sure this was the right choice. There was some common code (as I was
making a common composite bucket fill once the line art was generated),
but there is also a lot of different code and the functions were filled
of exception when we were doing a line art fill. Also though there is a
bit of color works (the way we decide whether a pixel is part of a
stroke or not, though currently this is basic grayscale threshold), this
is really not the same as other criterions. In particular this was made
obvious on the Select by Color tool where the line art criterion was
completely meaningless and would have had to be opted-out!
This commit split a bit the code. Instead of finding the line art in the
criterion list, I add a third choice to the "Fill whole selection"/"Fill
similar colors" radio. In turn I create a new GimpBucketFillArea type
with the 3 choices, and remove line art value from GimpSelectCriterion.
I am not fully happy yet of this code, as it creates a bit of duplicate
code, and I would appreciate to move some code away from gimpdrawable-*
and gimppickable-* files. This may happen later. I break the work in
pieces to not get too messy.
Also this removes access to the smart colorization from the API, but
that's probably ok as I prefer to not freeze options too early in the
process since API needs to be stable. Probably we should get a concept
of experimental API.
(cherry picked from commit cd924f453a)
After discussing with Mitch, it turn out commit 717c183a3e was fixing
(or rather working around) actual issues of broken device/usb stack
issues on Linux, as expected.
Nevertheless on Windows, this broke in turn many tablets (see commit
ce24e16083). Therefore we do a very ugly #ifdef to bail from duplicate
devices on Windows whereas we continue on Linux. This fix and difference
of behavior is completely empirical, rather than based on actual good
logics, so that's quite annoying, but well… not much choice here.
Also note that since we had no report of breakage on other OSes (such as
macOS/BSD), at least that I know of, I let them with the Linux code
path.
(cherry picked from commit 74a7a5d3e2)
Currently in bucket fill tool, the modifier was only switching fg to bg
and bg to fg, and was doing nothing when pattern was set. I make it
switch to fg as well (and remember which was the original value).
(cherry picked from commit 5a157bf1ba)
The code was too much spread out, in core and tool code, and also it was
made too specific to fill. I'll want to reuse this code at least in the
fuzzy select tool. This will avoid code duplication, and also make this
new process more self-contained and simpler to review later (the
algorithm also has a lot of settings and it is much cleaner to have them
as properties rather than passing these as parameters through many
functions).
The refactoring may not be finished; that's at least a first step.
(cherry picked from commit db18c679f3)
In particular, make simpler code in a few places, taking abyss value
into account (rather than checking the position).
(cherry picked from commit f7a4ce1051)
In particular, it allows to easily color pick. This just makes sense as
the bucket fill is definitely what one could call a "color tool", and
being able to easily change color without having to constantly switch to
color picker tool nor open a color chooser dialog is a must.
The fill type option (FG/BG/Pattern) was already mapped to the common
toggle behavior key (Ctrl on Linux), which is commonly used for
switching to color picker on paint tools. So I decided to remap the fill
type switch to GDK_MOD1_MASK (Alt on Linux) to keep consistent with
other tools (at the price of a change for anyone used to this modifier,
though I doubt it was that much used).
I also made possible to combine the 2 modifiers (so you could pick the
foreground or background color with ctrl and ctrl-alt).
(cherry picked from commit 5d4281944f)
The smart colorization was leaving irritating single pixels in between
colorized regions, after growing and combining. So let's just flood
these. We don't flood bigger regions (and in particular don't use
gimp_gegl_apply_flood()) on purpose, because there may be small yet
actual regions inside regions which we'd want in other colors. 1-pixel
regions is the extreme case where chances that one wanted it filled are
just higher.
(cherry picked from commit 744d67939d)
The distance map has all the information we need already. Also we will
actually grow up to the max radius pixel (middle pixel of a stroke).
After discussing with Aryeom, we realized it was better to fill a stroke
fully (for cases of overflowing, I already added the "Maximum growing
size" property anyway).
(cherry picked from commit 6bec0bc82d)
When flooding the line art, we may overflood it in sample merge (which
would use color in the line art computation). And if having all colors
on the same layer, this would go over other colors (making the wrong
impression that the line art leaked).
This new option is mostly to keep some control over the mask growth.
Usually a few pixels is enough for most styles of drawing (though we
could technically allow for very wide strokes).
(cherry picked from commit eb042e6c87)
I had this funny behavior when I was quitting GIMP with the active tool
using modifiers (for instance bucket fill). Each time I'd quit with
ctrl-q (and if the image is not dirty), the options would use the value
from the modifier state and be saved as-is. Hence at next restart, the
default value was always different!
(cherry picked from commit dd3d9ab3dd)
For this, I needed distmap of the closed version of the line art (after
splines and segments are created). This will result in invisible stroke
borders added when flooding in the end. These invisible borders will
have a thickness of 0.0, which means that flooding will stop at once
after these single pixels are filled, which makes it quick, and is
perfect since created splines and segments are 1-pixel thick anyway.
Only downside is having to run "gegl:distance-transform" a second time,
but this still stays fast.
(cherry picked from commit 5a4754f32b)
We don't really need to flow every line art pixel and this new
implementation is simpler (because we don't actually need over-featured
watershedding), and a lot lot faster, making the line art bucket fill
now very reactive.
For this, I am keeping the computed distance map, as well as local
thickness map around to be used when flooding the line art pixels
(basically I try to flood half the stroke thickness).
Note that there are still some issues with this new implementation as it
doesn't properly flood yet created (i.e. invisible) splines and
segments, and in particular the ones between 2 colored sections. I am
going to fix this next.
(cherry picked from commit 3467acf096)
Introduced in commit b4e12fbbbb:
gimp_pickable_contiguous_region_prepare_line_art_async() was running
gimp_pickable_flush(), which provokes the "rendered" signal on the
image projection when a change occured. As a result, it was calling
gimp_bucket_fill_compute_line_art() within itself and since
tool->priv->async was not set yet, none of the call were canceled. Hence
the same line art is computed twice, but one is leaked.
Make sure we block this signal handler as a solution.
(cherry picked from commit 36c885a6df)
This commit is based on GEGL master as I just made the auxiliary buffer
of gegl:watershed-transform optional for basic cases.
It doesn't necessarily makes the whole operation that much faster
according to my tests, but it makes the code simpler as creating this
priority map was quite unnecessary.
(cherry picked from commit 963eef8207)
... and use in bucket-fill tool
Add gimp_pickable_contiguous_region_prepare_line_art_async(), which
computes a line-art asynchronously, and use it in the bucket-fill
tool, instead of having the tool create the async op.
This allows the async to keep running even after the pickable dies,
since we only need the pickable's buffer, and not the pickable
itself. Previously, we reffed the pickable for the duration of the
async, but we could still segfault when unreffing it, if the
pickable was a drawable, and its parent image had already died.
Furthermore, let the async work on a copy of the pickable's buffer,
rather than the pickable's buffer directly. This avoids some race
conditions when the pickable is the image (i.e., when "sample
merged" is active), since then we're using image projection's
buffer, which is generally unsafe to use in different threads
concurrently.
Also, s/! has_alpha/has_alpha/ when looking for transparent pixels,
and quit early, at least during this stage, if the async in
canceled.
(cherry picked from commit b4e12fbbbb)
When computing line-art, don't ref the bucket-fill tool in the
async data, and rather cancel any ongoing async upon tool
destruction, so that the async callback doesn't attept to touch the
now-dead tool. This avoids segfaulting in the async callback when
switching to a different tool, while a line-art async operation is
active.
Additionally, always cancel any previous async operation in
gimp_bucket_fill_compute_line_art(), even if not starting a new
one.
(cherry picked from commit 663a6c7011)
In the line-art async function, pass ownership over the resulting
buffer to the async object, so that the buffer is properly freed in
case the async in canceled after line-art computation is complete,
but before the completion callback is called.
Also, clear the tool's async pointer in the completion callback, to
avoid leaking the last issued async.
(cherry picked from commit 2e45c4c8c8)
The "update" signal on drawable or projection can actually be emitted
many times for a single painting event. Just add new signals ("painted"
on GimpDrawable and "rendered" on GimpProjection) which are emitted once
for a single update (from user point of view), at the end, after actual
rendering is done (i.e. after the various "update" signals).
Also better support the sample merge vs current drawable paths for
bucket fill.
(cherry picked from commit 047265333c)
Since commit b00037b850, erosion size is not used anymore, as this step
has been removed, and the end point detection now uses local thickness
of strokes instead.
(cherry picked from commit 3f58a38574)
Previous algorithm was relying on strokes of small radius to detect
points of interest. In order to work with various sizes of strokes, we
were computing an approximate median stroke thickness, then using this
median value to erode the binary line art.
Unfortunately this was not working that well for very fat strokes, and
also it was potentially opening holes in the line art. These holes were
usually filled back later during the spline and segment creations. Yet
it could not be totally assured, and we had some experience where color
filling would leak out of line art zones without any holes from the
start (which is the opposite of where this new feature is supposed to
go)!
This updated code computes instead some radius estimate for every border
point of strokes, and the detection of end points uses this information
of local thickness. Using local approximation is obviously much more
accurate than a single thickness approximation for the whole drawing,
while not making the processing slower (in particular since we got rid
of the quite expensive erosion step).
This fixes the aforementionned issues (i.e. work better with fat strokes
and do not create invisible holes in closed lines), and also is not
subject to the problem of mistakenly increasing median radius when you
color fill in sample merge mode (i.e. using also the color data in the
input)!
Also it is algorithmically less intensive, which is obviously very good.
This new version of the algorithm is a reimplementation in GIMP of new
code by Sébastien Fourey and David Tschumperlé, as a result of our many
discussions and tests with the previous algorithm.
Note that we had various tests, experiments and propositions to try and
improve these issues. Skeletonization was evoked, but would have been
most likely much slower. Simpler erosion based solely on local radius
was also a possibility but it may have created too much noise (skeleton
barbs), with high curvature, hence may have created too many new
artificial endpoints.
This new version also creates more endpoints though (and does not seem
to lose any previously detected endpoints), which may be a bit annoying
yet acceptable with the new bucket fill stroking interaction. In any
case, on simple examples, it seems to do the job quite well.
(cherry picked from commit b00037b850)
Other bucket fills are now done as filter until committed, but basic
selection fill is still done automatically. So let's make sure the
canvas is updated immediately (as it used to be before my changes).
(cherry picked from commit 287d90ba9e)
I have not added all the options for this new tool yet, but this sets
the base. I also added a bit of TODO for several places where we need to
make it settable, in particular the fuzzy select tool, but also simply
PDB calls (this will need to be a PDB context settings.
Maybe also I will want to make some LineArtOptions struct in order not
to have infinite list of parameters to functions. And at some point, it
may also be worth splitting a bit process with other type of
selection/fill (since they barely share any settings anyway).
Finally I take the opportunity to document a little more the parameters
to gimp_lineart_close(), which can still be improved later (I should
have documented these straight away when I re-implemented this all from
G'Mic code, as I am a bit fuzzy on some details now and will need to
re-understand code).
(cherry picked from commit 824af12438)
Rather than just having a click interaction, let's allow to "paint" with
the bucket fill. This is very useful for the new "line art" colorization
since it tends to over-segment the drawing. Therefore being able to
stroke through the canvas (rather than click, up, move, click, etc.)
makes the process much simpler. This is also faster since we don't have
to recompute the line art while a filling is in-progress.
Note that this new behavior is not only for the line art mode, but also
any other fill criterion, for which it can also be useful.
Last change of behavior as a side effect: it is possible to cancel the
tool changes the usual GIMP way (for instance by right clicking when
releasing the mouse button).
(cherry picked from commit e1c4050617)
This makes the speed sensation of the tool much faster as line art can
be computed in dead time when you start the tool or when you move the
pointer.
(cherry picked from commit a3cda4abbe)
Right now, this is mostly meaningless as it is still done sequentially.
But I am mostly preparing the field to pre-compute the line art as
background thread.
(cherry picked from commit f246f40494)
The older labelling based off CImg code was broken (probably because of
me, from my port). Anyway I realized what it was trying to do was too
generic, which is why we had to fix the result later (labeling all
non-stroke pixels as 0, etc.). Instead I just implemented a simpler
labelling and only look for stroke regions. It still over-label a bit
the painting but a lot less, and is much faster.
(cherry picked from commit 93a49951a0)
I don't actually need to loop through borders first. This is what the
abyss policy is for, and I can simply check the iterator position to
verify I am within buffer boundaries or not.
This simplifies the code a lot.
(cherry picked from commit c4ff81540d)
We actually don't need to compute distance map. I just make the simplest
priority map, with 1 any line art pixel and 0 any other pixel (in mask
or not), lowest priority being propagated first.
And let the flooding begin!
(cherry picked from commit 410c747509)
... labels buffer.
We can watershed directly the mask buffer being correctly flagged.
This commit relies on merge request gegl!8 being accepted and merged.
(cherry picked from commit e905ea7ba2)
Also use more GeglBufferIterator on input GEGL buffer.
Using a char array is much less expensive and accelerated the line
erosion a lot!
Moving to GeglBufferIterator is not finished, but I do in steps.
(cherry picked from commit 0c80f8a718)
When filling colors in line arts, you don't want to leave space between
the strokes and the color, which usually happen with any of the current
selection methods.
A "KISS" trick is usually to grow your selection a few pixels before
filling (adding an additional step in colorization process), which
obviously does not handle all cases (depending on drawing style and
stroke size, you may need to grow more or less) as it doesn't take into
account actual stroke geometry.
Instead, I label the selection and the "rest" differently and leave the
pixel strokes unlabelled. Then I let these unlabelled pixels be flooded
by the "gegl:watershed-transform" operation.
Note that this second step is different from the second step from the
GREYC research paper, as they use their own watershed algorithm taking
color spots as sources to color the whole image at once. This is a
different workflow from the one using bucket fill with a single color
source.
(cherry picked from commit 8502b4e743)
This commit implements part of the research paper "A Fast and Efficient
Semi-guided Algorithm for Flat Coloring Line-arts" from the GREYC (the
people from G'Mic). It is meant to select regions from drawn sketchs in
a "smart" way, in particular it tries to close non-perfectly closed
regions, which is a common headache for digital painters and colorists.
The implementation is not finished as it needs some watersheding as well
so that the selected area does not leave "holes" near stroke borders.
The research paper proposes a new watersheding algorithm, but I may not
have to implement it, as it is more focused on automatic colorization
with prepared spots (instead of bucket fill-type interaction).
This will be used in particular with the fuzzy select and bucket fill
tools.
Note that this first version is a bit slow once we get to big images,
but I hope to be able to optimize this.
Also no options from the algorithm are made available in the GUI yet.
(cherry picked from commit 8ed12b1b98)
Showing it was only displaying the top modes, with a lot of top space,
and you had to slowly scroll down the list. This is the same as #2642
(as Alexandre noted in a comment), so I just use the same "fix" though I
don't fully understand it. It feels more of a side effect of
gtk_combo_box_set_wrap_width() working around a bug of GtkComboBox. So
if anyone has a better fix and understand the issue, feel free to patch
(maybe GTK+ directly?). In the meantime, it works well enough. :-)
(cherry picked from commit 6dfca83c2a)
Update the definition of the "cache-compressed" and "swap-
compressed" dashboard variables, to reflect the changes made by
GEGL commit gegl@dc22e997757ab91c180244d5290d094d2ea8572f.
(cherry picked from commit fda53f9c18)
In the warp tool, when the warp is empty and the current behavior
has no effect as a result (i.e., when it's ERASE or SMOOTH), show
an error message in the status bar, and blink the behavior combo
widget in the tool options, to hint at the source of the error.
(cherry picked from commit 7958387d54)
In the warp tool, when no stroke events are selected, blink the
stroke frame widget in the tool options, in addition to showing an
error message in the status bar, to hint at the source of the
error.
(cherry picked from commit 17cc44a7be)
The enumerators of the GimpWarpBehavior enum, except for MOVE, had
a GEGL_ prefix, rather than a GIMP_ prefix, for some reason.
Change all of them to GIMP_.
(cherry picked from commit 2085cb4a37)
Since commit fe139e5662, when
blinking a widget, we cancel blinking for all its ancestors. Avoid
redrawing all the ancestors as a result, unless they're actually
blinking. This prevents some noticeable lag when blinking a
widget.
(cherry picked from commit 5a2dee29d7)
In all tools, when the current item can't be edited due to its lock
mask, use gimp_tools_blink_lock_box(), added in the previous
commit,to blink the lock box of the corresponding dockable, in
addition to showing an error message in the status bar, to hint at
the source of the error.
(cherry picked from commit 637105b962)
Add gimp_tools_blink_lock_box() utility function, in a new
gimptools-utils.c file, which takes a GimpItem, and blinks the
GimpItemTreeView lock-box of the corresponding dockable. This can
be used to hint that the item's lock toggles are preventing it from
being edited.
(cherry picked from commit 9bdaec3a49)
When blinking a widget using gimp_widget_blink(), cancel the
blinking of all its ancestors, to reduce visual clutter.
(cherry picked from commit fe139e5662)
In the paint tools, when the current paint mode is invalid, i.e.,
when it requires an alpha channel, but the the current drawable has
no alpha channel, or its alpha channel is locked, blink the paint-
mode box widget in the tool options, in addition to showing an
error message in the status bar, to hint at the source of the
error.
(cherry picked from commit 464bf1b0a9)
In the transform tools, when there is no item of the selected type
to transform, blink the move-type box widget in the tool options,
in addition to showing an error message in the status bar, to hint
at the source of the error.
(cherry picked from commit 17412aa234)
In the move tool, when there is no item of the selected type to
move, blink the move-type box widget in the tool options, in
addition to showing an error message in the status bar, to hint at
the source of the error.
(cherry picked from commit c9bc3d7a09)
In the selection tools, when the selected operation is invalid,
i.e., when trying to subtract-from or intersect-with an empty
selection, blink the selection-mode box widget in the tool options,
in addition to showing an error message in the status bar, to hint
at the source of the error.
(cherry picked from commit f990e41609)
In gimp_tool_compass_update_angle(), use fuzzy comparisson when
determining whether to update the angle properties, to avoid
infinite recursion due to floating-point inaccuracies. In
partcicular, on x86, when using the x87 FPU rather than SSE, the
floating-point registers are 80-bit, while the properties are
stored as 64-bit, which can create small discrepancies between the
calculated angles and the stored values.
(cherry picked from commit ad831dbc6d)
We had many reports of tablets from various brands (Huion, Gaomon,
XP-Pen…) broken in the last release (though working fine when
downgrading to 2.10.6). Latest Huion drivers seem to fix the issue
(according to at least one report), but this is not the case for other
tablets.
Though unable to test myself, provided stderr logs indicate that we hit
the case when 2 devices with the same name are registered. Therefore
this commit is basically reverting commit 717c183a3e (though keeping and
completing the comments). I don't think there is an ultimate solution
here but with this regression, experience shows us there seem to be a
lot more breakage when overwriting the device with newer occurences (at
least on Windows). It is unclear though if commit 717c183a3e was also
supposed to fix another case actually encountered. If so, we will need
to get an even more advanced solution.
(cherry picked from commit ce24e16083)
As I did on app/, finalizing an output stream also implicitly flushes
and closes it. Hence if an export ended with an error, we'd end up with
incomplete data file (possibly overwriting a previously exported image).
Only 2 plug-ins I haven't fixed yet are file-tiff-io and file-gif-save.
The later one don't even clean up its memory (which somehow is good here
as at least the output stream is never finalized hence sane files are
not overwritten in case of errors). As for the former (TIFF plug-in), it
doesn't even seem to have any error control AFAICS, apart from printing
error messages on standard error output.
(cherry picked from commit 66ec467217)
When an error occurs, we want to prevent overwriting any previous
version of the file by incomplete contents. So run
g_output_stream_close() with a cancelled GCancellable to do so.
See also discussion in #2565.
(cherry picked from commit 613bf7c5ab)
We can cancel a file overwrite at the last second when closing the
stream by setting a cancelled cancellable. Current code was simply not
closing the stream, but this was not enough as overwriting was happening
anyway (probably when finalizing).
This will allow much safe saving process since we would not be
overwriting a previously sane XCF file when an error occurred (either in
our code or a memory error, or whatnot).
See also discussion in #2565.
(cherry picked from commit 076b53511a)
In GimpProjection's chunk renderer, when the chunk height changes
in the middle of a row, we need to merge the remainder of the
current render area back into the renderer's update region, and
refetch the remainder of the row as the new render area, so that we
don't miss any unrendered area, or re-render already-rendered area,
due to the change in chunk height. However, we should previously
fail to verify that the fetched area is, in fact, the remainder of
the current row, which could cause us to render the wrong area,
missing parts of the update region.
Fix this, by breaking up some of the chunk-renderer fucntions into
smaller sub-functions, and using those in order to explicitly set
the new render area to the remainder of the current row when the
chunk height changes. This also avoids erroneously merging the
unflushed update region of the projection into the renderer's
update region.
(cherry picked from commit c9c2397b0d)
Actually, image grids are saved as parasites, so even though older
GIMP versions round their coordinates upon loading, they maintain
the fractional coordinates when re-saving the image, hence bumping
the XCF version is not really necessary.
This reverts commit 13119efda33a7aba323dc13e6a56207a15a9f000.
(cherry picked from commit 411ddb7e48)
Fractional-coordinate support for image grids was added in commit
1572bccc9f, right before the
introduction of XCF version 10. While images with fractional grid
coordinates can be loaded with earilier versions of GIMP, the grid
coordinates are rounded to the nearest integer.
Bump the minimal XCF version when saving images with fractional
grid coordinates to 10, which should have been the case all along.
(cherry picked from commit a90322278d)
The NULL terminator of the tile-offset array of dummy buffer-levels
is erroneously written as an int32, instead of an offset, even in
version-11+ XCFs, in which offsets are 64-bit.
Since the dummy levels aren't actually used by GIMP, we're going to
keep these fields as int32 as an exception, in order to remain
consistent with existing XCFs, and just add a comment in the code,
and update the docs. If we ever make use of the higher buffer
levels, we should change these fields to offsets, and bump the XCF
version.
(cherry picked from commit 2168d91cf7)
Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
initialize it from gimp_export_color_profile() in
gimp_image_metadata_save_prepare().
Adapt all plug-ins to use the bit from the suggested export flags and
pass the actually used value back to
gimp_image_metadata_save_finish().
This changes no behavior at all but creates hooks on the libgimp side
that are called with the context of an image before and after the
actual export, which might become useful later. Also, consistency
is good even though the color profile is not strictly "metadata".
(cherry picked from commit c667fdc5c0)
by using gimp_image_get_effective_color_profile() instead of just
_get_color_profile(). Don't look at the preference setting because PSD
should behave more like "save" than "export" and save everything.
(cherry picked from commit a35b243f9b)
...export dialogs
Move most stuff out of the "Advanced" expander, only nerdish encoding
options are left there.
Issue #701: Add a "Save color profile" toggle which honors the default
value configured in preferences and always saves the profile when
enabled.
(cherry picked from commit 540cfa9611)
Add a boolean "direct" parameter to gimp_projection_flush_now(),
which specifies if the projection buffer should only be invalidated
(FALSE), or rendered directly (TRUE).
Pass TRUE when flushing the projection during painting, so that the
affected regions are rendered in a single step, instead of tile-by-
tile. We previously only invalidated the projection buffer, but
since we synchronously flush the display right after that, the
invalidated regions would still get rendered, albeit less
efficiently.
Likewise, pass TRUE when benchmarking the projection through the
debug action, and avoid flushing the display, to more accurately
measure the render time.
(cherry picked from commit dac9bfe334)
Don't use a direct-buffer fill if the mode is subtractive, and the
composite region includes the source. Currently, this never
actually happens.
(cherry picked from commit 660f53d300)
In gimp_drawable_edit_fill(), when filling/clearing the whole
drawable, without any special compositing (i.e., when there's no
selection, the opacity is 100%, and the layer mode is trivial),
fill/clear the drawable's buffer directly, without using an
applicator. This makes such operations much faster, especially in
big images.
(cherry picked from commit dd8268c0a2)
... which is similar to gimp_fill_options_create_buffer(), however,
it fills an existing buffer, instead of creating a new buffer.
Implement gimp_fill_options_create_buffer() in terms of the new
function.
(cherry picked from commit 45fc4cb4f9)
Add a TRIVIAL layer-mode flag, and corresponding
gimp_layer_mode_is_trivial() function, which indicates if the blend
function of a given layer mode is trivial, i.e., either never
modifies the source pixels (for non-subtractive modes), or always
clears the destination pixels (for subtractive modes).
(cherry picked from commit 8adec5fb3a)
... which clears the alpha component of a given buffer region,
i.e., it makes the region transparent, while preserving color
information. This corresponds to the "edit-clear" action.
(cherry picked from commit 2e3eab7fbd)
In gimp_paint_core_finish(), when copying the relevant region of
the cached undo buffer into a new buffer, align the region to the
buffer's tile grid, so that all copied tiles are COWed. This
avoids lag when finishing a stroke.
(cherry picked from commit 861f356b63)
When creating a drawable undo from the drawable's buffer, align the
copied rectangle to the buffer's tile grid, so that all the copied
tiles are COWed, saving memory and gaining speed.
Add applied_x and applied_y fields to GimpDrawableUndo, specifying
the position at which to apply the applied_buffer, so that we apply
it in the right place, even if the undo rect has changed due to
alignment.
(cherry picked from commit bb9dd049fb)
...export dialogs
Remove the "Advanced" expanders from the PNG and TIFF export
dialogs. This does not reorder anything in the GUI yet, the
dialogs are still ugly.
In the Luminance layer-mode, use the scratch allocator for
allocating temporary buffers, instead of using VLAs.
GimpOperationLayerMode already allocates data on the stack,
calculated as not to overflow the stack on any platform, so having
any of its descendants also allocate big buffers on the stack is
risky.
(cherry picked from commit 70b7316ebc)
Add a scratch-total variable to the dashboard's misc group, showing
the total amount of memory used by the scratch allocator.
(cherry picked from commit 698d1af798)
gimp-scratch is a fast memory allocator (on the order of magnitude
of alloca()), suitable for small (up to a few megabytes), short-
lived (usually, bound to the current stack-frame) allocations.
Unlike alloca(), gimp-scratch doesn't use the stack, and is
therefore safer, and will also serve bigger requests, by falling-
back to malloc().
The allocator itself is very simple: We keep a per-thread stack of
cached memory blocks (allocated using the normal allocator). When
serving an allocation request, we simply pop the top block off the
stack, and return it. If the block is too small, we replace it with
a big-enough block. When the block is freed, we push it back to
the top of the stack (note that even though each thread uses a
separate stack, blocks can be migrated between threads, i.e.,
allocated on one thread, and freed on another thread, although this
is not really an intended usage pattern.) The idea is that the
stacks will ultimately stabalize to contain blocks that can serve
all the encountered allocation patterns, without needing to reisze
any of the blocks; as a consequence, the amount of scratch memory
allocated at any given time should really be kept to a minimum.
(cherry picked from commit a8a8655285)
Use gimp_async_add_callback_for_object(), added in the previous
commit, instead of gimp_async_add_callback(), in cases where the
destructor of the object owning the async doesn't wait for the
async to finish. This avoids leaking such ongoing asyncs on
shutdown, during which gimp-parallel either finishes or aborts the
asyncs: if at this point an async has any registered callbacks, an
idle source is added for running the callbacks, extending the
lifetime of the async; however, since we're not getting back into
the main loop, the idle is never run, and the async (and any
associated resources) are never freed.
(cherry picked from commit 7c00cf498a)
... which is similar to gimp_async_add_callback(), taking an
additional GObject argument. The object is kept alive for the
duration of the callback, and the callback is automatically removed
when the object is destroyed (if it hasn't been already called).
This is analogous to g_signal_connect_object(), compared to
g_signal_connect().
(cherry picked from commit 49fd2847ac)
In gimp_async_remove_callback(), if removing the last callback
while the callback idle-source is already pending, cancel the idle
source and unref the async object (the async is reffed when adding
the idle source.)
(cherry picked from commit a779dd3849)
Use gimp_tile_handler_validate_validate(), added in the commit
before last, in gimp:buffer-source-validate, in order to pre-render
the necessary region of the buffer, instead of performing the
validation implicitly by iterating over the region. This is both
simpler, and, more importantly, allows us to render the entire
region in a single chunk, instead of tile-by-tile, which can be
considerably more efficient, especially with high thread counts.
This essentially extends the dynamic sizing of rendered projection
chunks to layer groups, which are rendered through
gimp:buffer-source-validate, rather than just the main image
projection.
(cherry picked from commit 83dd94ba6a)
Use gimp_tile_handler_validate_validate(), added in the last
commit, in GimpProjection, in order to render the projection,
instead of separately invalidating the buffer, undoing the
invalidation, and then rendering the graph. This is more
efficient, and more idiomatic.
(cherry picked from commit d6f0ca5531)
... which validates a given rectangle directly into the buffer,
possibly intersecting it with the dirty region. This is more
efficient than either invalidating, un-invalidating, and rendering
a given rect, as we're doing in GimpProjection, or validating the
buffer tile-by-tile, as we're doing in gimp:buffer-source-validate.
(cherry picked from commit 82a60997d4)
... which is similar to the ::validate() vfunc, however, it should
render the result to the provided GeglBuffer, instead of to a
memory buffer.
Provide a default implementation, which uses
gegl_node_blit_buffer() if the default ::validate() implementation
is used, or, otherwise, calls uses
gegl_buffer_linear_{open,close}(), and passes the returned memory
buffer to ::validate().
(cherry picked from commit 0ad41cfe0c)
Add begin_validate() and end_validate() virtual functions, and
corresponding free functions, to GimpTileHandlerValidate. These
functions are called before/after validation happens, and should
perform any necessary steps to prepare for validation. The default
implementation suspends validation on tile access, so that the
assigned buffer may be accessed without causing validation.
Implement the new functions in GimpTileHandlerProjectable, by
calling gimp_projectable_begin_render() and
gimp_projectable_end_render(), respectively, instead of calling
these functions in the ::validate() implementation (which, in turn,
allows us to use the default ::validate() implementation.)
In GimpProjection, use the new functions in place of
gimp_projectable_{begin,end}_render().
(cherry picked from commit 5a623fc54b)
In gimp_projection_finish_draw(), make sure we don't accidentally
re-start the chunk renderer idle source while running the remaining
iterations, in case the chunk height changes, and we need to reinit
the renderer state.
(cherry picked from commit 8a47b68194)
Don't needlessly flush projections whose buffer hasn't been
allocated yet. This can happen when opening an image, in which
case the image is flushed before its projection has a buffer.
(cherry picked from commit b07f810273)
When an async that was created through
gimp_parallel_run_async[_full](), and whose execution is still
pending, is being waited-upon, maximize its priority so that it
gets executed before all other pending asyncs.
Note that we deliberately don't simply execute the async in the
calling thread in this case, to allow timed-waits to fail (which is
especially important for gimp_wait()).
(cherry picked from commit 62baffed98)
Fix indentation in gimp-parallel.{cc,h}.
Remove unused typedefs in gimp-parallel.h.
s/Gimp/Gegl/ in function-type cast in gimphistogram.c.
(cherry picked from commit 05a4437d9a)
The parallel_distribute() family of functions has been migrated to
GEGL. Remove the gimp_parallel_distribute() functions from
gimp-parallel, and replace all uses of these functions with the
corresponding gegl_parallel_distrubte() functions.
(cherry picked from commit 2736cee577)
Initialize the X/Y tilt fields of improted/pasted path control
points to 0, instead of 0.5, which is the normal value for these
fields in paths. This avoids calculating bogus distances when
trying to pick the path, causing picking to fail.
(cherry picked from commit 0a123a81a3)
Pass the GEGL tile-cache size, swap path, and thread-count to plug-
ins as part of their config, and have libgimp set the plug-in's
GeglConfig accordingly upon initialization.
Move swap/cache and temporary files out the GIMP user config dir:
libgimpbase: add gimp_cache_directory() and gimp_temp_directory()
which return the new default values inside XDG_CACHE_HOME and the
system temp directory. Like all directories from gimpenv.[ch] the
values can be overridden by environment variables. Improve API docs
for all functions returning directories.
Add new config file substitutions ${gimp_cache_dir} and
${gimp_temp_dir}.
Document all the new stuff in the gimp and gimprc manpages.
app: default "swap-path" and "temp-path" to the new config file
substitutions. On startup and config changes, make sure that the swap
and temp directories actually exist.
In the preferences dialog, add reset buttons to all file path pages.
(cherry picked from commit a29f73bd9a)
Commented out the inactive plug-ins registry: no point linking to a dead page.
Added links to the roadmap page, main wiki page, and the bug tracker. Placed
the link to the bug tracker one level up from '<Image>/Help/GIMP Online'
to make it more visible.
In the scale tool, when the "around center" option is toggled,
scale the item around its center not only through canvas
interaction, but also when entering width/height values through the
tool GUI.
(cherry picked from commit 786bfa5171)
Nothing said what was going to be the order of the page, except by
testing. Now there will be an explicit text, which will be automatically
updated when checking the "reverse order" box.
(cherry picked from commit afe1de950f)
When constructing CC_VERSION, escape backslash characters in the
compiler version string, so that they don't get interpreted as
escape sequences by the compiler. This is especially important on
Windows, where the version string of MinGW may contain backslash
characters as part of paths.
(cherry picked from commit c0b107531e)
In gimp_drawable_transform_buffer_affine(), avoid modifying the
clipping mode when transforming layer masks, since this function is
used (among other things) to transform layer masks together with
their layer, in which case they should use the same clipping mode
as the layer.
This fixes a regression introduced by commit
2ae823ba2b, causing layer masks to be
transformed with a mismatched clipping mode during layer
transforms, leading to discrepencies between the transformed layer
and the transformed mask.
This commit merely reverts the necessary part of above commit,
fixing the regression, though note that this code is really up for
some serious refactoring: the logic for determining which clipping
mode to use when is spread all over the place.
(cherry picked from commit 45fc30caa7)
... as I would like it to.
Use GimpSpinButton, added in the previous commit, in GimpSizeEntry,
instead of GtkSpinButton. This avoids updating the spin-buttons'
adjustment values when they lose focus, truncating the value if it
can't be accurately displayed using the corresponding spin-button's
digit count. Since size-entries can have multiple spin-buttons
using different units, this prevents the value from changing when
entring a value using one unit, and then shifting the focus to, but
not changing, another unit.
GimpSpinButton is a drop-in replacement for (and a subclass of)
GtkSpinButton. Unlike GtkSpinButton, it avoids updating the
adjustment value when losing focus, unless the entry text has
changed. This prevents accidental loss of precision, when the
adjustment value can't be accurately displayed in the entry.
Note that libgimpwidgets already defines a (deprecated)
gimp_spin_button_new() function. This commit stays compatible with
the old function, by defining GimpSpinButton's _new() function as
gimp_spin_button_new_(), and defining a variadic
gimp_spin_button_new() macro, which expands to either the old or
the new function, based on the number of arguments, so that either
function can be used transparently as gimp_spin_button_new(). This
is all gone in master.
... only shows the color (and nothing else) when "Convert bitmaps to
vector graphics where possible" was set.
This is because gimp_drawable_histogram() only checks selected pixels.
So let's make sure we work on a duplicate of the image so that we can
safely remove the selection before processing the export.
In all themes, fix the color of selected text, while editing a
tree-view's item text (such as when renaming a layer), by
overriding tree-view specific styling with the global text-entry
style, for nested text entries inside tree-views. The text would
previously use the same color as the selection background, making
it unreadable.
This issue affects the Dark and Gray themes, although this fix only
takes care of the Dark theme.
Add devel-docs/performance-logs/performance-logs.md, which
describes how to record and view performance logs, and how to
report perofrmance-related issues.
(cherry picked from commit fa9161e4f2)
Blacklist the "threaded-ml" thread, which seems to mask the
backtrace signal.
Improve signal-handler synchronozation, to avoid segfaulting when
giving up on waiting for all threads to handle the signal.
Furthermore, when one or more threads fail to handle the signal in
time, return a GimpBacktrace instance with backtraces for all the
other threads, and with empty backtraces for all the non-responding
threads, instead of returning NULL and leaking the allocated
instance. Don't blacklist threads that failed to handle the signal
in time, and instead shorten the wait period for handling the
signal, and yield execution during waiting to lower the CPU usage.
(cherry picked from commit a29d040db5)
In sample-search predicates, remove the "exclusive" parameter of
the "function()" function, and replace it with optional "id" and
"state" parameters, which limit the match to the call-stacks of
matching threads, as per the "thread()" function.
Sort the backtrace thread-list by thread ID.
(cherry picked from commit 0b2d41635a)
Fix delta-encoding of performance-log backtraces in certain cases,
and distinguish between empty call-stacks and removed threads.
(cherry picked from commit eec1e1f189)
Connect GimpImage's gimp:mask-components node to the layers node
*before* connecting the channels node, so that the image's
component mask doesn't affect the channel colors, as is the case in
2.8.
(cherry picked from commit 56920dcdbf)
In gimp_view_renderer_drawable_render(), make sure the preview size
is always at least 1x1.
Fixes commit 8009ea342a.
(cherry picked from commit 963322fdd4)
In the preformance-log viewer, show instrumentation-variable
descriptions as tooltips for the corresponding treeview rows.
(cherry picked from commit 21b36cd864)
Include instrumentation-variable descriptions in the var-defs
section of performance logs, so that they can be displayed
alongside their names when viewing the log.
(cherry picked from commit 646208eff0)
Simplify gimp_view_renderer_drawable_render(), by consolidating
common code paths. In particular, when rendering the preview as
part of an image, always crop the preview to the bounds of the
image, even when downscaling, to avoid unnecessarily downscaling/
convering cropped-out regions. We previously only did this when
upscaling the preview by a factor of 2 or more; whatever the reason
for this used to be, it's no longer there.
(cherry picked from commit 8009ea342a)
In gimp_view_renderer_drawable_render(), avoid overflow in preview-
area calculation. This prevents erroneously setting 'scaling_up'
to FALSE while upscaling the drawable by a very large amount, which
can lead to the creation of a very large GimpTempBuf for the
preview, causing memory allocation to fail.
(cherry picked from commit 0cdbe91e5a)
Add line data padding when necessary.
Additionally I realize we should convert to little-endian after checking
the bytesperline oddness (this bug was most likely unnoticed until now
as most desktop proc are little endian now anyway).
(cherry picked from commit 5d319b77bf)
file_save(): make sure we always set an error on failure
file_save_dialog_save_image(): additionally, check that "error" exists
before dereferencing it.
(cherry picked from commit c55f2308e1)
... the second time you do a 180 degrees rotation
In gimp_transform_resize_adjust(), nudge the transformed layer
boundary by EPSILON toward the center, to avoid enlarging the layer
unnecessarily, as a result of numeric error amplified by rounding,
when the tranformed boundary should land on integer coordinates.
In particular, this avoids enlarging the layer when rotating by 180
degrees.
(cherry picked from commit c271992aa0)
...via hover tooltips
Use the GtkWidget::query_tooltip() signal on GimpFgBgEditor to emit an
own signal "tooltip" that has the hovered widget area as parameter.
Connect to GimpFgBgEditor::tooltip() in gimptoolbox-color-area.c and
set separate tooltips on the widget's areas, including the shortcuts
for "Swap colors" and "Default colors".
(cherry picked from commit ae9d84dd22)
Use a single segment with a "step" blending function, added in the
previous commit, instead of two separate segments, for the "FG to
BG (Hardedge)" internal gradient. This makes it simpler to change
its endpoint colors by modifying the gradient, instead of changing
the FG/BG colors.
(cherry picked from commit 84066ca26a)
... to make multi-color hard-edge gradient fills possible
Add a new "step" gradient-segment blending function, which is 0
before the midpoint, and 1 at, and after, the midpoint. This
creates a hard-edge transition between the two adjacent color stops
at the midpoint. Creating such a transition was already possible,
but required duplicating the same color at the opposing ends of two
adjacent stops, which is cumbersome.
(cherry picked from commit 68bf99e806)
Add xyY color space to the color spaces for sampling colors.
Also add code to xcf-load.c that makes sure the sample point loading
code handles unknown future GimpColorPickMode values (fall back to
PIXEL pick mode).
(cherry picked from commit 298cc57042)
Add pattern offset parameters to gimp_fill_options_create_buffer() and
pass the selection's top-left corner so that pattern fills on the same
drawable are aligned.
(cherry picked from commit 38dcb73bfc)
In gimp_metadata_add_xmp_history(), make sure the string returned by
strftime() has a terminating \0 after we mess with its format.
(cherry picked from commit 8421221b60)
Seems we were drawing marching ants for hidden tabs ever since the
introduction of SWM, which is both a horrible waste of CPU time, and
also makes all selections visible on all displays on GTK+ 3.x.
Implement GtkWidget::unmap() in GimpDisplayShell and stop the ants
when the shell is unmapped.
(cherry picked from commit 1d43e2ff37)
In the performance-log viewer's profile view, allow sorting the
call-graph tree-views by function name, in addition to the
inclusive/exclusive frequencies.
(cherry picked from commit 4664fa73fb)
On macOS, the "drag-end" signal does not seem to be emitted in some
cases, which leaves dockables in an unsensitive state. Rather than
trying to fix GTK+2 which is half-maintained nowadays anyway, let's drop
the unsensitivity. As a comment notes, this was anyway only a visual
cue. Dragging dockables in GIMP 2.10 already shows a lot of other visual
cues, so this is redundant.
In case of drop failure, we also had to cleanup the icon widget and
detach the dockable. This can be handled by the "drag-failed" (which
hopefully work better on macOS).
As an additional improvement, I raise the newly created dockable window,
since this is the most likely behavior when you just detached a dock
(and I realize it usually appeared behind other GIMP windows, at least
on GNOME).
Note: this is a gimp-2-10 only fix as master relies on GtkNotebook DnD
code which (hopefully, as I haven't tested) doesn't have this issue. The
detached window behind other windows issue doesn't exist on master, at
the very least.
In the performance-log viewer's profile view, displasy in-line bar-
chart-like visualization of function and source-line sample
percentages, as part of the corresponding tree-view cells.
(cherry picked from commit 26ea334825)
Add missing fclose invocations and fix copy-paste issue.
This issues has been discovered by coverity scan proceeded by Red Hat.
Fixed some mistakes in the patch and added more fclose() (Mitch)
GTK/OSX does not automatically assign focus to the new windows (upstream
issue), so activateIgnoringOtherApps is called. However, if it is called
before gtk initialized it may cause number of focus issues.
In gimp_file_proc_view_get_proc(), when there is no selected
procedure (which can happen, in particular, when searching the
list), return the "automatic" procedure and its corresponding name/
filter, if one exists, instead of bailing.
Additionally, in GimpFileDialog, use a match-all filter when
gimp_file_proc_view_get_proc() returns no filter, avoiding
CRITICALs/segfault.
(cherry picked from commit e26a220a6f)
In GimpDeviceInfo, make sure that the info->axes and info->keys arrays
always have info->n_axes and info->n_keys members. Also sync axes and
keys between GdkDevice and GimpDeviceInfo more often, and some
cleanup.
(cherry picked from commit 7adb6c26e5)
In performance-log-viewer.py, fix thread-state toggling in the
profile-view thread-filter popover, when not all threads are
included in the current selection.
(cherry picked from commit 43b492ff83)
In the GimpBacktrace Linux backend, always use libunwind, when
available, to find symbol names, even if dladdr() or libbacktrace
had already found one. libunwind provides more descriptive names
in certain cases, and, in particular, full symbol names for C++
lambdas.
Note that, in some cases, this can result in a discrepancy between
the reported symbol name, and the corresponding source location.
(cherry picked from commit 72fc01742b)
In the GUI implementation of gimp_wait(), explicitly finish the
input-pipe async operation after the busy-dialog plug-in
terminates, to avoid the async callback function from being
repeatedly called, stalling the main thread. Previously, this code
relied on gimp-parallel implicitly aborting the async operation,
but this is no longer the case since commit
4969d75785.
(cherry picked from commit 85b16b9eaa)
Add a new performance-log-coalesce.py tool, which groups together
performance-log address-map entries belonging to the same function
into a single symbol, by filling-in missing base symbol addresses.
The addresses are grouped such that each set of addresses
corresponding to a symbol of the same name, in the same source
file, are given the same (unique, but arbitrary) base address.
See the previous commit for why this is necessary.
This should work fine in most cases, however, for logs produced on
Windows, it can over-coalesce addresses belonging to different C++
lambda-functions in the same source file, since they all seem to be
given the same _FUN symbol name.
Use the new tool as part of the pipeline in performance-log-viewer.
(cherry picked from commit cb51ea981a)
In the GimpBacktrace Windows backend, avoid reporting meaningless
symbol addresses when failing to retrieve meaningful ones.
Unfortunately, it seems that we never get symbol addresses for
symbols that have debug information, which negatively affects the
log viewer's call graph. We're going to have to work around this.
(cherry picked from commit 52772cf3ff)
When initializing the GimpBacktrace Windows backend, set the name
of the current thread (which is assumed to be the main thread) to
the program's name, to match its name on Linux. We normally rely
on the SET_THREAD_NAME exception to set thread names on Windows,
which isn't raised for the main thread.
(cherry picked from commit 52908f397f)
In the gimp_parallel_run_async() family of functions, allow the
async callback to return without completing the async operation, in
which case the callback will be called again, until the operation
is either completed, or canceled, in which case it is aborted
(previously, returning from the callback without completing the
operation would cause it to be aborted.) It is guaranteed that all
operations of the same priority will get a chance to run, even if
some of them contuinuosly return without completing.
This allows potentially time-consuming operations to yield
execution in favor of other same-priority operations, and, in
particular, of higher-priority operations, to avoid priority
inversion. Essentially, this allows a simple form of cooperative
multitasking among async operations.
(cherry picked from commit 4969d75785)
Replace GimpTransformTool's 'drawable' field with an 'item' field,
and have GimpTransformGridTool set it to the active item, to which
the transformation is applied, during its initialization. In
gimp_transform_tool_get_active_item(), return the value of the
transform tool's 'item' field, if not NULL, instead of the image's
active item. This makes sure we apply that transform-grid tools
apply the transformation for the item for which they were
activated, even if the image's active item has changed.
(cherry picked from commit 3eaae58595)
Apply the check/radio-button style to GtkTreeView, so that
GtkCellRendererToggle picks the right check/radio-button graphic.
Otherwise, it falls back to a graphic that depends on the system
theme, and which may not play well with the current theme colors.
Note that this only affects the Dark theme; in the Light and Gray
themes, one of the KDE-hack styles "takes care" of this, but this
commit applies the same change to these themes anyway.
When shutting-down gimp-parallel, cancel and/or abort any ongoing
and queued async operations, instead of finishing them (async
operations that already started executing will be canceled, but
execution will be blocked until they're finished.) This is
especially important since we're shutting down gimp-parallel before
the destruction of data factories. This commit causes any ongoing
async operations of the factories to be canceled on shutdown,
rather than waiting for them to finish normally.
(cherry picked from commit e46fdc714e)
Add a new GimpData::data_cancel() virtual function, and a
corresponding gimp_data_factory_data_cancel() function. This
function should cancel any ongoing async operations related to the
factory (i.e., included in its async set), and wait for the
operations to finish. Provide a default implementation that simply
cancels and waits on the factory's async set.
Use this function to cancel any ongoing operations during factory
destruction, and in gimp_data_factory_data_free().
Override this function in GimpFontFactory, for which we can't
really cancel font loading, and simply cancel and clear the
factory's async set without waiting for loading to finish, making
sure that nothing happens (and, in particular, that the factory
isn't being accessed, since it might be already dead) when loading
does finish.
(cherry picked from commit 6bc0b3b8ad)
In gimp_data_factory_data_foreach(), don't rely on internal
GimpData objects being sorted first (while this is currently true
for all types of GimpData, they may override the sort order.)
(cherry picked from commit 50bab438ce)
Add an annotated source view to the performance-log viewer's
profile view. When selecting the [Self] entry of a function's
profile, for which source information is available and whose source
is found locally, a new column opens, showing the function's
source, annotated with sample statistics. Header-bar buttons allow
navigation through the annotated lines, selection of all the
samples corresponding to a given line, and opening the text editor
at the current line.
(cherry picked from commit 88438c5055)
... when selecting a function's samples
Since we now preserve the call-graph path across state changes,
there's no need to explictly set the path after selecting a
function's samples in the profile view.
(cherry picked from commit b672f20075)
... in backtraces
In the performance-log viewer's backtrace viewer, show a document
icon next to stack frames with source-location information, whose
source file is found locally. Clicking the icon opens the source
file in a text editor at the relevant line.
Two environment variables control this feature:
- PERFORMANCE_LOG_VIEWER_PATH is a list of colon-separated
directories in which to look for source files. If this
variable is undefined, the current directory is used.
- PERFORMANCE_LOG_VIEWER_EDITOR is the command to use to launch
the text editor, for editing a specific file at a specific
line. The special strings "{file}" and "{line}" are replaced
with the filename and line-number, respectively. If this
variable is undefined, "xdg-open {file}" is used.
(cherry picked from commit 0f38709259)
Don't take infinite values into account when calculating the
vertical scale of sample graphs, and rather display infinite values
as dashed lines at the top of the graph.
(cherry picked from commit 46e5e4d478)
When re-activating an operation tool by clicking on a different
drawable while the tool is active, we re-call the corresponding
procedure to re-activate the tool, which implictly initializes it.
Avoid initializaing it explicitly in addition to that, since this
leads to the creation of a new config object by the filter tool,
while the GUI still refers to the old, now-dead, config object,
causing CRITICALs or segfaults when changing any parameter.
(cherry picked from commit a21667821c)
In the warp tool, don't commit a trivial (empty) transform. This
is especially important now that exiting the tool through undo
causes it to get comitted (... with a trivial transform).
(cherry picked from commit d12dd3fb35)
... changing layers and warping layer B
Add a new GimpToolControl::dirty_action field, which specifies the
tool action to perform when the a dirty event matching the tool
control's dirty mask occurs; this field defaults to HALT. Apply
this action to the active tool in tool-manager in response to a
matching dirty event, instead of unconditionally halting the tool.
Likewise, use this action to stop the active tool in response to a
button-press event on a different drawable in the same image.
Set the dirty action of the gradient and warp tools to COMMIT, so
that they get comitted, rather than stopped, in cases such as
switching layers (including switching to/from quick-mask mode),
and, for the warp tool, changing the selection.
(cherry picked from commit ed20393f0e)
In gimp_drawable_real_{apply,replace}_buffer(), bail if the
applcation region, after intersection with the drawable and mask
extents, is empty. This avoids trying to create a GeglBuffer with
negative width/height.
(cherry picked from commit ae3c006293)
... (some sort of corruption)
In gimp_drawable_real_replace_buffer(), adjust the processed buffer
and mask_buffer regions according to the changes made to the
application region, as calculated by intersecting it with the
drawable and mask extents. This fixes wrong application position
when painting using the heal, dodge/burn, smudge, or convolve
tools, on a drawable whose origin is above/to the left of the
image's origin, and there's a selection active.
(cherry picked from commit a782acab57)
... the XCF file
Add a "saving" signal to GimpImage, which is emitted when the image
is about to be saved or exported (but before it's actually saved/
exported). Connect to this signal in tool-manager, and commit the
current tool in response (unless its GimpToolControl::preserve is
TRUE).
(cherry picked from commit ae628a8664)
Add undo functionality to the performance-log viewer, which allows
undoing/redoing changes to the sample selection, and the call-graph
state.
(cherry picked from commit 6ad3dbdb17)
Please everyone, feel free to update the list of upcoming
changes/features, if you feel some particular change should be more
prominently exposed in this list (or at the opposite that some change is
not worth mentionning), or for rewording, etc.
(cherry picked from commit ba53a833b2)
We currently construct the tool-options GUI for all the tools at
startup, which takes a significant amount of time. Instead,
only register the GUI construction function with the tool-options
object, using the new gimp_tools_set_tool_options_gui_func()
function, and use the registered function to construct the GUI when
actually needed.
(cherry picked from commit c1347a7f26)
Fix int-ratio variable formatting when the input is NaN, which can
happen when calculating the standard deviation, if all the values
are infinite.
Fix keyboard sample-range selection.
Deselect all samples when right-clicking a sample graph.
(cherry picked from commit d33fb0e7b8)
script-fu used to query the information of every PDB procedure on
startup, in order to get the number of parameters for each
procedure. This was done so that nullary procedures were defined
in such a way as to accept (and ignore) any number of arguments
(and at least one of the scripts we ship relies on this behavior).
However, this requires expensive back-and-forth communication with
the main GIMP process, which notable slowed down script-fu's
startup, and had a non-negligible impact on GIMP's startup time.
Instead, avoid querying procedure information, and implement the
special behavior for nullary procedures at call time. We do this
by defining, in addition to the "strict" gimp-proc-db-call
procedure, a "permissive" -gimp-proc-db-call internal procedure,
and using the latter to call the predefined PDB procedures.
(cherry picked from commit 9a2999a553)
... after erasing all points
When erasing the last remaining point in the iscissors tool, halt
the tool, rather than leaving the tool active with an empty curve,
which it is not prepared to handle, and which results in a segfault
once trying to add a new point.
Additionally, when erasing the last remaining segment (i.e., the
two last remaining points), don't erase the entire segment (i.e.,
both points), but rather convert the segment to its initial point,
so that, in effect, we only erase the last point of the segment.
(cherry picked from commit a5baba5539)
In GimpTransformTools, precalculate the resulting size of the
transformed item(s), and request confirmation if the size grows to
over 10 times the size of the image (in either dimension). This
protects against transformations that can result in suprprisingly
large items, such as inverted transformations, and, specifically,
perspective-correction transformations performed using the measure
tool, which will be added in the following commits.
(cherry picked from commit 20a6a3583b)
When removing the focus widget of a GimpToolWidgetGroup, use the
last child, rather than the first child, as the new focus widget.
This plays nicer with auto-raise, and is probably better anyway.
(cherry picked from commit 24fb597196)
When a focused widget is added to a group, make it the new focus-
widget of the group, instead of unsetting its focus if another
widget already has focus.
When removing the focused widget from a group, set a different
widget as the group's focus widget (if one exists), instead of
unsetting the focus widget, so that nonempty groups always have a
focus widget.
(cherry picked from commit 95d2c92ff2)
In gimp_tool_widget_group_button_press(), explicitly call
gimp_tool_widget_group_hover() before forwarding the event to the
group's hover widget, so that the hover widget gets recalculated.
If a widget is added to the group as a result of a button-press
event, this guarantees that it gets considered as a target for the
same event.
(cherry picked from commit 5b217b3ad4)
In the performance-log viewer, add an option to filter which
threads, and which states of each thread, are included in the
profile. By default, all threads in the RUNNING state are
included.
(cherry picked from commit 3f630378b0)
In the performance-log viewer, defer updates to the various UI
elements when the selection changes until they're actually shown.
This improves responsiveness when changing the selection.
(cherry picked from commit a7afbe13ec)
When libbacktrace is available, use it to retrieve source location
information in the Linux GimpBacktrace backend.
(cherry picked from commit 7cdd1ebeef)
Use the less-ambiguous, if just as clumsy,
"format-indent-more/less" icons, to stand for the
caller -> callee, and callee -> caller, directions, respectively.
(cherry picked from commit c7a4eb4602)
Commit 6484e91f82 broke the arrow
color of menu items with a submenu in the Dark theme; it seems to
have always been broken in the Light and Gray themes.
Fix this, by applying the default style to the GtkMenuItem class.
Fix searching for samples by thread name, in particular, when there
are unnamed threads.
Use GtkMenuButton, instead of GtkButton, for the find-samples
header button.
Add mnemonics to the find-samples popover.
(cherry picked from commit c537341d35)
... provided by RawTherapee's installer (version 5.5+).
See https://github.com/Beep6581/RawTherapee/issues/4783.
This patch required a small change to file_raw_get_executable_path
because the RawTherapee installer is supposed to work without admin
privileges and therefore can't write to HKLM.
Reviewer's note (Jehan): RawTherapee's installer does not add the
registry entry yet. We assume the upstream bug report will end up doing
so (someone has to make the first step!). :-)
(cherry picked from commit 829ca6583d)
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
In gimp_paint_core_loops_process(), initialize the iterator with
sufficient room for the number of iterators used by the algorithm
hierarchy, instead of a fixed number.
Add an additional 'rect' parameter to the init_step() and
process_rows() algorithm member functions, which receives the area
of the currently-processed chunk, to be used instead of the
iterator's ROI member. This allows us to pass a NULL iterator to
hierarchies that don't use an iterator, and avoid the stack-
allocated iterator hack we used in this case (and which became even
more problematic with the new iterator API).
(cherry picked from commit 6c6a7514a4)
... for applying the global style.
Last commit *might* have fixed the need to use "*" instead of
"GtkWidget", although it's hard to tell -- nothing seems to be
obviously wrong, anyway. Let's just try restoring this, and see if
anything breaks.
In the gtkrc files of the Dark and Light themes, replace a bunch of
"widget" selectors with "widget_class" selectors, which is what
they really should be (they should probably also use angle-bracket
notation for classes, but as long as it works...) This allows the
different styles to be merged correctly, and fixes the active layer
name color (more generally, the text color of selected rows of
focused tree-views inside dockables.) The Gray theme seems to be
double-broken in such a way that "fixing" it causes it to do the
"wrong" thing... I'm not touching that :)
My previous commit answers the forever question "do we want to require
this?" which was in comments and can now be removed.
We don't need to actually require this operation for running GIMP, as it
runs fine without. Just testing in configure is enough of a warning for
the missing feature.
(cherry picked from commit 97247f41ea)
This is a runtime dependency. If absent, we simply won't have access to
the alternative Matting Levin engine in the foreground selection tool.
If we don't add a test in configure, this may be easily forgotten. I
created the `gegl --exists` feature specifically for this kind of
checks, so let's check operation existence.
(cherry picked from commit 9560a653c5)
After Dirk Farin had another look in the specs, it turns out that "mif1"
is actually allowed as major brand for HEIF. Also adding "msf1" which is
the equivalent for image sequences.
(cherry picked from commit 64b00b5c7f)
Just looking for "ftyp" would also match other ISOBMFF files (.mov or
.mp4 files for instance). These are the possible 4-byte "brand" code
which can follow "ftyp", as listed by Dirk Farin from libheif.
I add the "mif1" brand, as I encountered some files using this magic
(even though this should normally not be valid apparently, yet the file
loaded fine in GIMP).
This is not perfect as the standard allows potentially very big box
headers, in which case 8 bytes (the "largesize" slot) may be inserted
between "ftyp" and the brand, as I understand it. But this is actually
unlikely enough to probably never happen (the compatible brands list
would have to be huuuge, as it looks like this is the only extendable
part in a ftyp box). So let's assume this just never happens.
See also: https://github.com/strukturag/libheif/issues/83
(cherry picked from commit 4ad3993eca)
Nicknames on IRC/gitlab are hard, even more when they change depending
on the media! I realize we are regularly asking them or unsure of who to
contact (for instance here for releases). Let's associate each package
with its current maintainer to make it easy to contact the right person
to prepare our official packages before a release.
(cherry picked from commit dc9a30446b)
Adding a magic number for HEIC/HEIF, which would allow to discard
obvious non-HEIC images even with the wrong extension.
Note: it looks like this magic number would also match more generically
other ISO base media file format (ISOBMFF) formats, like .mov or .mp4
files. I am enquiring for better magic but for now, this is better than
nothing.
(cherry picked from commit d738d2f645)
performance-log-viewer.py is a viewer for GIMP performance logs.
The viewer is made up of two parts: a sample-selection area at the
top, and an information area at the bottom.
The sample-selection area visualizes the sampled variables and
markers using a simultaneous set of plots, and displays the
currently selected samples. Samples can be selected directly
through the sample-selection area, or by other means, such as
searching for all samples satisfying a certain condition, or
containing a certain function.
The information area shows global information stored in the log, as
well as information specific to the currently selected samples,
including variable listing and statistics, full backtrace, and
profile/call-graph information.
Note that performance-log-viewer.py takes its input from STDIN,
like the rest of the performance-log tools, and is therefore
suitable for use as part of a pipeline. For standalone use, the
performance-log-viewer driver is also included, which takes the log
file as a command-line argument, and processes it through an
appropriate pipeline before feeding it to the viewer.
(cherry picked from commit 3601c9189b)
... which statistically deduces the correct thread states based on
backtrace address frequency, fixing local inaccuracies.
(cherry picked from commit 7e186f3e5d)
In addition to the verbose GIMP version, include in performance
logs the values of all environment variables beginning with BABL_,
GEGL_, or GIMP_, and of all the GEGL config options.
(cherry picked from commit 2c6b5c371e)
* The minimum GIMP version for this XCF is always written down when it
is GIMP 2.8 or over.
* The list of features warrating the minimum version is now listed in an
expander container rather than as tooltip (making the list actually
discoverable!).
* The warning on compression is now displayed as its own text under the
checkbox (only when checking the box actually changes anything
compatibility-wise), and not as additional text to the minimum GIMP
version label. Otherwise it had far too much weight on the minimum
compatible GIMP version text and people were wondering what it meant.
We should not tell people what the checkbox cannot do (it cannot
improve compatibility in some cases), only what it can do (it can
improve compatibility in other cases).
* Update the feature list real-time when checking the compression box
(making it even more obvious that tile compression may have a say in
compatibility).
* Metadata info is still added on the GIMP version label as it does not
limit compatibility of the XCF file itself.
(cherry picked from commit 573d817539)
Even though chosen as a parameter to gimp_image_get_xcf_version() and
not a feature within the image itself, we also want to list this reason
in the compatibility list.
(cherry picked from commit 0fa2ef9118)
When moving a text layer using the text tool (through alt+drag),
don't change the layer's box mode to "fixed", which is unnecessary,
since the layer's size isn't affected.
(cherry picked from commit 601c213c7a)
While editing a text layer with the text tool, update the layer's
frame when the layer moves, which most notably happens when
undoing/redoing a move operation while the text tool is active.
(cherry picked from commit 238c1035db)
The various functions of the text tool currently block and unblock
drawing (through gimp_text_tool_[un]block_drawing()) implicitly,
and in a non-symmetric fashion, which makes the tool's logic rather
fragile. Instead, require blocking/unblocking to be done
symmetrically, and explicitly block/unblock drawing as necessary in
all functions.
(cherry picked from commit a03183b266)
Improve out-of-range check in gimp_backtrace_find_thread_by_id().
Remove unnecessary #include <exchndl.h> in gimpbacktrace-windows.c,
and revert commit 644234e99d (the
DrMingw detection happens at runtime). The Windows backend can
work without DrMingw, it just can't find all the symbols, and
doesn't provide source-location information.
(cherry picked from commit b9f1ab8f53)
The "running" attribute (readable through
gimp_backtrace_is_thread_running(), and recorded in the performance
log) specifies if the thread was in a running or suspended state at
the time the backtrace was taken. It is accurate on Linux, but
only approximated on Windows.
Adapt the performance-log-expand.py tool to maintain this attribute
(and any future thread attributes we might add).
(cherry picked from commit 78adb7c900)
The Windows backend produces full, multithreaded backtraces. When
DrMingw is available, it also provides full symbol and (where
available) source-location information. Otherwise, it provides
symbol information for most of our libraries, but not for the GIMP
binary itself.
(cherry picked from commit 667efc221d)
Add source filename and line number fields to the
GimpBacktraceAddressInfo struct, populated through
gimp_backtrace_get_address_info(). This is not currently supported
by the Linux backend, but is supported by the Windows backend,
which we'll be added in the next commit.
(cherry picked from commit a6ec857123)
This function returns information about the given address, which
is currently mostly limited to the corresponding symbol
information, but we might want to add address-specific information
in the future, such as a line number.
(cherry picked from commit 7ac87dc01e)
In all the selection tools, show an error (and a BAD cursor
modifier) wheh starting a selection, if the current selection is
empty, and the tool is in SUBTRACT or INTERSECT mode (in which
case, the selection has no effect).
(cherry picked from commit 0e26525e65)
We're currently only using GimpHighlightableButton in the layers
dialog, which defines its own set of highlight colors. We're going
to use highlightable buttons in the dashboard too, so let's move
the highlight colors to gimphighlightablebutton.h, and give them
standard names. We currently define
GIMP_HIGHLIGHTABLE_BUTTON_COLOR_AFFIRMATIVE (green), and
GIMP_HIGHLIGHTABLE_BUTTON_COLOR_NEGATIVE (red).
(This commit was accidentally dropped from the gimp-2-10 branch; it
should have gone before 40ac4f7bc0f43aee24dc7ae1cf674d1a59612f55.)
performance-log-expand.py decodes a delta-encoded performance log
by expanding the deltas, producing a log where each sample (and
other relevant elements) contain complete information. Note that
the structure of expanded logs is identical to that of delta-
encoded logs, the expanded log simply has no deltas.
performance-log-resolve.py resolves symbol information in
backtraces. The logs produced by GIMP only specify the program
counter at each stack frame, providing an address-map to map
program-counter addresses to actual symbols separately. This tool
looks up each program-counter address in the address map,
incorporating the relevant symbol information directly into the
backtrace.
Both tools read their input from STDIN, and write their output to
STDOUT, and can be chained in a pipeline (with
gimp-performance-log-expand.py appearing first).
Note that these tools require Python 3.
(cherry picked from commit d7c74a615b)
Add an option to record a performance log through the dashboard.
The log contains a series of samples of the dashboard variables, as
well as the full program backtrace, when available. As such, it
essentially acts as a built-in profiler, which allows us to
correlate program execution with the information available through
the dashboard. It is meant to be used for creating logs to
accompany perofrmance-related bug reports, as well as for profiling
GIMP during development.
The sample frequency defaults to 10 samples per second, but can be
overridden using the GIMP_PERFORMANCE_LOG_SAMPLE_FREQUENCY
environment variable. Backtraces are included by default when
available, but can be suppressed using the
GIMP_PERFORMANCE_LOG_NO_BACKTRACE environment variable.
Logs are created through the new "record" button at the bottom of
the dashboard dialog. When pressed, a file dialog is opened to
select the log file, and, once confirmed, data is being recorded to
the selected file. Recording is stopped by pressing the "record"
button again (we use a highlight to indicate that recording is
active.)
While recording, the "reset" button is replaced with an "add marker"
button, which can be used to add event markers to the log. These
can be used to mark events of interest, such as "started painting"
and "stopped painting", which then appear in the log as part of the
sample stream. Markers are numbered sequentually, and the number
of the next (to-be-added) marker appears on the button. Shift-
clicking the button adds an empty (description-less) marker, which
is only identified by its number; this can be used when markers
need to be added quickly.
The log is an XML file, containing some extra information (such as
the output of "$ gimp -v", and symbol information) in addition to
the samples. The data in the file is delta-encoded to reduce the
file size, meaning that samples (as well as some other elements)
only specify the changes since the previous sample. This adds a
necessary decoding step before data can be processed; the next
commit adds a tool that does that.
There are currently no tools to actually analyze the data -- that's
still TBD -- but at least we can start gathering it.
GimpBacktrace provides an interface for creating and traversing
multi-threaded backtraces, as well as querying symbol information.
While we already have some backtrace functionality, it relies on
external tools for the most part, and as such is rather expensive,
and is only meant for producing opaque backtraces. GimpBacktrace,
on the other hand, is meant to be relatively cheap (we're going to
use it for profiling,) and allow inspection of the backtrace data.
In the future, it might make sense to replace some, or all, of the
other backtrace functions with GimpBacktrace.
GimpBacktrace currently only supports Linux. By default, it uses
dladdr() to query symbol information, which is somewhat limited (in
particular, it doesn't work for static functions.) When libunwind
is installed, GimpBacktrace uses it to get more complete symbol
information. libunwind is currently an optional dependency, but it
might make sense to promote it to a mandatory, or opt-out,
dependency, as it's lightweight and widely available.
On other platforms, the GimpBacktrace interface can still be used,
but it always returns NULL backtraces.
(cherry picked from commit 80bf686c94)
Move the call to gimp_filter_tool_disable_color_picking() from the
filter-tool's dialog "unmap" handler to gimp_filter_tool_halt().
Since commit ec80a88513, we
explicitly destroy the GUI when halting the filter tool, which
happens before the dialog's unmap handler is called, which could
potentially result in a dangling pointer to the active color-picker
widget in gimp_filter_tool_disable_color_picking().
(cherry picked from commit 072d6b0d12)
... 100% position anymore
In GimpGuideTool, use a closed [0, max_position] range as the
allowable range for new/repositioned guides (where max_position is
either the image's width or height), so that guides can be placed
at the right/bottom edge of the image.
(cherry picked from commit 547190faa8)
In gimp_image_merge_layers(), explicitly fetch the graph of the top
layer's parent layer (if exists), to make sure that the top layer's
graph has a parent node. We already fetch the image graph, which
takes care of top-level layers, however, if the top layer is a
child of an invisible layer group, as is the case in the wavelet-
decompose plug-in, this is not generally enough to guarantee that
the group's graph is constructed.
(cherry picked from commit e563845174)
In gimp_filter_tool_halt(), explicitly clear the GUI container
before clearing filter_tool->config, since the tool might be halted
during the GUI dialog's delete event, in which case the GUI will
only be implicitly destroyed *after* the function returns. The
destruction of the GUI might fire signals whose handlers rely on
filter_tool->config, so we need to make sure it happens while it's
still alive.
In particular, this fixes a CRITICAL in the threshold tool, which
occurs due to the histogram view's "range-changhed" signal being
fired during its destruction, and its handler accessing
filter_tool->config.
(cherry picked from commit ec80a88513)
gimp_device_info_set_device(): don't just bail out if a device with
the same name is added again, instead, simply continue and overwrite
the info's old device with the new one.
NOTE that this only happens if something is wrong on the USB or udev
or libinput or whatever side and the same device is present multiple
times. The only "safe" thing is to assume that devices listed earlier
are dead and dangling entities and that the last registered device is
the one actually delivering events.
(cherry picked from commit 717c183a3e)
In GimpProjection, use an adaptive chunk size when rendering the
projection asynchronously, rather than using a fixed chunk size.
The chunk size is determined according to the number of pixels
processed during the last frame, and the time it took to process
them, aiming for some target frame-rate (currently, 15 FPS). In
other words, the chunks become bigger when processing is fast, and
smaller when processing is slow. We're currently aiming for
generally-square chunks, whose sides are powers of 2, within a
predefined range.
Note that the chunk size represents a trade off between throughput
and responsiveness: bigger chunks result in better throughput,
since each individual chunk incurs an overhead, in particular when
rendering area filters or multithreaded ops, while smaller chunks
result in better responsiveness, since the time each chunk
individual takes to render is smaller, allowing us to more
accurately meet the target frame rate. With this commit, we aim to
find a good compromise dynamically, rather than statically.
The use of adaptive chunk sizes can be disabled by defining the
environment variable GIMP_NO_ADAPTIVE_CHUNK_SIZE, in which case we
use a fixed chunk size, as before.
(cherry picked from commit a1706bbd29)
Add a boolean "chunk" parameter to
gimp_projection_chunk_render_iteration(), which determines whether
the work area should be sub-divided into chunks prior to rendering
(previously, the work area would always be sub-divided.) Only
pass TRUE when rendering the projection asynchronously, in the
render callback, and pass FALSE when rendering the projection
synchronously, in gimp_projection_finish_draw(), which is called
when flushing the projection through the GimpPickable interface.
Rendering the projection using as big chunks as possible improves
performance, while worsening responsiveness. Since responsiveness
doesn't matter when rendering synchronously, there's no reason to
render in chunks.
(cherry picked from commit 105ffc787d)
In gimp_transform_tool_transform(), use "active_item", instead of
"tool->drawable", when cutting/pasting the selected portion of a
layer for transformation. The latter is a remnant of the old
transform-tool code, and is not guaranteed to be correspond to the
correct drawable, or even to a valid drawable (i.e., it can
potentially produce wrong results, or segfault.)
(cherry picked from commit 9420805525)
In the command handler of GimpTileBackendPlugin, forward unhandled
commands to gegl_tile_backend_command(), instead of asserting that
they're within range (which has already been disabled by commit
bc3b076caf). See GEGL commit
30047e65723ebb44fcde9c6b5f60ceecb43b0895.
(cherry picked from commit 668fee966a)
... which reports the amount of data queued for writing to the
swap (see GEGL commit 64021786ee067cf66c038622719acc590e6341db.)
When the swap queue is full, a yellow color underlay is shown in
the history graph.
(cherry picked from commit cd54457d46)
The "compression" field reports the ratio between the total size of
the data in the swap, and the total size the data would have had if
all tiles in the swap occupied a unique data block.
See GEGL commit 185f4450f2a51690b39112973c61f894c1ec3e41.
(cherry picked from commit b6e552a74b)
In gimp_tile_backend_plugin_command(), disable the range check for
the input tile command. This check prevents us from adding new
tile commands to GEGL without breaking the ABI; yet, the next GEGL
release will add a new command. We're going to have to decide what
to do about this, but for now, let's just disable the check, so
that at least GIMP 2.10.6 is compatible with newer versions of
GEGL, no matter how we end up handling this.
Do not set the interpreter to `python2` but to whatever was found by the
AM_PATH_PYTHON2() m4 macro.
It looks like the Python2 binary we ship in our DMG may be call "python"
only (without the '2'). Let's just make our code more resilient to
various builds.
I am not sure yet this is the only/actual problem for this issue on
macOS, but this is at least in the right way.
If I override the `program` variable, and it is not found in PATH
environment, then it is NULL and the error message is unhelpful. Make
the return value of g_find_program_in_path() into a separate variable
instead, and only override `program` in the end, when we know it is
non-NULL.
The python path with directory are generated files and should not be in
the dist. The previous commit was fixing an in-tree `make check` but
this one fixes the `make distcheck` as the dist was packaging the wrong
python files.
This issue was invisible when making VPATH builds, but appeared only in
source-tree builds as gettext tools are apparently mixing source and
build files. So we need to add these in the POTFILES.skip.
It seems I forgot to also install python plug-ins in a subdirectory
(because they are deactivated on master for the time being). I even
found a year-old patch from myself rotting in the tracker, and which was
doing exactly this.
I redid it, improved to fit changes.
(cherry picked from commit dbb9555d2f)
I am going to forbid plug-ins from being installed directly in the root
of the plug-ins/ directory. They will have to be installed in a
subdirectory named the same as the entry point binary.
This may seem useless for our core plug-ins which are nearly all
self-contained in single binaries, but this is actually a necessary
restriction to eliminate totally the DLL hell issue on Windows. Moving
core plug-ins in subfolders is only a necessary consequence for it.
(cherry picked from commit 870ca6334d)
... Windows installation of GIMP.
Our default installer installs 32-bit version of the various DLLs in
32/bin/ (under the installation prefix). Currently this additional
folder is simply added in the PATH, so it works most of the time.
Unfortunately the PATH is searched last for DLLs, and in particular, it
is searched after system directories. So it means that if any misbehaved
application is installing DLLs in system dirs (and in particular
incompatible/older versions of the same DLLs a GIMP plug-in uses), it
breaks the 32-bit plug-in.
SetDllDirectoryW() bypasses this order and the set folder is searched in
between the binary directory and the system dirs. We were already
setting this for our main bin/ directory, which was good for 64-bit
plug-ins, but this was not protecting 32-bit plug-ins. Now our code to
run plug-ins check the bitness of the executable before running it, and
updates the DLL folder accordingly.
The alternative 32-bit folder can be overridden by the configure option
--with-win32-32bit-dll-folder (default: 32/bin/). This option can only
be set when building for 64-bit Windows obviously.
Alternatively we could have put copies of 32-bit DLLs in a subfolder
with each 32-bit plug-in, but this is at best a terrible workaround, as
we would duplicate DLLs for every such case. And this would not have
protected third-party plug-ins which wish to use some of our DLLs.
Last alternative is to use AddDllDirectory(), but it works since Windows
7 with a given update only. And our current official support is any
Windows since Windows 7. So we don't want to use this right now (also
I'm not sure it would actually be much better than current
implementation, and it seems to have a bit more limitations than
SetDllDirectoryW(), though I have not tested).
This will go with the next commit, but I broke it so I can backport the
code without extension handling in gimp-2-10 first.
(cherry picked from commit c7b5977637)
Debugging stable versions under Windows is a pain because we don't have
access to the standard outputs. The debug console is indeed only built
on unstable builds. Let's make the debug console a separate build option
to allow building stable versions for debug (obviously the default
behavior when not configuring, is same as before, i.e. stable without
console and unstable with console).
When cross-compiling, I got various linking errors for printf() calls:
> undefined reference to `libintl_printf'
I am unsure why, since this is not recent code, and it used to build
fine with mingw64 compilers (last I cross-built, which is many months
ago). Anyway g_printf() works fine, all necessary libs are already
linked, and it is supposed to be a synonym. So let's just go the easy
way and use g_printf() only.
AM_PATH_GLIB_2_0 m4 macro actually computes this value using
$PKG_CONFIG. Yet $PKG_CONFIG variable is the pkg-config tool looking for
target libraries (not host), hence it would return the executable
`glib-compile-resources` built for the target.
Also using the same variable name invalidates our test: our own
AC_PATH_PROG was never run as the variable was already set. And no
environment variable could override this test anymore either. This is
why I rename the test variable to HOST_GLIB_COMPILE_RESOURCES.
Though no error was raised during a native build, a cross-build was
choking on this missing link to libgimpbase and failing.
The error returned by the linker though was a bit amiss.
Fixes:
> gimp-test-clipboard.o: In function `test_clipboard_copy_callback':
> tools/gimp-test-clipboard.c:419: undefined reference to `g_file_get_contents'
> collect2: error: ld returned 1 exit status
It seems that calling `lldb` when it is absent triggers some popup
proposing to install Xcode on macOS. This is obviously not good. Let's
check presence with g_find_program_in_path() instead. I was refraining
from doing so until now, because this function allocates memory, hence
may not do well during a crash.
Fortunately we don't need to check for lldb during crash (unlike gdb
which has some unacceptable behavior for older versions, at least on
FreeBSD) so that should be ok.
(cherry picked from commit 04bbe941d5)
Removing unused declaration of icons_set_icon_theme().
And reorder a bit the declarations to match the definition order.
(cherry picked from commit ae19441ddc)
In gimp_group_layer_update_size(), never suspend drawable updates
(and, in fact, remove the option to suspend drawable updates
entirely,) and instead never update the drawable during the call to
gimp_drawable_set_buffer_full(), and flush the group's projection
*after* setting the drawable's buffer, so that any pending updates
will happen after the group's buffer and size are up-to-date.
This fixes some missed drawable updates.
(cherry picked from commit fc2c640ca2)
In GimpProjection, change gimp_projection_add_update_area() to take
coordinates in the projection's coordinate system, rather than the
image coordinate system, and move the offset adjustment to the
projectable invalidation handler.
Modify gimp_projection_projectable_structure_changed() to pass
projection-space coordinates to gimp_projection_add_update_area().
gimp_projection_get_buffer() and
gimp_projection_projectable_bounds_changed() already pass
projection-space coordinates to gimp_projection_add_update_area(),
which was wrong before, when the projection had a nontrivial
offset, but is correct now.
(cherry picked from commit 2d63bc6e0a)
Fixed by implementing Massimo's two findings:
gimp_operation_cage_transform_process(): if aux_buf is NULL, bail out
after initializing out_buf with identity vectors, fixes the crash.
gimp_cage_tool_create_filter(): set the drawable filter's region to
GIMP_FILTER_REGION_DRAWABLE, fixes offset when there is a selection.
(cherry picked from commit 49dfc6143d)
In GimpCanvasTransformPreview, add the necessary bits to the
preview graph so that, when transforming a layer, the layer's
opacity and mask are correctly applied to the preview. Note that
since we're still not rendering the preview as part of the image
graph, the output is not always accurate, but it should be good
enough in most cases.
(cherry picked from commit 2ac91e0fc3)
Ok my previous fix was wrong (at least for the part in the macro). This
is a macro, not a function. So each time we write _reason, the call to
g_strdup_printf() is reevaluated, hence data is allocated.
The right fix is to prepend `tmp` to the list, not `_reason`.
Thanks to Massimo for the debugging, as always!
(cherry picked from commit 2912fe7c17)
ADD_REASON macro was leaking the allocated string when version_reason
return value was NULL (i.e. when we didn't care about the version
reasons).
Also we were not properly freeing all the reason strings at the end,
only the list. Use g_list_free_full() instead of g_list_free().
(cherry picked from commit 0ab682b0f5)
In gimp_projection_projectable_bounds_changed(), bail early by
calling gimp_projection_projectable_structure_changed() instead, if
the new bounds don't intersect the old bounds.
(cherry picked from commit c6b8a4213c)
In gimp_projection_projectable_bounds_changed(), which is called by
GimpProjection in response to a GimpProjectable::bounds-changed
signal, invalidate all regions of the new projection that weren't
copied from the old projection, so that they get rendered upon
flushing, instead of remaining empty.
Additionally, fix preview invalidation -- in particular, don't
directly invalidate the projectable's preview, even if preview
invalidation is already queued and chunk rendering was finished by
the boundary change, and instead always queue a preview
invalidation.
(cherry picked from commit bb5e3fd926)
Make sure we don't unnecessarily update the group layer's drawable
while flusing the group's projection during resizing, since we want
to either update the entire drawable, or avoid any updates, when
replacing the drawable's buffer. Note that explicitly supressing
updates in this case should theoretically not be necessary, but the
fact that the call to gimp_projectable_bounds_changed() can result
in reconstructing the projection (see the FIXME comment in that
function) makes it necessary in some cases nonetheless.
(cherry picked from commit bd726c96bf)
When translating group layers, there's no need to re-render the
group's projection -- we can simply update the group's offset (and
offset node) directly, and redirect any layer-stack "update"
signals to the group's drawable. This significantly improves
performance when moving groups.
(cherry picked from commit 3ff820a00a)
In GimpGroupLayer, use gimp_projectable_bounds_changed() when
updating the group layer's size, instead of reconstructing the
projection, unless reallocation of the projection has been
requested. This is more efficient, since it simply copies the
content of the projection's old buffer to the new buffer, rather
than re-rendering the graph.
(cherry picked from commit 1bb3e962f6)
In gimp_group_layer_flush(), stop any idle rendering, initiated
when a new buffer is allocated, before flushing the group's
pickable. Otherwise, the idle rendering is finished synchronously,
which unnecessarily introduces a noticeable lag.
(cherry picked from commit a4957c7c76)
... which specifies whether or not to update the drawable in
response to the buffer change.
Pass TRUE for "update" at all existing call sites, to keep the
current behavior.
(cherry picked from commit 26a8d141f6)
In GimpProjection, respond to the projectable's "bounds-changed"
signal, by reallocating the buffer, and copying the corresponding
region of the old buffer (using
gimp_tile_handler_validate_buffer_copy(), added a few commits back,
so that the relevant portion of the validate handler's dirty region
is also copied). Additionally, shift and clip all outstanding
update regions as necessary (actually, we avoid copying the buffer
when a shift is necessary, and simply reconstruct the projection;
see FIXME comment in the code.)
(cherry picked from commit fbeae36118)
... and a corresponding gimp_projectable_bounds_changed() function.
This signal can be emitted by implementers of GimpProjectable,
instead of the GimpProjectable::structure-changed signal, when the
projectable's bounds change, but its content does not -- i.e., the
old content simply gets cropped to the new bounds.
(cherry picked from commit 460c3d1349)
Add gimp_tile_handler_validate_buffer_copy(), which can be used
instead of gegl_buffer_copy(), to copy a (subregion of a) source
buffer to a destination buffer with a GimpTileHandlerValidate,
uninvalidating, and avoiding unnecessarily rendering, the
affected region. Additionally, if the source buffer also uses a
GimpTileHandlerValidate, the relevant parts of the source buffer's
dirty region are copied to the destination's dirty region as well.
(cherry picked from commit eeed4778a2)
... which should be used to properly remove a
GimpTileHandlerValidate from a buffer, instead of using
gegl_buffer_remove_handler() directly.
Use gimp_tile_handler_validate_unassign(), instead of
gegl_buffer_remove_handler(), in gimp_projection_free_buffer().
(cherry picked from commit 12530e21b2)
In GimpTileHandlerValidate, when allocating a new tile upon a
TILE_GET command, but not rendering the whole tile, clear the tile
data before rendering, so that the unrendered regions of the tile
contain zeros, rather than junk.
(cherry picked from commit e1e4ba9c8b)
This is my attempt to get better labels, shorter and also (hopefully)
improved English.
As Mitch states though, this is a Japanese-French-German conspiracy! So
any of you native English speakers out there, please review and suggest
proper English if needed. :-)
(cherry picked from commit 9cdedc98f8)
Adding spaces between function names and parenthese.
I would normally have just amended the contributed patches and pushed,
but gitlab is making our review process over-complicated with many
roundtrips with contributors, and review quality drops. Stating it here
for the records!
See commit 70945b8960 (where this cleaning
should have directly been done).
(cherry picked from commit 5c56f8cb3a)
anchor of LTR is top-left corner.
anchor of TTB-RTL is top-right cornner.
anchor of TTB-LTR is top-left cornner.
(cherry picked from commit 70945b8960)
Back when I implemented this as a recommendation, gettext 0.19 was not
even out yet. Nowadays it is in Debian Testing (Debian Stable even!), so
it makes no sense to continue just "recommend" it, especially as it was
breaking script-fu localization.
See old commit feb1bf2797.
(cherry picked from commit 8e6afe10a6)
This fish is used for text layers, so if we let it to be
lazy-initialized, the first time one writes text in a text layer, it
generates a few seconds delay, which is really not great.
(cherry picked from commit a03e52ea08)
Fixes:
> WARNING: Failed to validate desktop file […] for locale string list
> key "Keywords[mr]" in group "Desktop Entry" does not have a semicolon
> (';') as trailing character
I just added a semicolon.
(cherry picked from commit 79a5c304d2)
In gimp_layer_convert(), avoid converting the drawable type when
the source and destination color profiles are equal, if otherwise
unnecessary. Otherwise, text layers get unnecessarily re-rendered
during conversion, and, by extension, during image duplication
(which happens when exporting to any format that requires merging
down the image). This may cause the text layer to appear
differently in the duplicated image, or even use a different font
if the original font doesn't exist.
(cherry picked from commit a826a19359)
When duplicating an image, copy the source image's is-color-managed
status to the duplicated image, instead of having the duplicated
image always be color managed. In particular, do this before
duplicating the layers, so that we don't convert the duplicated
layers from sRGB to the image's profile when duplicating an image
with a non-sRGB profile but with color management turned off.
(cherry picked from commit f38443f3b0)
They are not perfect (not a designer here!) but a bit less packed than
the previous one. So hopefully more understandable.
(cherry picked from commit e326faa77c)
Squashed commit of the following:
commit ee1ff7d502658cfa1248a13a3f0348495db07eda
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sun Jul 29 00:31:47 2018 +0900
Fixed that gimp-text-dir-ttb-* icons are lacked in Symbolic.
commit d87d012d697628da28fe90199cc04b95b72ba8ef
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 16:23:10 2018 +0900
Fix a typo.
commit cf0238bf7df56c384cdf3b7ec69557d14740f853
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Sat Jul 28 15:50:57 2018 +0900
Fixed seg fault error.
commit b07f60d06fa1a753fda5b4d46af01698c344154e
Author: ONO Yoshio <ohtsuka.yoshio@gmail.com>
Date: Fri Jul 27 17:15:34 2018 +0900
Add support for vertical text writing.
https://gitlab.gnome.org/GNOME/gimp/issues/641
(cherry picked from commit 587d9bbb03)
Just like it was until now, the default filtering should not be all
files, but only relevant files (i.e. XCF when saving, exportable images
when exporting and loadable images/XCF when opening).
Now all files will only be available through the "Show All Files"
checkbox.
This is simpler than previous implementations where the list was
proposing "All Files", "All Images" and "All XCF/export images". That is
just too much.
With this default, I get the "All Files" checkbox out of the expander so
that it is visible immediately even when the format list is unexpanded
(you don't want people to get pissed when not finding how to display all
their files).
(cherry picked from commit 6b4b3bad13)
... format selection.
Second step: add a "Show All Files" checkbox so that one can still
prevent view filtering even when forcing a load format.
This is useful when loading files with unusual extensions, for instance.
(cherry picked from commit 6369445874)
... format selection.
As discussed, the first step is to get rid of the filter list. Our extra
widget now has both roles of filtering the file list and forcing a
loading procedure.
(cherry picked from commit 9ae7827f9b)
In subdirs containing a generated foomarshal.h header, add the
generated sources to BUILT_SOURCES, so that they're generated
before the rest of the source files are built. Otherwise, since
there is no rule specifying the dependency between the rest of the
source files and foomarshal.h, and since foomarshal.h is not
checked into git (and hence doesn't exist when doing a clean
build), compilation of the said source files may fail if they're
built before foomarshal.h is generated.
(cherry picked from commit a5102a7dba)
In GimpFilterTool, bind the controller's lifetime to the lifetime
of the config object, rather than to the lifetime of the
corresponding tool widget; make the controller's widget pointer a
weak pointer to the widget, and bail out of the controller "set()"
functions when the widget pointer is NULL.
This fixes an issue arising when the properties of a config object
that outlives the widget change after the widget had died,
triggering a call to the controller's set() function, resulting in
a segafult when trying to access the widget.
(cherry picked from commit 78abe756f1)
When constructing a prop-GUI widget for an angle property with a
dial, use the the property's "direction" UI-meta, if exists, to set
the direction of the dial. Together with GEGL commit
7b0578073a0f20334b5a8a8fe57b649d9f302454, this fixes wrong dial
direction in certain ops that use clockwise angles.
(cherry picked from commit 6976e87dac)
... and rename "clockwise" to "clockwise-delta"
Add a boolean "clockwise-angles" property to GimpDial, which, when
set, causes the dial legs' angles to be measured clockwise, rather
than counter-clockwise. The property is FALSE by default.
Rename the "clockwise" property, which controls the direction of
the measured delta between the two angles, to "clockwise-delta", to
avoid confusion, and adapt the rest of the code.
(cherry picked from commit 0c477564ad)
... from layer context menu
In gimp_text_tool_set_layer(), do nothing if the input layer is the
currently-edited layer, otherwise we get a CRITICAL.
(cherry picked from commit 6b1d77b11c)
Second parameter of gimp_scanner_parse_token() and
gimp_scanner_parse_identifier() is not a return value. It is a value to
compare with.
(cherry picked from commit bc427479e0)
This is a "for info" comment so that packagers don't forget them when we
sometimes depend on some specific GEGL dependencies.
(cherry picked from commit 530a2bd9a5)
In the dynamics editor, use the neutral curve color, which depends
on the current theme, for the "fade" curve, instead of hard-coding
it to dark gray, which is hardly visible with dark themes.
(cherry picked from commit b2a9bb4688)
... depending on UI language
Use gimp_register_file_handler_priority(), added in the previous
commit, to increase the priority of the merged PSD loader, so that
the non-merged loader is always preferred over it (unless
explicitly chosen), regardless of the UI language.
(cherry picked from commit 0320126254)
Add a gimp-register-file-handler-priority procedure, which can be
used to set the priority of a file-handler procedure. When more
than one file-handler procedure matches a file, the procedure with
the lowest priority is used; if more than one procedure has the
lowest priority, it is unspecified which one of them is used. The
default priority of file-handler procedures is 0.
Add the necessary plumbing (plus some fixes) to the plug-in manager
to handle file-handler priorities. In particular, use two
different lists for each type of file-handler procedures: one meant
for searching, and is sorted according to priority, and one meant
for display, and is sorted alphabetically.
(cherry picked from commit b4ac956859)
In GimpToolCompass (and, as a consequence, in the measure tool),
update the measured angle when the shell is scaled, rotated, or
flipped, so that we always satisfy the compass's constrains, and
render correctly.
(cherry picked from commit a810c6b60b)
When using a GimpToolCompass in 3-point mode, add a small gap after
the angle arc to the line corresponding to the "second" non-origin
point, so that it's visually distinguishable from the line
corresponding to the "first" point. This has significance for the
measure tool, since it determines the direction of the rotation
when straightening the image (the first point is rotated toward the
second point.)
(cherry picked from commit 0f03f9e9f5)
... does not restore the measure points
Halt the measure tool after straightening, thus removing the
expectation that undoing the operation should restore the original
points.
Halting the tool, rather than making undo work "as expected",
sidesteps several issues:
- Implementing undo correctly is tricky, since image-undo and
tool-undo are handled separately.
- In fact, the measure tool doesn't provide tool-undo, so that
image edits can be undone while the tool is active without
affecting the tool, and it's not clear that we want to change
this behavior. However, this makes undoing a straighten
operation a special case, and it's not entirely clear what the
behavior should be when undoing other kinds of transformations,
or when the measure points had changed since the straighten
operation.
- Perhaps most importantly, measure tool points are restricted to
the pixel grid, which means that when measuring an angle
against an orientation that's not fully horizontal or vertical
in image space (either using a 3-point angle, or when the
canvas is rotated), the resulting transformed point after
straightening doesn't generally land on the pixel grid, causing
it to be rounded, which can result in a non-zero angle after
the rotation. This is especially ugly, since clicking
"straighten" again at this point would cause another non-
trivial rotation.
(cherry picked from commit 2e08c9164a)
Rename XCF property PROP_SAMPLE_POINT to PROP_OLD_SAMPLE_POINT and add
new PROP_SAMPLE_POINT.
The new property saves the sample point's pick mode plus some padding
for whatever else we might want to add. Always save the old property
too so nothing changes for older GIMP versions, and avoid loading the
old property if the new one was loaded before.
(cherry picked from commit 47a008be97)
Bind the "orientation" property of the measure-tool options to the
tool's compass widget's "orientation" property, instead of manually
synchronizing their values.
(cherry picked from commit 7a91aabf37)
Add an "orientation" option to the measure tool, corresponding to
the "orientation" property of GimpToolCompass (i.e., it controls
the orientation against which the angle is measured, when not in 3-
point mode.) The orientation is "auto" by default, so that the
angle is always <= 45 deg. Note that the "orientation" option
affects the tool's "straighten" function, so that the layer is
rotated toward the current orientation.
Use the "pixel-angle" and "unit-angle" properies of
GimpToolCompass to read the measured angle, instead of duplicating
the angle-measurement logic, in particular, so that we benefit from
the improvements/fixes of the previous commit.
(cherry picked from commit cb3b7a1ba5)
Add an "orientation" property to GimpToolCompass, which can be one
of "auto", "horizontal", or "vertical", and which controls the
orientation of the line against which the angle is measured, when
not in 3-point mode (previously, the line would always be
horizontal.) When "orientation" is "auto", the orientation is
automatically set to either horizontal or vertical, such that the
measured angle is <= 45 deg.
Keep the line horizontal, or vertical, in display-space, rather
than in image-space, so that the compass works correctly even when
the canvas is rotated and/or flipped.
Fix the compass's behavior when the image's horizontal and vertical
resolutions are different, both with and without dot-for-dot.
Add "pixel-angle" and "unit-angle" read-only properties, which
return the measured angle either with or without taking the image's
resolution into account, respectively. These properties will be
used by the measure tool in the next commit, instead of having it
implement its own angle calculation.
(cherry picked from commit d2f33cf1be)
Fix gimp_constrain_line() and friends to properly constrain line
angles when the image's horizontal and vertical resolutions are
different, and dot-for-dot is disabled.
(cherry picked from commit 4fefab1798)
Remember the sample point's GimpColorPickMode in the sample point
itself, so it is remembered across switching between images.
Not persistent in the XCF yet tho...
(cherry picked from commit a0129504c8)
This is just some preparation for fixing issue #1805, but actually
"target" is a much better name so I went the full way and also changed
GUI labels and the color picker tool options config property
accordingly.
If anyone notices at all, how horrible is it to lose your saved pick
target...
(cherry picked from commit b140b283dc)
In gimp-parallel, always flush the async-operations queue (by
executing all remaining operations on the caller thread) when
setting the async-pool thread count to 0 (as happens when setting
GEGL_THREADS=1, per the previous commit,) and not only when
shutting GIMP down. Otherwise, pending asynchronous operations
can "get lost" when setting GEGL_THREADS to 1.
Additionally, in gimp_gegl_init(), initialize gimp-parallel before
before connecting to GimpGeglConfig's "notify::num-processors"
signal, so that the number of async threads is set *before*
GEGL_THREADS, in order to avoid setting GEGL_THREADS to 1 while
async operations are still executing.
Also, allow setting the number of gimp-parallel-distribute threads
while a gimp-parallel-distribute function is running (which can
happen if gimp-parallel-distribute is used in an async operation,
as is the case for histogram calculation), by waiting for the
parallel-distribute function to finish before setting the number of
threads.
(cherry picked from commit 432a884715)
When GEGL_THREADS=1, concurrent access to the same buffer is not
safe, which can result in errors if asynchronous operations are
allowed to run in parallel to the main thread (see
https://gitlab.gnome.org/GNOME/gimp/issues/1721#note_265898.)
Disable parallel execution of asynchronous operations when
GEGL_THREADS=1 for now, to fix this. Ultimately, GEGL should be
able to remain thread-safe even when GEGL_THREADS=1. Note that we
want to execute asynchronous operations on a separate thread even
when GEGL_THREADS=1, since the goal here is mainly to avoid
blocking the main thread during their execution, rather than
speeding their execution up (in particular, it's benecifical to run
asynchronous operations in parallel even on a single-core machine,
while parallelizing GEGL operations generally isn't.)
(cherry picked from commit 408540659f)
In GimpContainerTreeView, don't process updates in response to a
selection-change if the selection is empty (for the reason this is
necessary in the first place (though not in this particular case),
see commit f9a71fb6de5a2e65e0d88c6b7aaa39f589d6cdc4.) When
clearing the container-view's context, we deselect all items after
setting the context to NULL, in which case
gimp_view_renderer_draw() warns, breaking one of our tests.
...not found if language changed since last session
For various reasons, (gimp-context-get-brush, pattern, gradient, ...)
can return "Standard" which is the untranslatable name of the internal
fallback object.
Therefore, we must accept "Standard" as fallback in all PDB functions
that take brush, pattern, gradient etc. names.
(cherry picked from commit 397ae027ba)
...and successfully fails
Commit d2ad2928 removed "gradient-repeat" from GimpPaintOptions, not
considering that it is also used in the PDB.
Move "gradient-repeat" from GimpGradientOptions back to
GimpPaintOptions, and add a comment that it is only used by the
gradient tool, not for painting.
(cherry picked from commit c3d37140eb)
- "LCh" intead of "LCH"
- "CIE LCh" instead of "CIELCh"
- "HSV Hue" instead of "Hue (HSV)" for all models/components
(cherry picked from commit 926dc070ef)
In GimpContainerTreeView, work around a GTK bug which can cause the
window containing the tree view to stop processing updates,
resulting in an apprarent freeze, until update-processing is
explicitly requested. This can be triggered by adding layers to a
layer group until the layers-dialog tree view is almost full, but
still doesn't have a scrollbar, and then duplicating the group.
This doesn't seem to affect GTK3, so not applying to master.
Don't destroy the color frames when the number of points changes.
Instead, simply hide them so they keep their color model, but add an
upper limit of an arbitrary number of 16 frames to keep around.
(cherry picked from commit 370680f9bc)
Use gimp_babl_is_valid(), added in the previous commit, to validate
image-type/precision combinations in various functions.
(cherry picked from commit 49ca383fa4)
... (valgrind reports Invalid read)
Add gimp_babl_is_valid(), which takes a GimpImageBaseType and a
GimpPrecision, and determines whether the image-type/precision
combination is valid. Use this function to validate that loaded
XCFs use a valid type/precision combination, before trying to
create the image. Otherwise, we get a CRITICAL, and eventually a
segfault, when the combination is invalid.
Use the same function to validate the arguments of
gimp_image_new().
(cherry picked from commit a0a62656d2)
Introduce GIMP_PATTERN_MAX_SIZE (10000) and GIMP_PATTERN_MAX_NAME (256)
and validate pattern dimensions and pattern name length against them.
Add GIMP_BRUSH_MAX_NAME and validate that too.
Also make sure that the names are properly terminated, and some
cleanup.
(cherry picked from commit 9b56ca8c1d)
In app_exit_after_callback(), call gimp_gegl_exit() before
gegl_exit() when performing a quick shut-down in stable versions,
so that gimp-parallel, and, in particular, the async thread pool,
is properly shut down. Code running in the async thread pool may
use GEGL (in particular, now the drawable previews are rendered
asynchronously), and calling gegl_exit() while it's still running
is unsafe.
(cherry picked from commit ed033b1cb5)
In GimpAction, instead of connecting the action-history log
function to the action's "activate" signal as a user-provided
handler, call it directly from the default handler.
In subclasses of GimpAction, chain to the parent's activate()
function before emitting the "selected" signal, so that we always
log the action in the history before responding to it.
This allows us to avoid the hack in commit
6544ce4301.
(cherry picked from commit 114d49510f)
In gimp_metadata_set_from_{exif,iptc,xmp}(), gracefully reject data
of invalid size, returning an error instead of raising a critical.
In particular, this avoids a CRITICAL when loading an XCF with an
empty exif-ata parasite.
(cherry picked from commit eafefc7d81)
In xcf_write_int8(), avoid calling g_output_stream_write_all() with
data == NULL and count == 0, in which case it raises a CRITICAL and
doesn't set bytes_written, which we proceed to use uninitialized.
This can happen, e.g., when writing an empty parasite.
(cherry picked from commit 8e798e9cf2)
In gimp_color_profile_new_from_icc_profile() and
gimp_image_validate_icc_profile(), don't raise a critical when
encountering an empty profile, but rather reject it gracefully with
an error.
(cherry picked from commit 10f33b080b)
... (Invalid read reported by valgrind)
In gimp_image_parasite_validate(), don't segfault when validating
a "gimp-comment" parasite of size 0 (i.e., whose data is a 0-byte
array, not an empty string), and just consider it invalid.
(cherry picked from commit f384a0713d)
... (Invalid read reported by valgrind)
In xcf_read_int8(), avoid calling g_input_stream_read_all() with
data == NULL and count == 0, in which case it raises a CRITICAL and
doesn't set bytes_read, which we proceed to use uninitialized.
This can happen, e.g., when reading an empty parasite.
(cherry picked from commit 6ebadea7c1)
In gimp_action_history_activate_callback(), bail if history.gimp is
NULL, instead of dereferencing it. This can happen if GIMP is shut
down during the execution of a temporary procedure, such as a
script-fu script. See the code comment for details.
(cherry picked from commit 6544ce4301)
Remove the now-useless "independent" parmaeter. It is supplanted
by the new gimp_parallel_run_async_independent() function.
(cherry picked from commit 00d034a1d4)
Add an "async" field to the dashboard's "misc" group, showing the
number of async operations currently in the "running" state (i.e.,
all those GimpAsync objects for which gimp_async_finish[_full]() or
gimp_async_abort() haven't been called yet).
(cherry picked from commit aa382650a1)
Preview generation for layer groups is more expensive than for
other types of drawables, mostly since we can't currently generate
layer-group previews asynchronously. Add a preferences option for
enabling layer-group previews separately from the rest of the
layer/channel previews; both of these options are enabled by
default. This can be desirable regardless of performance
considerations, since it makes layer groups easily distinguishable
from ordinary layers.
(cherry picked from commit 30cc85fd63)
In the preferences dialog, make the "dither images when promoting
to floating point" option insensitive when the "promote impoprted
images to floating point precision" option is unchecked.
(cherry picked from commit 5b9bc0aadd)
In GimpViewRendererDrawable, use
gimp_drawable_get_sub_preview_async(), added in the previous
commit, to render drawable previews asynchronously. While the
preview is being rendered, either keep showing the previous
preview, or render a placeholder icon.
This commit also fixes an issue where, under certain conditions, a
drawable preview would be rendered, even when layer/channel
previews are disabled in the preferences.
(cherry picked from commit 8a81bfd2f1)
... which is an asynchronous version of
gimp_drawable_get_sub_preview().
We currently support async preview generation for drawables whose
buffer isn't backed by a GimpTileHandlerValidate tile handler
(i.e., anything other than group layers), since preview generation
fir such drawables may involve processing the corresponding graph,
which isn't thread-safe.
When the GIMP_NO_ASYNC_DRAWABLE_PREVIEWS environment variable is
defined, all drawable previews are synchronously generated.
(cherry picked from commit d79e3fbd6f)
Remove the "independent" parameter of gimp_parallel_run_async(),
and have the function always execute the passed callback in the
shared async thread-pool.
Add a new gimp_parallel_run_async_full() function, taking, in
addition to a callback and a data pointer:
- A priority value, controlling the priority of the callback in
the async thread-pool queue. 0 is the default priority (used
by gimp_parallel_run_async()), negative values have higher
priority, and positive values have lower priority.
- A destructor function for the data pointer. This function is
called to free the user data in case the async operation is
canceled before execution of the callback function begins, and
the operation is dropped from the queue and aborted without
executing the callback. Note that if the callback *is*
executed, the destructor is *not* used -- it's the callback's
responsibility to free/recycle the user data.
Add a separate gimp_parallel_run_async_independent() function,
taking the same parameters, and executing the passed callback in
an independent thread, rather than the thread pool. This function
doesn't take a priority value or a destructor (and there's no
corresponding "_full()" variant that does), since they're pointless
for independent threads.
Adapt the rest of the code to the changes.
(cherry picked from commit b74e600c12)
and remove all other tool options parent setting/unsetting and
property copying code. Also select a tool at the end of
tool_manager_init() so it is in sync with what the tool options
manager does.
(cherry picked from commit 37f69457b7)
tool_options_manager_tool_changed(): also copy the non-global paint
options of the new tool to the global paint options, so they get used
when "global_foo" is enabled.
(cherry picked from commit 1b858eb4ad)
tool_options_manager_paint_options_notify(): sync properties between
tool paint options and global paint options if the property is global
*or* the active tool is involved.
tool_options_manager_global_notify(): don't mess with the active
tool's connection to the user context or its properties at all, it is
always fully connected to the user context anyway.
(cherry picked from commit 54257da7c4)
The way we currently manage tool options, and particularly copy things
around for "global_brush", "global_pattern" etc. sucks, is spread
across files, happens only on tool change, is thus buggy and leads to
all sorts of small inconsistencies.
This new manager will replace all of that stuff, and it does it in one
place, and will keep the user context, the global paint options, and
all tool options connected permanently, and only connect/disconnect
things when settings change, so everything is always in a consistent
state.
Pushed for review only, nothing is used yet.
(cherry picked from commit ef952f2926)
In GimpMeter, use cairo_path_extents() for getting the history
graph's extents, rather than cairo_clip_extents(), since the latter
may also include clipping applied by GTK.
(cherry picked from commit b8e08cddbc)
According to some bug reports, it seems that under some (unknown)
conditions we might save an empty custom gradient file on exit (for
equally unknown reasons). The only difference in the way we save
internal data files, such as the custom gradient, compared to
gimp_data_save(), is the fact that we currently don't explicitly
close the output stream, but rather only unref it.
The output stream should be implicitly closed (and hence flushed)
upon destruction, but maybe the unreffing is not enough to
guarantee that it's actually destroyed (maybe it spawns an extra
reference for some reason, who knows.) Anyway, let's just
explicitly close it, which also gives us a chance to catch and
report any errors occursing during flushing/closing (which,
altenatively, might be the culprit).
Additionally, a few more error-reporting improvements, to match
gimp_data_save().
(cherry picked from commit a72f7f1ace)
In gimp_data_factory_finalize(), wait on the factory's async set
after canceling it, and before continuing destruction. It's not
generally safe to just abandon an async op without waiting on it
-- this is a font-specific hack, due to the fact we can't actually
cancel font loading, and GimpFontFactory is prepared to handle
this.
Instead, in gimp_font_factory_finalize(), cancel and clear the
async set, so that GimpDataFactory doesn't actually wait for
loading to finish.
In gimp_font_factory_load_async_callback(), don't try to acess the
factory when the operation is canceled, since cancelation means the
factory is already dead. On the other hand, when the opeation
isn't canceled, make sure to thaw the container even when font
loading failed, so that we always match the freeze at the begining
of the operation.
(cherry picked from commit b5890e05b8)
GIMP_BRUSH_MAX_SIZE was already defined (as 10.000 pixels per dimension,
which is big for a brush) in gimpbrush.h. Let's just use this to
validate the size returned by the header.
(cherry picked from commit b3de0bb7a5)
The "move-current" flag does not apply to selection mode and our current
code was simply setting the radio buttons insensitive while showing the
same labels on both buttons. This was not wrong per-se, yet very
confusing.
Instead let's just hide the radio buttons in selection mode, and update
the option title to "Move selection" (old label of both buttons) to keep
this mode as understandable as possible.
(cherry picked from commit 7cbbb8cba8)
When defining a dashboard group, allow specifying multiple
variables as input to the group meter's LED. The LED is active
when any of the specified variables evaluates to TRUE, and its
color is the combination of the active variable colors.
Remove the swap-busy variable, and use swap-reading and
swap-writing as inputs to the swap group's LED instead, so that the
LED's color indicates whether the swap is currently being read-
from, written-to, or both.
(cherry picked from commit 716510cb83)
Put the center_image_on_size_allocate() code into the canvas'
size-allocate callbacck.
As a side effect we now have a flag in GimpDisplayShell which
indicates that there will be a size allocate before the next frame, so
simply skip drawing the canvas completely. This fixes new images
jumping around when they are first shown.
(cherry picked from commit c0480f502d)
(this fix is actually a side effect from fixing something else in
master)
The flag `free_selection_string` is used to track an array of strings
with some of them being static and others allocated. This should have
been an array of boolean but we can't change it because it is public API
(though it should really not have been!).
So let's just allocate every string of the `selection` array instead,
which makes the boolean flag useless now.
As discussed on IRC with Mitch and Samm.
Older versions may work, and Samm says he will build for 10.9 actually,
but we officially only supports for 10.10.
When ENABLE_RELOCATABLE_RESOURCES is set, override libwmf fontdir. This
is actually an alternate version of MR !9 by Alex Samorukov assuming a
bundled GIMP on a single prefix rather than depending on an environment
variable.
This especially makes the relocatable feature more discoverable (rather
than some random environment variable for which you'd need to read the
code to discover it then make some wrapper script for GIMP).
(cherry picked from commit 4ff856f68d)
... --enable-relocatable-bundle option.
This will allow to use this option for more than MyPaint brushes. For
macOS and Windows, we default to "yes" and "no" for other OS, though it
is always possible to set an explicit value.
(cherry picked from commit 8da2646372)
And uncommenting the <release> tag for translators to be able to work on
it. Also using short list items without finale points to agree with
`appstream-util` rules.
(cherry picked from commit 4fa5f61dae)
As asked by Samm and solid_black on IRC.
Apparently tested and the change is fine, while getting rid of
deprecated API. I cannot test myself.
(cherry picked from commit 1b9729d46d)
We should not have essential signal connections (such as setting tool
options from brush properties) implemented in the tool options GUI
files, because they are not active until the options GUI is created.
Also, that magic is simply too hidden in the options GUI files.
Move the signal connections and the brush property copying code to
gimppaintoptions.c where is can also be done cleaner.
However, this must only be done for the main tool options instance
that is used for the GUI. Therefore, add a "gui_mode" boolean to
GimpToolOptions and set it to TRUE for all main tool options.
(this is ugly, but much less ugly and much less hidden than all the
places where code lives (like tool_manager.c) that can now be moved
into GimpToolOptions and its subclasses, and implemented cleanly
there).
(cherry picked from commit cb0e6c65d0)
GTK always returns 72 dpi due to API used. This patch using Cocoa
directly instead. Tested on Retina and non-hidpi displays.
GTK+2 version of commit 5b6126146a.
Cf. MR !14.
... after each successful read().
I completely missed this declaration after a statement during the review
of !13 even though I saw another similar issue!
Also let's reset the error counter to 0 each time a successful read()
happens so that we can continue reading even if a lot of EINTR were to
happen, as long as we globally go forward. Only consecutive errors
increment the counter.
Finally add a small comment to explain why we let EINTR pass instead of
breaking directly.
(cherry picked from commit 49b4b1a5c2)
When lldb attaching to the process it triggers few "-1" errors on read with
EINTR error. After 1-2 errors read() call works again.
Also this patch fixing TID detection, syscall SYS_gettid is oficially deprecated
now and does not work. Also adding safecheck to avoid enldless loop.
(cherry picked from commit 559d9b89e3)
... metadata by default".
Also for other metadata, and doing it both for the tooltip and the label
of the option.
(cherry picked from commit 50bcc8db3c)
Let the split and replicate segments dialogs keep their own data and
don't use GimpGradientEditor struct members. Remove redundant members
and indent the struct.
(cherry picked from commit b8e75a0201)
This reverts commit d997b2b897.
This is not needed anymore since gimp_widget_load_icon() always returns
a non-NULL GdkPixbuf now. Cf. commit 32931c4606.
We were already doing so when an icon was simply absent from the icon
theme. But we may still end up in cases where the icon is seemingly
present, yet it fails to load (for instance the image file is
corrupted). When this happens, let's also try to load the wilber-eek
fallback.
Note that it doesn't completely stops gimp_widget_load_icon() from
possibly returning NULL (in the case where "gimp-wilber-eek" is also
missing/corrupted for instance), so calling code must still account for
possible NULL return value.
If "gimp-swap-colors" or "gimp-default-colors" are present in the theme,
yet broken somehow, GIMP would crash because it was not checking if the
icons had been successfully loaded.
Just make the relevant checks and output on standard error that the swap
and/or default color areas are invisible.
Set the tooltip in GimpColorHexEntry itself and remove all other
tooltip setting. This just moves the translatable string sround in
libgimpwidgets/, and even removes it from app/.
(cherry picked from commit 2b8b780b6a)
This will allow a designer to simply "tag" an object so that its color
does not get overrided by GTK+ without needing to edit the file as text.
(cherry picked from commit 8a36b786bc)
It should now be possible to fully export our symbolic icons from a
single central file.
My long-standing bug of librsvg#250 is still opened and unfixed, but it
turns out most issues I encountered are anyway also problems when
recoloring symbolic icons in GTK+ (like using strokes instead of
fills!). So let's just bypass all problems at once by accounting for
these issues in the design.
(cherry picked from commit 4c68d5dfc9)
I tried to fix all the icons I could see which had issues regarding all
recoloring matters (using fill not stroke, change circle/ellipses to
paths, etc.) when looking at a blank canvas.
I'm sure I still miss a lot but that will do for now.
(cherry picked from commit 8811b0d916)
Sometimes even within symbolic icons, parts of the design must keep
fixed colors, when they are semantic. For instance this is the case for
the color-picker-(black|gray|white) icons or the gimp-default-colors.
The trick used by GTK+ to recolor is by supplying an additional CSS
style to icons which overrides inline CSS thanks to "! important"
keyword. Our own trick to circumvent this trick is to set "!important"
in inline CSS when one wishes not to have it overrided by the general
colors.
Right now I am doing the edit by hand with vim because Inkscape doesn't
seem to validate this keyword if I add it manually in its XML editor. So
what I did is add the "color-important" label on such object, and I will
later modify my SVG export tool to add !important on such object "fill"
values at export time.
(cherry picked from commit 5d5bbeb88b)
The current recolorization code only recolors paths and rectangles. In
particular it leaves circles and ellipses as-is.
I opened the merge request gtk!214 for this issue. But in the meantime,
it is quite easy to change circles and ellipses into path with "object
to path" in Inkscape.
A second problem is that it only recolors fills, not strokes, as
previously stated. So I need to remove strokes from icons, or transform
them to paths.
(cherry picked from commit fd46018203)
It seems not wide enough to differentiate easily the broken and
non-broken chains. So let's make this gap bigger.
(cherry picked from commit a5afb04501)
This time, 2 icons still had problems because of visible rectangles.
Fixing "gimp-prefs-folders" and "gimp-prefs-folders-mypaint-brushes".
(cherry picked from commit 2bb8afd119)
For anyone wishing to help me fix icons, here is the trick: apparently
GTK+ would fill the paths with CSS colors, not stroke them. So when we
have icon drawing based on path-stroking, they don't end up as expected.
In Inkscape, just run "Stroke to Path" to transform a stroke design in a
fill design.
I am fixing "gimp-tool-cage", "document-revert", "gimp-image-reload",
"gimp-reset" and "view-refresh". More to follow as we discover them, I
guess.
(cherry picked from commit 4b6869dd67)
Return an optional tooltip from gimp_procedure_get_sensitive(), in
GimpPlugInProcedure, build that tooltip from the image types the
procedure works on.
(cherry picked from commit 63817485c0)
... to satisfy the inter-variable dependencies, so that the READING/
WRITING variables are based on the READ/WRITTEN values of the
current sample, and not the previous one.
(cherry picked from commit 51793b114a)
... and gimppaintcore-loops
When a rectangle argument is NULL, use the extents of the
corresponding buffer, instead of raising a CRITICAL, to match the
old behavior.
(cherry picked from commit 8a881ca61a)
Don't show percentage for the swap read/written fields, and make
sure their history underlays are displayed correctly even if the
swap limit changes.
(cherry picked from commit fda671841c)
Add "read" and "written" fields to the dashboard swap group, which
report the total amount of data read-from/written-to the tile swap,
respetively. These fields are non-active by default. When these
fields are active, show a color underlay in the swap group's meter,
indicating when data was beging read-from/written-to the swap.
Improve the swap busy indicator (used as the meter's LED), so that
it's active whenever data has been read-from/written-to the swap
during the last sampling interval, rather than at the point of
sampling.
(cherry picked from commit 6b9aba3067)
Use gimp_input_data_stream_read_line_always(), instead of
g_input_data_stream_read_line(), in a bunch of places that don't
expect EOF. If we don't do that, the code assumes the GError
parameter is set by the function and returns an error indication,
causing the caller to segfault when it tries to access
error->message. Instead, we now process an empty line when EOF is
reached, which is caught by the normal parsing logic.
Additionally:
- Use gimp_ascii_strto[id]() when loading gradients, generated
brushes, and palettes, to improve error checking for invalid
numeric input.
- Improve gradient-segment endpoint consistency check.
- Allow loading palette files with 0 colors. They can be created
during the session, so we might as well successfully load them.
(cherry picked from commit 993bbd354e)
... which are similar to g_ascii_strtoll() (except that
gimp_ascii_strtoi returns a gint, and not a gint64), and
g_ascii_strtod(), however, they make error checking simpler, by
returning a boolean value, indicating whether the conversion was
successful (taking both conversion and range errors into account),
and return the actual value through a pointer.
(cherry picked from commit 3301c06163)
... which is a drop-in replacement for
g_data_input_stream_read_line(), however, it always returns a non-
NULL value when there's no error. If the end-of-file is reached,
an empty string is returned.
(cherry picked from commit e090b910c0)
same code as in GimpDeviceManager, should be only ever needed in the
presence of debug modules like GtkInspector.
(cherry picked from commit bf66882878)
...while other windows are on the second monitor if window positions
are saved at exit
Add some lines of code to color_area_color_clicked() which position
the already existing color dialog exactly like a newly created dialog
would be positioned by gimp_dialog_factory_add_dialog().
This should be part of GimpDialogFactory but let's wait for another
case before we generalize it.
(cherry picked from commit 1ae2b5d573)
When using the color-picker tool's info window, set the tool's
display when a color is picked, and the gui is updated, so that we
properly halt the tool when the display is closed. Otherwise, we
may segfault.
(cherry picked from commit 335023b127)
The memory group shows memory-usage information: the currently used
memory size, the available physical memory size, and the total
physical memory size. It can also show the tile-cache size, for
comparison against the other memory stats. The memory group is
active but contracted by default.
Note that the upper-bound of the meter is the physical memory size,
so the memory usage may be > 100% when GIMP uses the swap.
This is currently implemented for *nix systems with Linux-like
procfs, and Windows.
(cherry picked from commit 8d0766c1fc)
gimp_layer_create_mask(): make sure we don't do a gamma conversion
when initializing the mask from a channel. This was probably not the
last place to need this fix.
Also get rid of a second switch(add_mask_type), must be some leftover
from long gone logic.
(cherry picked from commit f815a2d922)
PSD files may include a "merged", pre-composited, version of the
image (in Photoshop, this is the case when saving files with
"Maximize Compatibility" enabled; GIMP always saves the merged
image data in exported PSD files.) This commit adds support for
loading the merged image version from PSDs, instead of the full
layer hierarchy. This is useful when loading PSD files that use
features that we don't currently support, and therefore can't
render correctly, such as adjustment layers.
When loading the merged image version, we avoid loading certain
additional data from the file, such as channels, paths, and
guides, while still loading metadata, making this akin to loading
other "flat" image formats.
This option is currently exposed as an additional file type
("Photoshop image (merged)"), which has to be explicitly selected
from the file-type list when opening the image.
(cherry picked from commit 1d9a8a91ab)
...upon exporting an image
Step 1: make it configurable just like "Export EXIF" etc.
app, libgimp: add "export-color-profile" config option
Add it to the preferences dialog, and pass it on to plug-ins in the
GPConfig message. Add gimp_export_color_profile() to libgimp.
Nothing uses this yet.
(cherry picked from commit 8c9c091021)
Mostly formatting and thortening variables. Only real change is adding
gimp_clipboard_new() and moving most init() code there.
(cherry picked from commit e0f46d1dc9)
Make the bottom-left entry request only minimal width, it expands
anyway. Also replace the "Columns:" label by a "grid" icon and set a
tooltip on the columns spinbutton.
Addresses Issue #1223 too.
(cherry picked from commit 0aa018dec2)
Replace "Selection Bounding Box" by simply "Selection" and add a tooltip
to the frame that says it's the bounding box.
Addressed Issue #1223.
(cherry picked from commit 33d2595d22)
Our plug-ins have no "optional" parameters per-se. Clarify the
description to make explicit that the last 4 parameters are simply only
taken into account when the shoot type is SHOOT-REGION.
(cherry picked from commit 3a0c03a61c)
Turn the boolean "root" argument into enum ShootType and reorder that
enum to { WINDOW, ROOT, REGION } so that the "0", and "1" values match
the former boolean. Adapt parameter checking accordingly so that
callers without optional arguments (e.g. script-fu) can call all the
plug-ins's features.
(cherry picked from commit d94b954c2a)
... with a color profile other than the gimp built-in.
When initializing the smude tool's accum buffer, use
gimp_pickable_get_pixel_at(), instead of
gimp_pickable_get_color_at(), for picking the initial color to fill
the buffer with, so that we don't erroneously apply the image's
color tranform to it when the image has a profile. Previously,
this would result in wrong colors when painting from the drawable
edges inward, with flow < 100%.
(cherry picked from commit 5a07876c78)
gimp_eek(): simply increase gimp->busy so XCF saving calling
gimp_set_busy() and gimp_unset_busy() won't call the GUI layer and do
whatever windowing system calls to set busy cursors.
(cherry picked from commit eaddef595e)
... with a color profile other than the gimp built-in.
Remove the separate alpha-channel copy in
gimp_image_color_profile_srgb_to_pixel(). We no longer need it,
since GimpColorTransform already takes care of that itself.
We used babl_process() to copy the alpha, which would also
transform the input color from R'G'B' to the output color space.
When the same buffer was used for both input and output, this call
would overwrite the input to the subsequent
gimp_color_transform_process_pixels() call; when the output color
space was different than R'G'B', this meant we'd pass the input to
gimp_color_transform_process_pixels() in the wrong color space,
producing wrong results. This was the case when converting the
foreground color for use with the smudge tool.
(cherry picked from commit e58e2ec5dc)
resize_dialog_new(): create the preview with "popup = TRUE", so we
really get a preview of layer size and not of the layer within the
image context like used for the layers dialog.
(cherry picked from commit 93d28ceccc)
when the GimpDeviceInfo already has a device. This is not a programming
error that should trigger a bug report popup, it's something else about
non-uniqueness of device names, or whatever. Simply g_printerr() a more
useful message that can help to debug this and bail out.
(cherry picked from commit f06d0485e6)
...after program restart
GimpContext was always supposed to keep the names of objects (brush,
pattern, font etc.) around even if these objects don't exist, for
cases like refreshing the data in a GimpDataFactory (which worked
fine), but also for deserializing the names of objects which don't
exist *yet* (delayed loading, no-data or whatever).
This commit fixes the delayed loading case (particularly affects fonts):
gimp_context_deserialize_property(): always keep the name of the
object around when it is not found, not only in the no-data case.
gimp_context_copy_property(): always copy the object *and* its name to
the dest context.
Add GimpConfig::duplicate() and ::copy() implementations which chain
up for duplicating/copying all properties and additionally copy all
object names to the new/dest context.
(cherry picked from commit ed1e2b1524)
It seems it was simply forgotten. PROP_MASK_ALL is used at some very
central places, so this commit might fix a few subtle bugs, or
introduce new ones, everybody look for strange tool preset behavior
please :)
(cherry picked from commit b3690b48d9)
Same as we did for binfmt-style lines, if the executable part (for
instance in `pygimp.interp`) is not an absolute path, let's allow
ourselves to find it in the environment $PATH.
Our configure test checks the presence of a Python2, but then uses
"python" as interpreter, which is a problem nowadays as the default
python is set to be Python 3 on some distributions (and this will be
more and more the case). So GIMP may end up trying to run our plug-ins
through Python 3 (which would fail) even if Python 2 is present.
Now AM_PATH_PYTHON2() m4 macro will set $PYTHON to a more accurate
Python version as priority.
Similarly let's use "python2" in the binfmt string for extension search.
So basically our binfmt set for Python simply never worked since we just
set 'python' and not a full path, but current code was not looking in
the $PATH environment. This was dead code. Now it's fixed.
Current code of gimp_interpreter_db_resolve() was only resolving the
interpreter by the file extension when the file could not be opened for
reading or if it was empty/coult not be read. This basically made this
test completely useless.
Let's fix this. Now it will be run all the time, but simply at the end,
if shebang and magic failed.
In GimpScaleTool, fix scaling around the center-point, and make
sure the width and height are always >= 1 when updating the
transformation in response to a widget change.
(cherry picked from commit 1516bfc14b)
Get rid of GimpTransformGridTool::recalc_matrix() and
gimp_transform_grid_tool_recalc_matrix(), and have
GimpTransformGridTool and its subclasses use
GimpTransformTool::recalc_matrix() and
gimp_transform_tool_recalc_matrix() directly instead.
In order to break the GimpToolWidget::changed/
GimpTransformTool::recalc_matrix() loop, add a
GimpTransformGridTool::update_widget() vfunc, which subclasses
should override to update their tool-widget (instead of doing this
in ::recalc_matrix()), and ::widget_changed(), which is called when
the tool-widget changes (and which subclasses should override
instead of connecting to the tool-widget's "changed" signal
directly.) GimpTransformGridTool calls these functions as
necessary, instead of relying on extra parameters passed to
recalc_matrix().
Adapt all the direct and indirect subclasses of
GimpTransformGridTool to the change.
(cherry picked from commit 6a3fc6c1b9)
As noted by Massimo, we can just make the argument of raw_input() an
optional argument.
Also adding a modal implementation for input() so that it doesn't lock
the Python console waiting from input from the plug-in stdin. As noted
in Python doc, input() is equivalent to `eval(raw_input(prompt))`.
Not all that safe, but in the end, it is the developer's responsibility.
... GIMP_TOOL_VERSION rather than hardcoding versions.
Mostly cherry picked from commit 276d9b60b3
except pkg-config still checks gtk+-2.0 (not 3.0) on gimp-2-10 branch.
In GimpTool, always clear tool->drawable upon halting, even for
tools that don't use it explicitly.
GimpTool sets tool->drawable in its default button_press()
implementation, and we potentially access it in
gimp_display_shell_initialize_tool(), so failing to clear it when
halting the tool may leave it as a dangling pointer, which can
result in a segfault when trying to initialize the tool in the
above function. In particular, this happens with the iscissors
tool.
(cherry picked from commit 58c96f596e)
In GimpCanvasTransformPreview, when the image mask is not empty,
make sure to align it with the drawable using a gegl:translate
node, before combining both at the gegl:opacity node. Otherwise,
the mask is applied at the wrong offset when the drawable's offset
is not (0, 0).
(cherry picked from commit d3a3c35317)
Make gimp_free_select_tool_halt() protected, and call it in
gimp_foreground_select_tool_set_trimap(), so that the free-select
subobject of the foreground-select tool is properly shut down
before switching to trimap mode. In particular, this clears the
free-select tool widget at the right point; failing to do this
leads to CRITICALs later on.
(cherry picked from commit e15733236c)
In GimpToolRectangle, call gimp_tool_rectangle_update_options()
when the "[xy][12]" properties change, so that the "x", "y",
"width", and "height" properties are updated accordingly.
In particular, we set these properties when committing an empty
rectangle select tool, to init the rectangle to the current
selection bounds, and this call is necessary so that the "x", "y",
"width", and "height" tool options are properly updated as well.
(cherry picked from commit 47b7e7be7d)
With the symbolic-awareness of GTK+, vector icons are recolored (using
fg, success, warning and error colors). Unfortunately it was also
recoloring some rectangles with neither fill nor stroke, which were
using only to get appropriate icon size (these icons were therefore
displayed as just a square).
I made a quick pass in our icons to "fix" these. I expect I may have
missed some icons, or at the opposite, I may have broken other icons by
removing rectangles which should not have been removed. If you find any
such icon, please fix.
Also some icons do not look quite right just now. We will have to create
new guidelines on how to make symbolic icons and fix/redesign some, I
guess.
(cherry picked from commit 0c3659c5f1)
The 2 major changes seem to be the much-awaited font loading in
background, and this new "Auto straighten" option on Measurement tool.
Please everyone, feel free to tweak the release description while it is
still commented out. Once we remove the comment tags, it will be
submitted for translation.
In gimp_image_set_colormap(), make sure the image's colormap always
has at least one color -- babl palette formats must have at least
one color.
If the function is called with 0 colors, use black. We still need
to support this case, in particular, since existing XCFs may have
an empty colormap, and since plug-ins can call
gimp-image-set-colormap with 0 colors.
(cherry picked from commit c16c68e63e)
Introduced in commit 032e95fad6, Makefile.am was apparently directly
edited instead of plugin-defs.pl. This also fixes a typo:
s/bust-dialog/busy-dialog/
(cherry picked from commit 4117c98655)
Set the libpng error_fn to NULL *after* png_read_end() not before.
png_read_end() can throw errors and we recover what's partially loaded
from an image in the error handler.
(cherry picked from commit db08271d16)
There is something broken in the obscure "text_column" and
"pixbuf_column" code in GtkIconView, and I don't have the nerve to
debug it.
Enable opening an image on activation (double click).
(cherry picked from commit 625aa514f6)
(picking the icon view change was not neccessary but this plug-in will
get more updates so let's keep the code in sync)
Last commit reintroduced this bug.
Allow transforming invisible layers using transform-grid tools, by
adding a 'drawable' member to GimpTransformTool, and setting/
clearing it when initializing/halting a GimpTransformTool. In
gimp_transform_tool_check_active_item(), skip the visibility check
if the active item equals the GimpTransformTool's 'drawable'
member.
(cherry picked from commit cea6f1dc73)
Split gimp_transform_tool_get_active_item() into two functions:
gimp_transform_tool_get_active_item(), which returns the item
without checking for errors, and
gimp_transform_tool_check_active_item(), which returns the active
item while checking for errors. Adapt the rest of the code to the
change.
Remove the invisible_layer_ok parameter of
gimp_transform_tool_check_active_item(), and always return an error
when the active layer is invisible. This causes the flip and
measure tools to correctly reject invisible layers. Un-hide the
active item in GimpTransformGridTool before transforming, to avoid
rejecting layers that were hidden by the tool.
(cherry picked from commit 360b25b9a8)
... and various other palette formats
Change accidental 'G_IS_INPUT_STREAM (file)' argument validation to
'G_IS_INPUT_STREAM (input)'.
(cherry picked from commit ea6d997e56)
Derive GimpMeasureTool from GimpTransformTool (and
GimpMeasureOptions from GimpTransformOptions), so that we can reuse
GimpTransformTool's logic for the "straighten" function. This
simplifies the code, aligns the measure tool with the rest of the
transform tools in terms of transform-related options (it can now
transform selections and paths, in addition to layers, and the
resampling method and clipping behavior are adjustable,) and fixes
straightening of layer groups.
Rename the function from "auto straighten" to just "straighten".
Don't resize the canvas after straightening. Since we only
transform the active layer, and not the entire image, resizing the
canvas doesn't make much sense.
When in 3-point mode, rotate the second point toward the third
point, rather than toward the x-axis.
(cherry picked from commit b0cf2e435a)
While most of our transform tools use an interactive transform
grid, and have similar behavior, the flip tool is an odd one out.
The new "auto straighten" function of the measure tool introduces
another tool that performs transformations, while not behaving like
the rest of the transform tools.
Factor out the parts of GimpTransformTool that handle user
interaction into GimpTransformGridTool (with corresponding
GimpTransformGridOptions, and GimpTransformGridToolUndo), and only
leave the basic transform functionality and options in
GimpTransformTool (and GimpTransformOptions).
Derive all the transform tools (and transform-tool base classes)
that previously derived from GimpTransformTool, from
GimpTransformGridTool. The one exception is GimpFlipTool, which
still derives from GimpTransformTool directly. The next commit
will derive GimpMeasureTool from GimpTransformTool as well.
Never return an internal image/buffer/svg/curve from any
gimp_clipboard function if we are not the owner of the display's
clipboard. The clipboard is supposed to be a global thing, and we must
only offer to ourselves what would be pasted in any other app.
(cherry picked from commit 7d3a129ddd)
Add GimpPaintTool::paint_[xy] members, and periodically assign the
paint core's current coords to them in
gimp_paint_tool_paint_timeout(), while the main thread and the
paint thread are synchronized, during painting.
In gimp_paint_tool_draw(), fetch the current coords for the brush
outline from the above members during painting, instead of directly
from the paint core, to avoid a race condition with the paint
thread, so that we always use the correct coordinates at the time
the paint buffer was flushed back to the drawable.
(cherry picked from commit 5c17d2a43b)
...won't work with older GIMP?
Make gimp_image_get_xcf_version() return a "reason" string which lists
all reasons why the image can't be saved with compatibility for older
GIMP versions. Display the reason as tooltip on the compat hint label
in the save dialog.
(cherry picked from commit a4061a6b0d)
When creating a layer group, or a text layer, use the image's
default new-layer mode, instead of always using (non-legacy)
NORMAL.
(cherry picked from commit 7c7b6eb537)
Instead just transform the measurement extremities appropriately to
still map to the same points.
To do so, I also added out parameters to gimp_image_resize_to_layers()
so that calling code can get offsets from old origin (as well as new
image dimensions).
(cherry picked from commit d56a8d439e)
In particular, this tool should not make huge rotation where the top
ends up in the bottom and it should not depend on whether we started the
measure tool from the left, right, bottom or top. This is fixed by using
atan() instead of atan2().
Also make a proper tooltip text. Help id is unneeded most likely though.
Finally do some cleaning and alignment.
(cherry picked from commit ba1d937dfb)
gegl:recursive-transform-plus is an extension of
gegl:recursive-transform, allowing multiple transformations to be
applied simultaneously; it will eventually be merged back into
gegl:recursive-transform. See GEGL commit
9829bc22e85526d789c4e80c05949d4c6202a207.
The GUI uses the new TRANSFORM_GRIDS controller, allowing adding,
duplicating, and removing transformations, and controlling them
through on-canvas transform grids.
(cherry picked from commit 99828a697a)
... which is similar to the TRANSFORM_GRID controller, supporting
multiple transformation matrices.
Implement the TRANSFORM_GRIDS controller in GimpFilterTool, using
the new GimpToolWidgetGroup to display multiple transform grids.
(cherry picked from commit 5e953ece85)
GimpToolWidgetGroup is a tool widget acting as a container for
child widgets, multiplexing widget events and demultiplexing tool
events. It can be used by tools to display multiple widgets
simultaneously.
The group keeps track of the current focus widget, and hover
widget. Certain events are only dispatched to/forwarded from these
widgets.
The hover widget is determined by performing a hit test for all the
children, starting from the last child. The first widget returning
GIMP_HIT_DIRECT, if any, is selected as the hover widget;
otherwise, if the current focus widget returns GIMP_HIT_INDIRECT,
it's selected; otherwise, if exactly one widget returns
GIMP_HIT_INDIRECT, it's selected; otherwise, there is no hover
widget.
The focus widget is set when clicking on a widget (or
programatically, using gimp_tool_widget_set_focus()).
Additionally, the group can raise the clicked widget to the top of
the stack (see gimp_tool_widget_group_set_auto_raise().)
(cherry picked from commit 4ef06b9922)
... which emits the "changed" signal, for use in subclasses to
notify the tool about widget changes not resulting from property
changes.
(cherry picked from commit 614cdcc0a8)
... which takes the same arguments as GimpToolWidget::hover(), and
performs a hit-test, returning one of the following values:
- GIMP_HIT_DIRECT: The point corresponds to one of the widget's
elements directly.
- GIMP_HIT_INDIRECT: The point does not correspond to one of the
widget's elements directly, but the widget otherwise responds
to press events at this point.
- GIMP_HIT_NONE: The widget does not respond to press events at
this point.
Unlike hover(), hit() should not have any side effects.
(cherry picked from commit 385203f4d6)
... by having them disable item highlights, and any other proximity
indication, when the cursor leaves the widget.
(cherry picked from commit 5e736c697f)
... which should be called on a widget when the cursor leaves the
widget, i.e., when it stops receiving hover events.
Have the default implementation clear the tool status.
(cherry picked from commit be7eff980e)
The next few commits are going to add support for using multiple
tool widgets simultaneously. As a first step, add a notion of a
focused tool widget, by adding gimp_tool_widget_{set,get}_focus(),
which tools/subclasses can use to control focus, and a
corresponding "focus-changed" signal, which tools/subclasses can
use to respond to focus changes.
(cherry picked from commit eeed9c413b)
specified by GimpDataLoaderEntry structs. Remove the same code from
GimpDataFactory and make it an abstract base class that only serves as
an interface for actual implementations. Also move around some stuff
in GimpDataFactory and remove virtual functions that were a bad idea
in the first place.
(cherry picked from commit 73da7c9a54)
When Control-Button2-Zooming, remember the start point, pass it to
gimp_display_shell_scale_drag() and force gimp_display_shell_scale()
to zoom around that point by passing GIMP_ZOOM_FOCUS_POINTER and
faking the point using gimp_display_shell_push_zoom_focus_pointer_pos().
(cherry picked from commit 792cd581a2)
so pull it to the parent class. Also remove the "no_data" parameter
from the data_init() virtual function and handle it in
gimp_font_factory_data_init() itself.
(cherry picked from commit d1b9f74c6f)
Sans-serif is also an actual font from the list and the standard font
is being used when there is really no font at all.
(cherry picked from commit 6b5fd27943)
Also, make sure we freeze() and thaw() the font container correctly,
so that all places keep their fonts across a refresh.
The only thing to make this actually work seems to be a bug in the
list views, grid views work perfectly.
(cherry picked from commit 1b1739bb06)
which contains all the font loading and refreshing including all async
stuff and is a complete replacement for gimp-fonts.c and GimpFontList.
(cherry picked from commit 0763ea2a69)
Virtualize a lot of functions and move their code into the default
implementation. Also connect to changes of the "path" property and
reload data automatically when the path changes. Add "wait" method
which is by default empty but is to be implemented by fonts.
(cherry picked from commit 01e4104236)
Make sure gimp_async_set_wait() and gimp_async_set_cancel() work
correctly, even if the set changes in nontrivial ways as a result
of waiting-on/canceling individual operations. This is purely
theoretic right now, but why not.
(cherry picked from commit ec5f4d03fa)
Increase the percision of the "position" property of
guides-new-percent.scm to two decimal places. Currently, it only
accepts integers, which limits its accuracy to 100px.
(cherry picked from commit 8e6a5298c1)
Add support for exponentiation (using the ^ operator) to eevl.
This is occasionally useful, e.g., in geometrically-derived
quantities involving square roots.
(cherry picked from commit 8d35299410)
This is mostly core code which we want to keep in sync with master as
long as possible, so I picked this one even though not strictly
neccessary.
(cherry picked from commit 1b7d63cce9)
When font loading is finished, restore the font list in the
corresponding async completion callback, and not in the
"notify::empty" signal handler of the fonts async set
This solves a problem arising when gimp_fonts_wait() is called
*inside* a "notify::empty" signal handler, emitted when reloading
fonts (causing the "empty" property of the fonts async set to
switch from TRUE to FALSE): When the wait is over, "empty" will
switch back from FALSE to TRUE, however, since the "notify" signal
is non-recursive, the corresponding handler will not be called,
gimp_fonts_wait() will return *before* the font list is restored,
and the caller will see an empty font list. This can happen under
certain circumstances when reloading fonts while the text tool is
active.
(cherry picked from commit 0e19f159f5)
... Windows.
Reviewer note (Jehan): I have not built on Windows because I need to
refresh my crossbuild environment, but it looks sane enough, and Gil
previously did good patches. I push as-is, hoping it still builds fine
on Windows. :-)
(cherry picked from commit 2caa400a96)
In the threshold and levels tools, use gimp_wait() to wait for
histogram calculation to complete before applying auto-adjustment,
so that a message is displayed in the meantime. Allow the
operation to be canceled, in which case we simply abort the auto-
adjustment, but let the histogram calculation continue.
Use gimp_fonts_wait(), added in the previous commit, to wait for
fonts to finish loading before operations that depend on font
availability. In particular, this includes font- and text-related
PDB functions, and text-layer rendering.
... which waits for font-loading to complete, using gimp_wait() to
show a message while waiting.
Note that we don't currently allow the wait to be canceled, since
it may have unpredictable effects on plug-ins, but the interface is
such that the wait might not complete, so calling code should be
prepared for that.
Add a GimpGui::wait() virtual function, and a corresponding
gimp_wait() function. The function takes an object implementing
the GimpWaitable interface, and a printf-style message, and waits
for the object to become ready, displaying the message as
indication in the meantime. The default implementation simply
prints the message to STDERR.
Implement the function in gui-vtable, using the busy-dialog plug-
in added in the previous commit, to display the message in a
dialog. Additionally, if the object implements the GimpCancelable
interface, provide a "cancel" button in the dialog, which, when
pressed, causes gimp_cancelable_cancel() to be called on the
object. Note that the function keeps waiting on the object even
after requesting cancelation; GimpTriviallyCancelableWaitable can
be used to stop the wait once cancelation has been requested.
This plug-in is used internally to show an interactive dialog in a
separate process, while the main process is blocking waiting for an
operation to complete. The dialog shows a custom message in a
GimpBusyBox, and potentially a "cancel" button, allowing the
operation to be canceled. Communication with the main process is
performed through a pair of file descriptors, passed to the plug-in
as arguments.
Pass the current icon theme directory to plug-ins through the
config message, and add a gimp_icon_theme_dir() libgimp function
for retrieving it. Note that we already have a similar
gimp_icon_get_theme_dir() PDB function, which we keep around, since
it can be used to dynamically query for the current icon dir,
unlike the former, and since it returns a dynamically-allocated
string, while the rest of the config-related functions return
statically allocated strings.
Use the new function, instead of gimp_get_icon_theme_dir(), in
gimp_ui_init(). This allows gimp_ui_init() to run without making
any PDB calls. Consequently, this allows us to start plug-ins that
call gimp_ui_init() without entering the main loop in the main app.
We're going to add a plug-in that displays an interactive dialog
while the main app is blocking waiting for an operation to
complete, and we need to be able to start the plug-in without
entering the main loop, to avoid the possibility of arbitrary code
being executed during the wait.
Bump the protocol version.
While fonts are loading, show a GimpBusyBox with an appropriate
message above the text tool options, and make the options
themselves insensitive, and in font views, such as in the fonts
dialog (through gimp_container_editor_bind_to_async_set(), added in
the previous commit).
... which takes a GimpAsyncSet and a message, and shows a
GimpBusyBox with that message, instead of the container view, while
the async set is nonempty.
We're going to use this for font-loading indication in font views,
such as in the fonts dialog.
GimpBusyBox is used to show a message indicating an operation is in
progress. It's basically just a spinner and a label, with some
styling.
We're going to use it both in app/ and in a plug-in.
We already avoid rendering text layers while fonts are loading,
showing an appropriate message, but this will soon be replaced with
waiting for the fonts to finish loading.
Instead, don't allow the text tool to start at all while the fonts
are loading (showing an appropriate tool message, and a BAD cursor
modifier), and halt the tool when reloading fonts if it's already
started.
Replace the boolean fonts_loading member of Gimp with
fonts_async_set, which is a GimpAsyncSet object. This allows us
to easily respond to the completion of font loading and reloading,
as will be done in the next commits.
Additionally, move the call to FcConfigSetCurrent(), used to
activate the loaded font configuration, from the async thread to
the main thread, just to be on the safe side, and avoid calling
FcInitReinitialize() in gimp_fonts_reset() if font loading is still
in progress, which is unsafe.
GimpAsyncSet represents a dynamic set of running GimpAsync objects.
The objects are automatically removed from the set once they're
synced.
GimpAsyncSet implements the GimpWaitable and GimpCancelable
interfaces, allowing the entire set to be waited-on or canceled.
Additionally, GimpAsyncSet provides an "empty" property, which
indicates whether the set is empty or not. This allows responding
to the completion of all the GimpAsync objects through the set's
"notify::empty" signal, or drive UI changes through property
bindings.
GimpTriviallyCancelableWaitable is a proxy object for another
GimpWaitable object, implementing both the GimpWaitable interface
and the GimpCancelable interface. While waiting on the proxy
simply waits on the underlying waitable, canceling the proxy
doesn't affect the underlying waitable, even if it implements
the GimpCancelable interface as well, but rather causes subsequent
wait operations on the proxy to successfully complete immediately.
This essentially causes cancelation to abort only the wait, rather
than the underlying operation.
GimpUncancelableWaitable is a simple proxy object for another
GimpWaitable object, implementing only the GimpWaitable interface.
Its main purpose is to mask away the cancelability of an object
implementing both GimpWaitable and GimpCancelable.
In gimp_parallel_run_async(), lower the priority of threads
executing independent async operations. Independent operations
are generally potentially long-standing background tasks, which we
don't want to bog down the rest of the program.
This is currently only implemented on Linux and Windows.
The GIMP version string and the backtrace both look completely wrong
when pasted as-is on gitlab. Somehow all linefeed are gone.
This can be fixed by surrounding these as blocks (triple backticks),
using markdown syntax. Of course now the debug content is not for our
tracker only since packagers are encouraged to replace with their own
tracker URL, but this small markdown syntax is simple enough that it
should not break formatting on other platforms (as far as I know).
(cherry picked from commit d4ff504735)
In gimp_parallel_run_async(), when aborting a GimpAsync operation
in reponse to its "cancel" signal, properly clean up internal data
attached to the object, to avoid use-after-free if the signal is
emitted again.
(cherry picked from commit 3fa4c01bcf)
Add a boolean "independent" parameter to gimp_parallel_run_async().
When FALSE, the passed function is run in the shared async thread
pool; when TRUE, the passed function is run in an independent
thread.
Generally, async operations should run in the async pool, however,
it might be desirable to run long-standing operations, especially
ones that can't be canceled, in independent threads. This avoids
stalling quicker operations, and shutdown.
Adapt the rest of the code for the change. In particular,
initialize the font cache in an independent thread.
(cherry picked from commit ad8add6808)
In gimp_parallel_run_async(), connect to the returned GimpAsync's
"cancel" signal, and abort the operation in response if it's still
enqueued, i.e., if its execution hasn't started yet.
(cherry picked from commit 3958ffbe50)
Have GimpAsync implement the GimpWaitable and GimpCancelable
interfaces, added in the previous two commits, instead of providing
its own public version of the corresponding functions.
Add gimp_async_cancel_and_wait() as a convenience function for both
canceling an async operation, and waiting for it to complete.
Adapt the rest of the code to the change.
(cherry picked from commit e2c56ef407)
The code was basically leaking memory everywhere, and apparently on
purpose (according to a top comment). Even on short-lived process, not
properly managing memory is not a good habit, especially if we plan to
maintain a program for the long run.
So here are some fixes. I'm sure I must have missed some places (code
was a mess), and hopefully I broke nothing. But that's good for now. At
least it is somewhat sane code now.
(cherry picked from commit f3de5cd3fe)
Since commit 58fa382001, gimptool would accept source files with
non-standard extensions when using known C or C++ compilers. This would
include source with no extensions at all.
When this happens, do not try to set a pointer to a non-existing dot
separator to '\0'. That obviously segfaults.
(cherry picked from commit 02fc818bf6)
Unlike the last two commits, we don't port GimpConfig to
G_DEFINE_INTERFACE(), since we need to provide a base initializer
for it. However, this commit aligns it with the rest of our
intefaces, by renaming gimp_config_interface_get_type() to
gimp_config_get_type(), and by performing class initialization for
the interface in a separate function than base initialization.
Keep gimp_config_interface_get_type() around as a deprecated
function, to maintain ABI compatibility. It will be removed in a
separate commit in master, so that this commit can be easily
cherry-picked to gimp-2-10.
(cherry picked from commit 5f8643a6ee)
... instead of calling g_type_register_static() ourselves.
Keep the old foo_interface_get_type() (replaced with
foo_get_type()) around as deprecated functions, to maintain ABI
compatibility. They will be removed in a separate commit in
master, so that this commit can be easily cherry-picked to
gimp-2-10.
(cherry picked from commit 6b40c7f37a)
Fonts should not be blocking startup as this provides a very bad
experience when people have a lot of fonts. This was experienced even
more on Windows where loading time are often excessively long.
We were already running font loading in a thread, yet were still
blocking startup (thread was only so that the loading status GUI could
get updated as a feedback). Now we will only start loading and proceed
directly to next steps.
While fonts are not loaded, the text tool will not be usable, yet all
other activities can be performed.
(cherry picked from commit 2484dec7d5)
Improve the formalism of a GimpAsync object being "sycned"
(previously referred to as the main thread being "synced" with the
async thread), by both providing a gimp_async_is_synced() function,
separate from gimp_async_is_stopped(), and by improving the type
and function descriptions.
Make sure all previously added callbacks have been called after a
call to gimp_async_wait[_until](), even if these functions are
called from within a callback.
(cherry picked from commit a901c3c1f4)
Replace the custom threading code with a call to
gimp_parallel_run_async(). This simplifies the code, while
maintaining the current (blocking) behavior. In the future, we
might build upon this to actually load the fonts in the background.
(cherry picked from commit 3e92e7a449)
... which is similar to gimp_async_wait(), taking an 'end_time'
parameter, controlling how long to wait for the async operation to
complete.
(cherry picked from commit 68c57548fd)
The default stack size for new threads on MacOS is 512 KiB, making
our 512 KiB limit for stack-allocated buffers in
gimp_operation_layer_mode_real_process() too high. Lower it to
256 KiB.
(cherry picked from commit 367399e5c0)
In gimp_drawable_gradient(), pass the undo description ("Gradient")
to gimp_gegl_apply_operation(), so that its displayed as the
progress text while rendering the gradient, even when applying a
shaped gradient, in which case we end the progress after
calculating the distance map, causing the progress text be NULL
during rendering unless explicitly set.
(cherry picked from commit deee2f14f5)
... which is a drop-in replacement for gegl_buffer_copy(),
parallelizing the copy operation when the source and destination
formats are different, requiring a conversion.
(cherry picked from commit fded25b38c)
and remove all clipping hacks for drawing the canvas background, turns
out they never worked and we were relying on the pattern set on the
window, gah! This optimizes away one entire step of drawing of image
size, for each expose...
"magnification-api-win32.h" was not included in the dist!
Note that I know that alphabetical order is wrong. I am planning to
actually change the name of the file (more in line with other filenames)
but I am waiting to finish a review of another patch from Gil before
doing so. So just let it as-is for now! ;-)
* You should have received a copy of the GNU General Public License
* along with this program. If not, see <http://www.gnu.org/licenses/>.
* along with this program. If not, see <https://www.gnu.org/licenses/>.
*/
#ifndef __FONTS_ACTIONS_H__
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
