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.
(cherry picked from commit 90ed3c8d3a)
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.
(cherry picked from commit 8f21c9483a)
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.
(cherry picked from commit 87a9feb6d9)
... 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.
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.
That's the problem of having alternative build options! My previous
commits were made when testing the build with PNG icons.
Anyway I am planning to soon merge the 2 options.
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.
(cherry picked from commit 55a7872e1b)
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.
(cherry picked from commit 8ec5f44f2f)
We don't need to commit PNG symbolic icons as `gtk-encode-symbolic-svg`
is perfectly able to generate them from the SVG.
Moreover its man says that it makes "specially prepared png files",
whatever that means. So I don't think we should just rename our
self-exported PNG files as '*-symbolic.symbolic.png'. It is better to
generate them with this tool.
Note that I am now splitting icon-list.mk into 2 files. This is only a
temporary stepback, as I am actually going to merge the 2 icon themes
into one very soon, and hopefully we should be able to generate the list
to ensure we don't miss an icon.
Anyway the icon lists had already diverged earlier, even though it was
only all still in a single file.
A single icon theme can contain both regular and symbolic icons. Let's
give possibility to switch from one style to the other within GIMP
Preferences.
This won't work very well in all cases yet, especially if an icon theme
only has symbolic icons (and no regular ones) because of inconsistencies
in glib which are being fixed (patches which I submitted and which were
merged in glib on 2018-08-17).
So this will work as expected when we will bump our glib requirement to
whatever is the next release.
If we enable the console on Windows, we might as well open it as fast as
possible, since its purpose is debugging.
(cherry picked from commit c9d7618056)
... 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).
(cherry picked from commit 91c139f4d0)
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).
(cherry picked from commit 1a28878943)
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.
(cherry picked from commit c49afa4f84)
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.
(cherry picked from commit d1d9eb17e5)
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
(cherry picked from commit 0865e9db1f)
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.
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.
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.
Ell