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)
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)
...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)
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)
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)
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)
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)
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)
... 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)
...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)
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)
After Alexandre Prokoudine's insistent demand! :-)
I am still not sure how wise this is, since this should be really
considered a "developer-only" option. Basically these tools are really
too buggy and unstable and we should not shine too much light on these.
The counter-argument is that doing so will favor the bitrot.
Well ok. At least let's add a big warning message at the top of the
Playground page, to make it very clear (if that were not already the
case) that basically this is not to be considered a secret feature, but
really more a "we are looking for contributors" option.
Add GimpGuiConfig::filter-tool-use-last-settings wchich defaults to FALSE.
Honor the new option in gimp_gegl_procedure_execute_async() and add
it to prefs -> dialog defaults.
A hidden feature of the action search dialog, is that actions can
be matched based on their label's initials. E.g., "gb" will match
"Gaussian blur". While very convenient, this feature is currently
limited to two-letter initialisms.
Extend initialism-based search, by matching arbitrarily-long
initialisms, and by allowing partial matches (with lesser
priority.)
... and rename gimp_action_history_excluded_action() to
gimp_action_history_is_excluded_action().
is_blacklisted_action() determines whether an action should be
excluded from *both* the history and the search results, while
is_excluded_action() determines if an action should be excluded
only from the history. This eliminates some redundancy across
gimpaction-history and action-search-dialog.
... g_find_program_in_path() instead of a test run.
I knew there was a `which` equivalency in glib but could no find it
anymore. I finally found it thanks to a comment by Rishi. :-)
which is just a #define to g_assert for now, but can now easily be
turned into something that does some nicer debugging using our new
stack trace infrastructure. This commit also reverts all constructed()
functions to use assert again.
If the backtrace() API is available, it should always be possible to
debug. Still, display a message whether or not gdb or lldb are present,
as preferred debugging solutions (much better traces).
Replacing the boolean property "generate-backtrace" by an enum
"debug-policy". This property allows one to choose whether to debug
WARNING, CRITICAL and FATAL (crashes), or CRITICAL and FATAL only, or
only FATAL, or finally nothing.
By default, a stable release will debug CRITICAL and crashes, and
unstable builds will start debugging at WARNINGs.
The reason for the settings is that if you stumble upon a reccurring bug
in your workflow (and this bug is not major enough for data corruption,
and "you can live with it"), you still have to wait for a new release.
At some point, you may want to disable getting a debug dialog, at least
temporarily. Oppositely, even when using a stable build, you may want to
obtain debug info for lesser issues, even WARNINGs, if you wish to help
the GIMP project.
It can be argued though whether the value GIMP_DEBUG_POLICY_NEVER is
really useful. There is nothing to gain from refusing debugging info
when the software crashed anyway. But I could still imagine that someone
is not interested in helping at all. It's sad but not like we are going
to force people to report. Let's just allow disabling the whole
debugging system.
