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.
Noticed by Massimo.
gimp_type_set_translation_domain() calls were missing.
Also make so that the output is exactly similar (even whitespaces) as
the autotools one, making it easier to diff, hence maintain.
It should be clear that the autotools build is still the officially
mandated one for all finale builds (i.e. packaging). Our meson builds
still have bugs (some we know of and are trying to fix, others that we
will probably discover soon) so packagers should be well aware that they
should not use meson (though we highly encourage it for developers so
that bugs can be found).
Adding this warning as someone was asking on a bug report whether
autotools were still being supported (while it's the opposite: meson is
still not officially stable and autotools is still our main build
system).
New images should obviously still default to the template pixel density
(defaulting to 300.0 PPI when no specific template is selected).
Loaded images though should use a more conservative default of 72 PPI,
first because this is what other software defaults to when no density is
set (so we should keep consistent when possible), and this is also what
the Exif standard (I checked both last version 2.32, and older 2.3)
recommends when no resolution is set.
Technically we differentiate a loaded from a newly created image by
whether or not an imported_file has been set. Of course, any explicitly
set resolution will always override whatever default.
We want to be able to install icons only in a quick command when
testing/developing.
Also I realize that Legacy icons are not even installed with meson
build, which is bad! Even though legacy, we want to keep them (at least
for the time being), just as we do with autotools.
… different layer size/location used.
We need to use the source coordinate space when generating the first
fill buffer, then transform to the target layer coordinate space when
applying the drawable filter.
This is a quick and dirty fix to just deal with this specific issue, but
looking at meson rules for icons, it looks like I will need to do a
proper and very detailed review of this part of the build system.
In gimp_page_selector_add_frame(), if "gimp-frame" icon cannot be loaded
(which should not happen, but reality can always strike back!), we want
to abort from gimp_page_selector_add_frame() immediately.
Also as a consequence, its return value might be NULL, hence should be
freed with g_clear_object() instead.
This happened here because of broken meson rules (which didn't install
this icon) and ended up in forever looping errors when loading a
multi-page PDF (pages are shown in frames in a dialog):
> (file-pdf-load:12348): GdkPixbuf-CRITICAL **: 11:59:28.513: gdk_pixbuf_copy_area: assertion 'src_pixbuf != NULL' failed
My commit c77c903c8d was obviously wrong since I realize that by fixing
the C plug-in installation, I broke non-C goat-exercise plug-ins
installation. This fixes it.
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.
I had this warning when cross-building for Windows 64-bit:
> libgimp/gimpui.c:187:52: warning: passing argument 2 of
> 'gdk_win32_window_foreign_new_for_display' makes pointer from integer
> without a cast [-Wint-conversion]
> note: expected 'HWND' {aka 'struct HWND__ *'} but argument is of type 'guint32' {aka 'unsigned int'}
Similar to commit 9b328167ab. Apparently the same function is duplicated
into app/.
Also add some comments to detail a bit more where this Win32 different
comes from (i.e. bug 359538 on Bugzilla, commit eac61e1e12).
Moreover I tested the same steps as comment 4 in bug 359538 on master
code. The same hanging issue still exists with GTK+ 3.24.1 (in a Windows
VM at least). I have not investigated further, just wanted to check if
this ifndef could not simply be removed by now. Apparently not.
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.
export it to libgimp via GPConfig and add new API gimp_export_comment().
Bump the protocol version and improve variable names in both GPConfig
and libgimp/gimp.c.
which removes quite some boilerplate. Also remove the boolean
"profile_saved" return value of save_image() and instead modify the
config. Add a "bits_per_sample" return value and set value on the
metadata instead of always "8".
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.
See #3996.
This was a warning raised by the Coverity scan on one of the lines. I
fix also in the same time other arithmetics mixing int and double.
Better be thorough.
The specific warning was on:
> circ = 2.0 * G_PI * (private->width / 2)
where the division was integer, which was probably not intended. Of
course that error (display item only) was likely barely visible anyway,
still…
Now takes an integer index into the aa_formats array instead of the
format's name. "4" is about as magic as "weird aallib format name #4"
so no harm done.
and add boolean arguments to control comment and hot-spot
writing. This revives comment writing, which is disabled by default
and comes with a big warning in the dialog.
Sabri Ünal