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.
They are simply setting properties on GimpPlugInProcedures, just like
the other functions in gimpplugin-proc.[ch], so there is no reason to
have them elsewhere and with worse checks and error messages.
Mention and guarantee the order of procedure registration (see
previous thumbnail loader commit). Remove duplicate docs from the
GimpPlugIn class comments that are needed for introspection, it's too
cumbersome to keep two identical texts in sync, and the removed text
is used nowhere.
GTK-docs needs the struct member documentations in the main struct
comment. So let's get this back, while keeping the proper GI
introspection for each method this time.
As discussed with Mitch.
... after commit 2c9a8a567b. Don't
use the same function as a handler for GimpContext::display-changed
and GimpContext::image-changed -- their signatures are different.
The exact warning was:
> (goat-exercise-gjs:26895): Gjs-WARNING **: 15:59:18.382: Some code
> called array.toString() on a Uint8Array instance. Previously this
> would have interpreted the bytes of the array as a string, but that is
> nonstandard. In the future this will return the bytes as
> comma-separated digits. For the time being, the old behavior has been
> preserved, but please fix your code anyway to explicitly call
> ByteArray.toString(array). (Note that array.toString() may have been
> called implicitly.)
Commit 005143a43e completely broke all the
introspected plug-ins, so I am reverting only the relevant changes.
If some things need to be improved in this part of the docs, let's do it
without breaking major stuff.
In particular: abstract methods must be properly documented (with
parameters, return values and annotations) like any function, and must
be named Class::method, e.g. GimpPlugInClass::query_procedures.
Other we break GObject Introspection, i.e. we break all plug-ins using
these.
In GimpNavigationEditor, make sure to clear the editor's shell when
the last image is closed, even though the corresponding display is
stil alive, so that we don't needlessly extend the lifetime of the
image. This is necessary after the recent GimpImageViewable
changes, since the editor now (indirectly) holds a reference on the
image.
Ell