… don't include it from public gimpui.h.
As reviewed during !786, if this file is private, the name should show it
clearly. And of course, we must not include it from another public header, since
it won't be installed.
This also fixes building plug-ins with gimptool as reported by tmanni:
e00f2d7f50 (note_1650791)
Simplifies chooser widgets (e.g. GimpBrushSelect) by eliminating attributes (e.g. opacity) of chosen resource.
See #8745, but this commit fixes that by first refactoring the code.
Refactors GUI widgets (e.g. GimpBrushSelectButton and GimpBrushSelect etc.)
Refactor by "Extract class" GimpResourceSelectButton from GimpBrushSelectButton etc.
This moves common code into an inherited class (formerly called GimpSelectButton)
but the subclasses still exist.
The subclasses mainly just do drawing now.
Refactor by "Extract module" GimpResourceSelect from GimpBrushSelect etc.
Moves common code into one file, generic at runtime on type of GimpResource,
that is, the new code dispatches on type i.e. switch statements.
In the future, when core is changed some of that can be deleted.
The files gimpbrushselect.[c,h] etc. are deleted.
The module adapts the API from core to the API of callbacks to libgimp.
Note that core is running the resource chooser (select) widgets remotely.
Core is still calling back over the wire via PDB with more attributes
than necessary.
The new design gets the attributes from the resource themselves,
instead of receiving them from core callback.
The libgimp side adapts by discarding unneeded attributes.
In the future, core (running choosers for plugins) can be simplified also.
Fix gimp_prop_chooser_brush_new same as other resources.
Finish changes, and clean style.
Annotations
So procedures can declare args and GimpProcedureDialog show chooser
widgets
Fix so is no error dialog on id_is_valid for resources
Palette.pdb changes and testing
Memory mgt changes
Gradient pdb
Font and Pattern tests
Test brush, palette
Cleanup, remove generator
Rebase, edit docs, install test-dialog.py
Whitespace, and fix failed distcheck
Fix some clang-format, fix fail distcheck
Fix distcheck
Cleanup from review Jehan
Only libgimpui depends on GTK+, display servers and other GUI-related
dependencies. There was a problematic include added in commit 0b56aa0d13 for
macOS, but the needed code (testing the macro GDK_WINDOWING_QUARTZ to use some
[NSApp activateIgnoringOtherApps:YES] API) doesn't seem to be present anymore in
there, so I think that removing this include (replace by including GLib for
other calls) should work fine. Of course, we'll know it when the separate CI
will test a macOS build as we still don't have in-Gitlab macOS jobs. :-/
Now text layers are proper types, which means that the binding API will also be
nicer (e.g. `txt_layer.set_text('hello world')` in Python).
This commit also adds the param specs allowing to create plug-in procedures with
text layer parameters.
Finally it fixes the few calls in file-pdf-save (apparently the only plug-in
using specific text layer API right now) with explicit type conversion.
Now that we bumped our meson requirement, meson is complaining about
several features now deprecated even in the minimum required meson
version:
s/meson.source_root/meson.project_source_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.source_root. use meson.project_source_root() or meson.global_source_root() instead.
s/meson.build_root/meson.project_build_root/ to fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': meson.build_root. use meson.project_build_root() or meson.global_build_root() instead.
Fixing using path() on xdg_email and python ExternalProgram variables:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.55.0': ExternalProgram.path. use ExternalProgram.full_path() instead
s/get_pkgconfig_variable *(\([^)]*\))/get_variable(pkgconfig: \1)/ to
fix:
> WARNING: Project targets '>=0.56.0' but uses feature deprecated since '0.56.0': dependency.get_pkgconfig_variable. use dependency.get_variable(pkgconfig : ...) instead
Ironically, it is a test for the Windows platform but it cannot run on
Windows. First, because it expects a .so (which could be easily fixed),
but even more because from web search, it looks like the nm tool may not
exist on Windows (though I haven't checked).
Anyway we only ever ran it from Linux machines and up to now, it worked
just fine and was useful anyway. So let's go with it.
Also clean a bit remnants from older attempts to run this script.
Our meson build system was not properly building the enums.c file,
because they are versionned.
I did a similar trick as what I did for the pdbgen, which is that I used
a wrapper script around the existing perl script, which sets proper
options and generate a stamp file in the end (which is considered by
meson as the actual custom target, not the C file since it is generated
in the source dir).
The most important part is that the stamp file is a generated header
source (not just a random text file) which is **included** by the
generated C file. This is what will force meson to regenerate the C file
if the header is updated, **then** build using this new version, not use
an outdated versionned version (which would make for hard to diagnose
bugs), through the indirection of the intermediate stamp header.
See #4201.
See also: https://github.com/mesonbuild/meson/issues/10196#issuecomment-1080742592
The check script now takes into account both the autotools and meson
file hierarchy (in autotools, built libs are in .libs/ subdirs).
Also it now properly fails on missing lib.
The build now successfully build the PDB files into the source folder
itself. Unfortunately it seems I can't get meson dependencies to work
properly, once more! I added a "sources" argument to the relevant
library() or static_library() but it still uses old versions to build
these. E.g. if I add an error on purpose to a pdb file, the next build
still passes, yet the second-next fails (as it should have before).
Note that I even tested a declare_dependency() with just the "sources"
arguments, because it says "sources to add to targets (or generated
header files that should be built before sources including them are
built)" (so I assume it means that it should be trigger a rebuild,
otherwise it's useless) but it's just not working. I'll investigate
more.
Still going with this for now, because at least generating the PDB
source was a big miss until now. But we should
yocto/oe is capable of building gobject introspection despite cross-compiling.
add an option to enable gir build even if cross-compiling
Signed-off-by: Markus Volk <f_l_k@t-online.de>
Reviewer note (Jehan): this whole stuff is a mess. Actually I'd like to
simply get rid of the whole no-gir-when-cross-compiling logics but I
still can't figure out how to cross-build generically with GIR.
Yet since some manage it with yocto, let's unblock them.
See #7208.
… class GimpSaveProcedureDialog.
The idea is that we have basically the same code in most file format
plug-ins to handle various generic metadata, yet usually with slight
differences here and there. Even behavior is sometimes a bit different
even though there is no reason for the logics to be different from one
format to another.
So I move the metadata support logics into GimpSaveProcedure (and
GimpProcedureConfig still keeps the main export logics). The GUI logics
is now in a new GimpSaveProcedureDialog. So export plug-ins will now get
the creation of generic metadata nearly for free. All they have to do is
to tell what kind of metadata the GimpSaveProcedure supports with the
gimp_save_procedure_set_support_*() functions.
Then consistency will apply:
- If a format supports a given metadata, they will always have an
auxiliary argument with the same name across plug-ins.
- The label and tooltips will also be always the same in the GUI.
- Order of metadata widgets will also stay consistent.
- The widgets will work the same (no more "Comment" text view missing in
one plug-in but present in another, or with an entry here, and a text
view there, and so on).
Also adding gimp_save_procedure_dialog_add_metadata() to allow plug-ins
to "declare" one of their options as a metadata option, and therefore
have it packed within the "Metadata" block which is now created (for
instance for PNG/TIFF/JPEG specific metadata). This allows a nicer
organization of dialogs.
Though GObject Introspection is normally not an option, the only case we
don't build it yet is when cross-compiling (as we haven't found the
right way to do it). So let's not build the Goat Exercise plug-in in
Vala in such case as we needed the introspected libgimp.
Since meson 0.43.0 (below our current requirement), 'symbol_prefix'
argument of gnome.generate_gir() allows an ordered list. If I prepend
'gimp_ui', it makes any gimp_ui_*() function to not start with 'ui_'.
In particular, GimpUi.ui_init() becomes GimpUi.init() which is much less
redundant.
Orientation is now handled by core code, just next to profile conversion
handling.
One of the first consequence is that we don't need to have a non-GUI
version gimp_image_metadata_load_finish_batch() in libgimp, next to a
GUI version of the gimp_image_metadata_load_finish() function in
libgimpui. This makes for simpler API.
Also a plug-in which wishes to get access to the rotation dialog
provided by GIMP without loading ligimpui/GTK+ (for whatever reason)
will still have the feature.
The main advantage is that the "Don't ask me again" feature is now
handled by a settings in `Preferences > Image Import & Export` as the
"Metadata rotation policy". Until now it was saved as a global parasite,
which made it virtually non-editable once you checked it once (no easy
way to edit parasites except by scripts). So say you refused the
rotation once while checking "Don't ask again", and GIMP will forever
discard the rotation metadata without giving you a sane way to change
your mind. Of course, I could have passed the settings to plug-ins
through the PDB, but I find it a lot better to simply handle such
settings core-side.
The dialog code is basically the same as an app/dialogs/ as it was in
libgimp, with the minor improvement that it now takes the scale ratio
into account (basically the maximum thumbnail size will be bigger on
higher density displays).
Only downside of the move to the core is that this rotation dialog is
raised only when you open an image from the core, not as a PDB call. So
a plug-in which makes say a "file-jpeg-load" PDB call, even in
INTERACTIVE run mode, won't have rotation processed. Note that this was
already the same for embedded color profile conversion. This can be
wanted or not. Anyway some additional libgimp calls might be of interest
to explicitly call the core dialogs.
gimpimagemetadata.[ch] was built into libgimpui because GTK+ was used
for dialog query for rotation metadata. gimpimagemetadata-save.c only
was built into libgimp, which made no sense as the declaration for its
public function was inside gimpimagemetadata.h!
That was a weird situation and somehow only made visible in the build
system because GIR build was complaining about missing annotations to
gimp_image_metadata_save_prepare() (the annotation was actually present
but in the implementation which was not in the same library as the
header, how weird!):
> Warning: GimpUi: gimp_image_metadata_save_prepare: return value: Missing (transfer) annotation
Moreover it means that only plug-ins linking libgimpui had access to the
gimp_image_metadata*() API, which is obviously not cool (that should be
a core API).
Instead I moved everything into libgimp and replaced
gimp_image_metadata_load_finish() with
gimp_image_metadata_load_finish_batch(), which is essentially the same
function except that it's not interactive (it will proceed to rotate the
image without user confirmation, provided the right flag is present).
Then I add gimpimagemetadata-interactive.[ch] which contains only
gimp_image_metadata_load_finish() and is the alternative interactive
version of gimp_image_metadata_load_finish_batch(). Most plug-ins won't
even have to be changed (at least none in core GIMP) and would still
work as before, whereas now a non-interactive version exists, which
doesn't mandate to link GTK+.
By using Meson's `declare_dependency()`, we can avoid specifying the
linked libraries, dependencies and includes we need over and over again.
Basically, this conceptually acts like an internal pkg-config.
When using GIR-based bindings that will eventually include the header
files (like Vala), we need to make sure to tell the gir-scanner what
file that is. Otherwise tools like `vapigen` have to make an educated
guess (which will be wrong).
Copy gimp_param_specs_get_desc() to libgimp and make it also mention
default values. Don't install its header for now, because it's pretty
much a utility function of GimpProcView. It also doesn't handle most
GParamSpec types yet.
As a side effect, this fixed issue #3947.
No need to introspect deprecated API, especially for the new non-C APIs
after a major version update.
This also sync both the autotools and meson-generated GIR files.
See also #4018.
More of the files were wrong, or at least not absolutely identical to
the files generated by the autotools. I am not doing any code change
other than trying to make both build systems produce identical files
(except for slight differences on 2 files not worth the effort) even
though maybe some things can be improved (especially on the include
list). Maybe to be improved later.
Also fixing 2 of the previously autotools-generated files because of
space typos which should have been committed earlier.
Finally it is to be noted that there is no logics to copy the generated
files back to the source directory in the meson rules. I am not sure
anyway this is really worth it and maybe we should just stop tracking
these generated files eventually.
This is listed twice and is not needed for libgimpui (not listed in
autotools build) and apparently it provokes introspection warnings on
MSYS2 builds.
Thanks to lillolollo and Massimo for debugging this.
Thanks to Massimo for helping:
> To reduce the number of warnings down to 2, it is necessary to list
> gimptypes.h and gimpenums.h right after gimp.h and gimpui.h
> gimpuitypes.h at the start of libgimpui_headers_introspectable like
> they are in the corresponding list in Makefile.gi.
>
> Their order evidently matters
See #4018.
Some stuff are still wrong, but this is a first step in the right
direction.
Add gimp_procedure_config_begin_export() and end_export() which
are wrappers around begin_run() and end_run() and additionally
pretty much completely manage GimpMetadata handling.
A GimpProcedureConfig can provide boolean properties "save-exif",
"save-xmp" etc. in order to have them automatically managed by
begin_export() and end_export(). This also restores the feature of
overriding the procedure's saved default values with export
preferences, but not the values from the last export, like it
used to be in 2.10.
Move gimp_image_metadata_save_prepare() and save_finish() (which are
now completely handled by GimpProcedureConfig) from libgimpui to
libgimp, but keep their declarations in the libgimpui header. Not
perfect, but not finished either.
Also fix gimp_image_metadata_save_prepare() to set the affected
GimpMetadataSaveFlags to 0 when the image has no metadata at all.
This is hopefully a temporary setback since we want to consider the
introspected API as a core feature (otherwise we'd end up with third
party builds deactivating the feature, and get a very random experience
depending on where you got GIMP) hence don't want it to be optional
(note that I haven't added a configure option).
Anyway for now, it seems that cross-building introspected data is not
really supported (or I'm still figuring it out).
Apart from some obvious typo, libgimpui link was failing with meson
because it now relies on a function from libgimpconfig (i.e.
gimp_config_reset()), since commit bfb7f43dbc. This fixes:
> /usr/bin/ld: libgimp/gimpproceduredialog.c:223: undefined reference to `gimp_config_reset'
