This port made clear that it is almost impossible to
do the langs patching with PowerShell alone.
The new output of the patching will display the encoding.
Previously, the Help button triggered the default dialog close behavior, without showing any help.
This change ensures that pressing Help triggers the expected help function.
Reverts dc21fb76
The CodeView format introduces some advantages to our Windows build:
- It is way smaller than DWARF, reducing the .exe installer. With
the strip of COFF symbols too, the installation is 120MB smaller.
- Can be uploaded as .appxsym to be used on demand by MSIX (in thesis)
- Works better with DIA and DbgHelp debuggers like WinDbg and DrMingW,
respectively. LLDB also works by using LLDB_USE_NATIVE_PDB_READER=1
Context: that was not working before because DrMingw and LLDB seems to
only search for the build-time .pdb path in '.buildid' section of bins.
See: https://github.com/jrfonseca/drmingw/issues/91 and
https://github.com/llvm/llvm-project/issues/125355. So, we will set
_NT_SYMBOL_PATH at least for $PREFIX/bin for now as workaround.
The Smudge Tool gets accumulated buffers from its
history via g_list_nth_data (). However, this function can
return NULL if we go out of bounds. We did not check for
this before trying to use it as a GeglBuffer, which caused
crashes if we ran out of accumulated buffers (e.g. if we
were partially smudging off-canvas).
This patch adds NULL checks to prevent the crashes.
...before trying to get its GimpColorConfig.
Resolves#13691
After the color space invasion, various GimpCanvas
functions are now aware of color management settings.
However, these public GimpCanvas functions do not
require the user to pass in a GimpCanvas, just a GtkWidget.
This can lead to crashes if we pass in a different kind of
GtkWidget, since it may not have a GimpColorConfig property.
One example is the Navigation Dockable, which crashes when
it tries to draw boundaries around the image when "Show All"
is turned on, because it passes a GimpView widget instead of
a GimpCanvas.
This patch adds a check if the "canvas" parameter is actually a
GimpCanvas, and sets the config to NULL otherwise.
With grave on heart I am dropping crosbuilds. Always liked them but
actually our crossbuids on Debian are flawed on either GCC or Clang
(with linking either to UCRT or MSVCRT, I tested all possibilities).
The main problem is that Debian does not provide the runtime deps
(unlike Fedora) so we use from MSYS2. This fact tends to cause:
- Linking problems due to undefined references on compiler: #11756
- Clash between Windows runtime and Linux build-time deps: #12970
Worst, these bugs historically are rarely spotted or fixed at all.
Some of them took weeks and even months(!) to be reported by us and,
in the end, there is only one or two guys to do this: me and Jehan.
I do rather prefer to improve native builds than spending more and
more time on fixing crossbuilds without effectively using them.
Resolves#11552
We did not explicitly define the colors for the Minimize,
Maximize, and Close button icons for merged titlebars.
On some system themes, the color used blends into
the titlebar and makes the icon look invisible.
This patch makes sure we always define the icon color
for the Default theme.
Resolves#13633 (for now)
Same rationale as 975d1a4a, as diagnosed by Thomas Manni.
During 3.2 development, we can review and likely just set this as
the default value inside GimpDrawable.
For now, this is a limited bugfix for 3.0.x.
Following eab5e061
This avoids curious users cheating the mode to make multiple installs, which
is unsupported by us since we only allow for different mutexes. See: #1382
It looks like packagers have regular issues with this support. Also I
added info about the fact we also support JPEG2000-in-HEIF (HEJ2) now.
And I made clearer that there may be other encoders/decoders possible
for a given format (though for AV1, we have a clear AOM preference in
our code).
Finally I add info about an environment variable which may be useful
probably in cases when the run prefix differs from the build prefix.
Cf. a case which was recently happening in the Snap package.
See: https://github.com/snapcrafters/gimp/issues/390
The Force option does not affect the Pencil Tool's painting.
While Force is already set to be insensitive, hiding the
option entirely makes it even clearer that it can not
be used with this tool.
for generated brushes.
The maximum radius we allowed for generated brushes was not used
consistently everywhere.
In the API call we clamped it to 0.0-32767.0, while the param_spec
set min and max to 0.1 and 4000.0, and the brush editor used a
maximum of 1000.0.
Using a large value (probably anything larger than 4000) would
sooner or later lead to a crash.
Instead of manual changes everywhere, let's define a maximum and
minimum in one place and use that wherever we need the min/max values.
Use the values as set in the param_spec for the defines.
The only place we can't easily do that is in brush.pdb, so we add
a comment above our defines that the values need updating there too.
Actually we should probably use more defines for other values too,
that way there is less chance of min/max values getting out of synch
throughout our code.
This makes a bit more clear changes introduced by:
itInstall, itReinstall, itUpdate: cbe2f6bec2
itRepair: eab5e0615d
itDowngrade: e447b1244b
Unninstall (settings): b6069baa04
Unninstall (restore): 22e3ae24c7
Relocatable builds do not need them.
Also, remove comments about the inspiration for the scripts since
they are now so refined that make no sense to link 3P sources.
Bruno Lopes