It now supports all GParamSpecs possible on the wire protocol, except
the ones that are implemented in app/ and libgimp/ (image, drawable,
...) and are not visible to libgimpconfig
Bug discovered by Simon. See #3921.
The logics of the whole test for binding interpreters may still change
(or even disappear), but for now, at least make it work as expected.
Add a new mnemonic-clashes tool, which checks for mnemonic clashes
in menus. This tool can be invoked directly from the shell. It
takes an optional parameter which limits the search to a specific
type of menus, according to their xml tag (in particular, "menu"
for regular menus, and "popup" for popup menus).
Don't drop references we do not own. Turns out bindings can have
things referenced even after all procedure code has returned. Keep the
old code there in #if 0 and keep the debug warning for now, maybe we
can do something generic about this.
Align plug-ins/common/meson.build with plugin-defs.pl, avoiding
building optional plug-ins whose dependencies aren't met.
Fix the build condition of the mail plug-in.
and in an attack of madness, changes almost all file plug-in
code to use GFile instead of filenames, which means passing
the GFile down to the bottom and get its filename at the very
end where it's actually needed.
Which means support for GParamSpecObject with value_type ==
G_TYPE_FILE, and converting between GFile and its URI for wire
communication directly above the protocol layer.
This change requires passing a GParamSpec's value type as generic
member of GPParamDef, which in turn makes some members of its
sub-structures obsolete.
jpeg-save.c:56: warning: "DEFAULT_QUALITY" redefined
56 | #define DEFAULT_QUALITY 90.0
|
In file included from C:/msys64/mingw64/x86_64-w64-mingw32/include/windows.h:71,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/rpc.h:16,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/objbase.h:7,
from C:/msys64/mingw64/x86_64-w64-mingw32/include/shlwapi.h:16,
from C:/msys64/mingw64/include/jmorecfg.h:19,
from C:/msys64/mingw64/include/jpeglib.h:31,
from jpeg-save.c:33:
C:/msys64/mingw64/x86_64-w64-mingw32/include/wingdi.h:1140: note: this is the location of the previous definition
1140 | #define DEFAULT_QUALITY 0
In GimpDisplayShell, scale the render cache by the window's scale
factor, and render its content in device pixels, instead of scaled
application pixels. When painting the cache to the screen, unscale
the cairo context by the same factor, so that it's painted in the
native resolution. Note that the various
gimp_display_shell_render_foo() functions still speak in
application pixels, and the scaling happens internally in
gimp_display_shell_render().
Aside from rendering at native resolution on HiDPI, this also fixes
an issue where grid-like display artifacts would appear when the
render cache was not fully validated due to the non-native scaling.
We should not rely on the current working directory, as it looks like
meson sets it to be the source directory (even when actually in the
build dir) when running custom target (so it fails).
Instead meson explicitly sets MESON_SOURCE_ROOT and MESON_BUILD_ROOT
environment variables for us. We should use these. This should work in
every cases (whether calling from the source or build dir).
Also removing the special-casing for a _build/ directory. This updated
version is generic and won't assume that you used some generic naming or
direct subdir under the source (even if many people might use this path
and name; I, for one, certainly don't!).
See: https://mesonbuild.com/Run-targets.html
It's an ancient concept from ancient times when we didn't have URIs
and only filenames (not to speak of GFile), and actually even from
before the ancient time before that ancient time when we first had
ones and zeros, and only had zeros.
gimp_plug_in_manager_add_to_db() used to call the PDB in order
to properly register file procedures from pluginrc. This broke
when I moved code to gimpplugin-file.c.
Instead, add gimp_plug_in_manager_add_load_procedure() and
gimp_plug_in_manager_add_save_procedure() and call them from both
gimpplugin-file.c and gimp_plug_in_manager_add_to_db(), which also has
the nice side effect that more GimpFileProcedureGroup logic gets moved
to its place in gimppluginmanager-file.c and less magic is needed in
gimpplugin-file.c.
Michael Natterer