A few commands need to be performed the first time for glib to work
properly, and gdk-pixbuf loaders to be found. I add them in a wrapper
script so that it's easy to ask people to test the dev builds (even
though it's not necessary to run these commands each time, but who
cares!).
Variable ai and ai_curr going out of scope at line 496.
Variable ai going out of scope at line 545.
Revealed by Coverity Scan.
(cherry picked from commit 1ce1b0eebe)
Let's make sure they are not pulled in as dependency of other packages.
This fixes the Win32 CI build now that we fixed the Pango minimum
requirement in meson files.
as in, sync it with a "comment" property on the config if one
exists. Also allow gimp_procedure_config_begin_export() and
end_export() to skip GimpMetadata handling, for file formats which
don't support it.
Add an n_components parameter to gimp_histogram_clear_values(),
which allows to set the new component count when clearing the
histogram. This is useful to seed the histogram with the correct
number of channels, for display purposes, before starting an async
histogram calculation. We use this in GimpHistogramEditor, to
avoid resetting the view's channel back to "Value" each time the
active drawable changes.
In GimpHistogram, get rid of the "n-channels" property and
corresponding gimp_histogram_n_channels() function. The former
returned the actual number of channels, but this wasn't too useful,
as channel values may not be sequential; the latter returned the
number of components. Instead, add an "n-components" property and
a corresponding gimp_histogram_n_components() function, both of
which return the number of components. Furthermore, add a
gimp_histogram_has_channel() function, which determines if the
histogram has a given channel; this allows for simple testing for
channel availability, which was done wrong in various places.
Adjust the GimpHistogram code for the changes, and clean it up,
fixing a few bugs.
Adjust users of GimpHisotgram for the changes. In particular,
in GimpHisotgramView, fix the channel-availability test when
setting the view's histogram (which happens whenever the active
drawable's preview is frozen), to avoid erroneously swithcing the
view's channel back to "Value" when a non-RGB channel is selected.
Tested in a VM. Minimized window is properly deiconified and showed to
the front. Though a window in the back (not minimized) is not moved to
the front.
There were 2 warnings of unused functions on this file, and masking
them, we were ending with a whole file #ifdef-ed 0. So let's just get
rid of the whole useless file.
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.
Swapped arguments: height is passed to width. width is passed to height.
Please check the function in /app/core/gimpbrush.c at line: 606
void
gimp_brush_transform_size (GimpBrush *brush,
gdouble scale,
gdouble aspect_ratio,
gdouble angle,
gboolean reflect,
gint *width,
gint *height)
(cherry picked from commit aeadaaeb6c)
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).