gegl:recursive-transform applies a transformation recursively to
an image. The custom GUI allows controlling the transformation
matrix using a transform-grid controller, added in the previous
commit.
... which allows ops to create a transform-grid widget, similar to
the unified-transform tool, which can be used to control a
transformation matrix.
Implement the transform-grid controller in GimpFilterTool.
Since the entry behaves differently based on whether the user
provided an explicit input or not, it makes sense to have a button
for clearing the entry.
The bug is very hard to reproduce, probably because it requires specific
timing conditions but this looks like this commit would prevent it.
Apparently the signal handler gimp_container_view_name_changed() may
have been run while the container view (set as user data) was most
likely already finalized, hence leaving an invalid dangling pointer.
Let's just make sure we disconnect this handler (and another) when we
finalize the container view and its private data.
In a previous commit, I bumped it for Windows only, where major bugs had
been fixed in recent fontconfig. Yet as Mitch notes, Debian testing has
Fontconfig 2.12.6, so we can simply use the same requirement on all
platforms. No need to make our configuration script over-complicated
with per-platform requirements here.
... current aspect ratio
In gimp_{rectangle_select,crop}_tool_start(), move
GimpToolRectangle signal connection to the end of the function. In
particular, connect the signals *after* the call to
gimp_{rectangle_select,crop}_tool_update_option_defaults(), since
it may result in an emission of a "change-complete" signal, whose
handler calls the function again with ignore_pending == FALSE, which
would override the ratio set with ignore_pending == TRUE.
... when focus is lost/enter is pressed
When a GimpNumberPairEntry loses focus, or when enter is pressed,
set its user-override property by calling
gimp_number_pair_entry_set_user_override(), instead of setting the
corresponding member directly, so that the entry's font is updated
correctly.
Fontconfig has a new slowness issue, this time apparently because of
locked cache files, preventing a successful cache update.
See: https://bugs.freedesktop.org/show_bug.cgi?id=99360
Furthermore the slowness apparently happens at every GIMP startup, and
also even when GIMP closes according to various reports. So let's bump
Fontconfig version (for Win32 builds only).
Also let's not make it a recommendation anymore, but a requirement. That
makes quite a few Win32-specific fontconfig bugs which have been fixed,
and most are quite serious so this should not be considered as optional
anymore, I guess.
... from first monitor
While researching the cause for the missing window contents (bug
793722), I noticed that the full screen capture mode was also not
working as expected. No matter how many monitors were connected, it only
ever captured the contents of the main monitor. This patch adjusts the
source rectangle for the BitBlt copy operation so that multiple monitors
are captured correctly.
"gimp-detach" does not just use "gtk-convert" anymore and has its own
design. As for "gimp-attach", this is not used anywhere (yet), but it
could be soon as reverse action of gimp-detach. For instance, this icon
can be used for bug 791859 when we implement re-attaching overlay
dialogs.
These are simple on purpose since the smaller size they are displayed at
is 12 px (in overlay dialogs) so it needs to be simple shapes.
Note by Jehan: gimpicons.h and Makefile.am not updated yet. Waiting for
the color icons first.
... thewindow is IE 11.
The screenshot plugin for windows had a problem when capturing
applications that use hardware rendering acceleration (e.g.
Chromium-based Apps, IE11). Those applications seem to render their
content to a device context (DC) that is different from the one that can
be retrieved via GetDCEx(hWnd). So a screenshot that simply copies the
main window DC will be incomplete (see bug attachment) or just plain
black.
This patch removes the code that uses GetDCEx for single window
screenshots and always uses the display device context instead. This
makes sure that all window contents are actually visible in the
screenshot. With this change, we now have to set the source coordinates
in the call to BitBlt() to the window's coordinates to exclude
everything that isn't the window from the screenshot when doing a single
window screenshot.
Review comment by Jehan: as Simon notes in bug 793722, there is a
regression though, which is that this new code cannot capture any part
of a window which is not in any screen. This is still an improvement
because at least for what is on screen, we always get exactly the same
as what is displayed. This is especially true since hardware-accelerated
applications are more and more common. So let's push this first commit
and hope for further improvements.
It seems that older GDB (under version 7) are not handling very well
some common debug information format, in particular DWARF > 3. Such
version of GDB is usually not a problem since it is quite old (more than
10 years old, it would seem) so you don't see it anymore on any modern
GNU/Linux distribution. On FreeBSD on the other hand, it is still
available (probably for license reasons) and even installed by default!
As a consequence, it makes debugging fail, even though LLDB is also
installed by default.
That is even more of a problem because it would seem that GIMP is killed
(most likely by FreeBSD kernel according to the reporter tests) as a
side-effect of GDB failing, which is seriously bad, in particular since
we also use the debug dialog for non-fatal errors (which could therefore
end up killing GIMP as side effect of a bad GDB!).
So I add some GDB version check. I implement this without any dynamic
memory management, as usual, since this needs to happen also during
crash handling where the state is unstable and prone to memory
allocation failure.
I also add gimp_utils_backtrace_available() public API which can be used
by the Preferences.
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.
Anders Jonsson