It was reported that several brushes added in 1998 may have problematic
copyright with unclear/unknown licensing. And basically nobody knows
anymore where these actually come from, with which authorship or origin,
at least not for sure. It is even possible some come from commercial
software. So let's at least get rid of the ones where the origin is the
most doubtful.
Thanks to Americo for discovering these issues.
Having to sync the "valid" flag with the presence of a histogram is
error-prone (cf. previous commit).
Instead gimp_histogram_editor_validate() return value will just depend
on the presence of the histogram. And "valid" becomes "recompute", i.e.
a flag to request for "recomputation" of the histogram.
When the histogram is freed, we need to set valid to FALSE, in order to
force recreation as soon as needed. Otherwise we may hit some race
condition of trying to work with a NULL histogram. For instance this
happened when starting painting fast enough after switching the active
image.
I had to shuffle a bit the order of initialization since we were
creating a folder for the crash logs, as well as one for the backups a
bit too early. So now I move errors_init() after configuration folder
creation/migration, and I create both these folders in this function
(especially since gimp_init_signal_handlers() is run even earlier).
For this later reason, I also check for backtrace_file and backup_path
being allocated in gimp_eek() since it is also possible for signals
happening before errors_init(). In such a case, we will simply bypass
the GUI error handler (terminal error handler still possible) and the
backup (anyway there is nothing to backup at this point).
I could also try to create these 2 directories at the last second, when
needed. But since we are trying to do the strict minimum during crash
handling, it is better to do whatever can be done earlier.
Don't choke when calling gimp_tool_rectangle_set_constraint() while
there's no active image, or while the active image has no active
layer, which can happen when updating the default aspect ratio of
the crop tool. This would previously result in CRITICALs.
Additionally, use weak pointers for the crop tool's current_image
and current_layer members, to avoid potential dangling pointers.
While not currently necessary, this makes the code less dependent
on the exact order of events.
The current sorting logic of actions in the history is essentially
linear, so that when an action is activated it moves up one place
in the history. This has the undesirable effect that actions take
very long to climb up the history list, as well as that actions at
the top of the list can change their relative order too frequently.
Improve the sorting logic, such that items climb up the list
faster, while top items retain their relative position longer. See
the comment at the top of the diff for the actual logic.
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.)
The undo/redo actions' label changes based on context, and may
interfere with the labels of more relevant, but less frequent,
actions.
For example, after applying filter Foo, the label of edit-undo
becomes "Undo Foo", so searching for "Foo" results in both
edit-undo, and the action referring to the filter, with edit-undo
most likely appearing at the top of the list due to its frequency.
Excluding the undo/redo actions from the history is a simple, if
suboptimal, way to fix this.
... 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.
... current aspect ratio
When updating the default aspect ratio of a widget-less crop tool,
construct a temporary GimpToolRectangle widget, so that we can use
it to call gimp_tool_rectangle_constraint_size_set() and pick the
correct ratio, instead of just bailing.
When halting the crop tool, update the default aspect ratio, which
now does the right thing, as per the above.
Update the default aspect ratio upon changes to the active layer of
the current image, and to the size of the active layer, which
affect the default aspect ratio when "current layer only" is
toggled.
... current aspect ratio
When starting the rectangle-select (and ellipse-select) tools,
properly reset their default aspect ratio to 1:1. This fixes an
issue where the tool would use the aspect ratio of the last
rectangle when there's no user-overriden aspect ratio specified.
This restores the 2.8 behavior, except for the fact that the aspect
ratio resets to 1:1 when the tool is commited (if there's no user-
overriden ratio), rather than keeping the aspect ratio of the last
rectangle (i.e. "Current"); in 2.8 this only happend when halting.
The current behavior seems more consistent anyway.
Set the scale of the GimpRectangleOptions highlight-opacity
spinscale to 100, so that the spinscale's range is 0-100, instead
of 0-1, like the rest of our opacity spinscales.
gegl:color-to-alpha-plus was merged back to gegl:color-to-alpha in
GEGL, so we can change the custom propgui constructor to refer to
gegl:color-to-alpha.
Remove the threshold-range compression toggle and logic, since the
corresponding property was removed in GEGL.
Revert commit 24fcabc1ca, which
allowed passing a NULL buffer to gimp_drawable_set_buffer[_full](),
leaving the drawable without a buffer in a semi-functional state --
this is too risky.
Instead, have gimp_drawable_steal_buffer() assign an empty 1x1
buffer to the stolen-from drawable, rather than leaving it without
a buffer at all.
... 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. :-)
Remove the impromptu boundary invalidation when converting a
channel to a selection mask in xcf_load_channel_props(), as this
happens implicitly when stealing the channel's buffer, since
commit 38d4aa8121.
When constructing a text layer from an existing layer in
gimp_text_layer_from_layer(), steal the old layer's buffer using
the new gimp_drawable_steal_buffer(), instead of using simple
pointer assignment, as the latter is generaly unsafe (even though
it should currently work).
Since commit d0ae244fe8, which
connects GimpChannel instances to their buffer's "changed" signal,
the XCF loading code that steals a channel's buffer when converting
it to a selection mask (which happens when loading an XCF with a
saved selection mask) is unsafe, since fails to perform the
necessary cleanup and setup of the buffer in the old and new
channel objects, respectively.
Perform the buffer transfer using the new
gimp_drawable_steal_buffer(), which does the same thing in a safe
manner.
... which transfers a buffer from one drawable to another in a safe
manner, leaving the source drawable empty.
There are already two ad-hoc instances where we steal a drawable's
buffer through simple pointer assignment, however, this avoids
performing potentially necessary cleanup and setup. In particular,
since commit d0ae244fe8 this causes
actual errors. The next two commits replace those instances with
calls to gimp_drawable_steal_buffer().
... which clears the drawable's buffer, performing any necessary
cleanup, without setting a new buffer. While the drawable has no
buffer, it can only be used in a very limited way, in particular,
it may be destroyed, and it may be assigned a new buffer.
This is used by the next commit to implement
gimp_drawable_steal_buffer(), which transfers a buffer from one
drawable to another in a safe manner, leaving the source drawable
empty.
Current code was redirecting WARNING and CRITICAL errors to normal
messaging when the debugging was deactivated (in Preferences). But if
you deactivate these on purpose, then it means you don't want to get
annoyed by small pop-ups either.
This commit makes them directly displayed in terminal, as they used to
before, when debugging is deactivated.
Current phrasing seemed to imply that you could chose another format
than XCF to *save* your work-in-progress image. Reword a bit to make
obvious that "saving" is always done with XCF. Other formats are for
exporting.
As previously explained, this was the next and logical step after
debugging. At the very end, just before exiting the process, let's
attempt to save all unsaved (i.e. "dirty") images. Of course we try to
do so as backup files in the config directory (once again, this would
be better under $XDG_CACHE_HOME/GIMP/ though) because we must not touch
the originals.
Currently we only have some automatic saving, but we don't warn yet that
backups were made. Also we don't keep track of the original paths for
later recovery hints. Proposed recovery would be worth being done at
next start of GIMP when we detect files in the backup directory (with a
typical "What should we do with these?" dialog).
Also it is to be noted that it is not a 100%-sure system. While testing
various test cases, I had many cases where the images were successfully
saved, but others when the backup failed (in particular when playing
with double freeing). I'm not sure if this is because of some memory
allocation during XCF saving or some other issue which could be improved
later (hopefully).
... on perceptual gamma image
When constructing the paint core's paint buffer, in GimpBrushCore
and GimpInk, use the drawable's format as the preferred format in
the call to gimp_layer_mode_get_format(), instead of NULL.
Subsequently, use the paint buffer's format, instead of the source
buffer's format, as the preferred iterator format in
do_layer_blend(), since the iterator format must match the paint
buffer format.
It seems gegl_buffer_sample() crashes with the first parameter being
NULL so let's just test its value first. This will output a huge
quantity of CRITICALs in this edge case but that's much better than a
crash. :-)
See also bug 793371 where this bug is being processed.
When checking the Cage Transform operation code, I saw some ifdef meant
to be switched to when bug 645810 is fixed. It also says in a comment:
> /* When Gegl bug #645810 will be solved,
> this should be a good optimisation */
Checking said bug, it appears it has been fixed since 2012!
I also fixed a bit the parameters in gegl_buffer_sample() call since it
seems the function signature has changed quite a bit.
The Win32 build was not taking the new path of git-version.h into
account and was outputting these errors:
> ../build/windows/gimp.rc:2:10: fatal error: git-version.h: No such file or directory
> #include "git-version.h"
> ^~~~~~~~~~~~~~~
Since a few commits, I don't generate the traces anymore in errors.c but
delay this to gui-message.c and rely on the message severity to decide
whether or not generating traces.
Unfortunately none of the current severities are properly describing
this new type of messages. Even GIMP_MESSAGE_ERROR is used everywhere in
our code NOT for actual programming bug, but often for data errors
(which are not bugs but proper messages and should obviously not prompt
a debug trace).
This reverts commit 94c6bb4603, because
unlike what the bug title suggests, Smudge apparently *should* use
perceptual RGB, so now everything works as before.
