Per Jehan, we should remove gimppickbutton-default.[ch] and
move the functions into gimppickbutton.c. Then we can
make the GimpPickButtonPrivate API actually private without
any additional public functions.
This widget is used primarily in plug-ins like GFig and IFS Compose
which have toolbar buttons. This patch explicitly defines the style to
prevent system theme leaks and too dark colors on Middle Gray theme.
The "selected-layers-changed" signal was emitted while there were still
selected channels (which is an inconsistent state). And since
gimp_image_get_selected_drawables() returns selected channels first when
the image has any, vectors_actions_update() was using the previously
selected channel's lock information for deciding which actions to set
sensitive.
Temporarily reverting as the private struct
is shared between various OS versions of
the object and needs to be accessible.
A different approach will be needed to resolve,
and until then, I'd like the Debian pipeline to
work properly.
Move all public attributes of GimpThumbnail
from the header to a private struct in
GimpThumbnail.c. Also replace direct
access of these attributes in app/core and
app/widget with get/set calls.
Legacy plug-ins like Checkerboard (legacy) under Render Patterns lost
their Help button, although using F1 was still working.
Due to changes in how procedures are called, `gimp_dialog_constructed`
was called before the help-id was set.
The simplest way to fix this, is to call
`G_OBJECT_CLASS (parent_class)->constructed (object);`
at a later time in `gimp_procedure_dialog_constructed` after we have
set the help-id there.
Fixes:
> libgimpbase/gimpchoice.c:366: Warning: Gimp: gimp_choice_set_sensitive: invalid return annotation
Introspection step is now fully without any warning! \o/
I thought that such annotations would work and be useful to tell GIR that
a type is nothing more than a NULL-terminated array of a specific type.
But apparently GIR doesn't like these annotations and complain. So let's
just clean these out.
Fixes:
> ./../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: array
> ../../../../../../../dev/src/gimp/libgimpbase/gimpparamspecs.h:254: Warning: Gimp: unexpected annotation: element-type
Right now, it only tests a few API, such as creating an image, then a
text layer, then inserting it in the image.
This is a test to avoid regression bug after having fixed#9923 in a
previous commit.
Without this, build-time GIMP cannot find the etc/ files unless GIMP is
installed. This becomes even more annoying now as I want to run tests
(for GimpUnit) depending on etc/unitrc contents.
This will also ensure that tests run properly in environments where the
etc/unitrc may have been modified.
This fixes all our GObject Introspection issues with GimpUnit which was
both an enum and an int-derived type of user-defined units *completing*
the enum values. GIR clearly didn't like this!
Now GimpUnit is a proper class and units are unique objects, allowing to
compare them with an identity test (i.e. `unit == gimp_unit_pixel ()`
tells us if unit is the pixel unit or not), which makes it easy to use,
just like with int, yet adding also methods, making for nicer
introspected API.
As an aside, this also fixes#10738, by having all the built-in units
retrievable even if libgimpbase had not been properly initialized with
gimp_base_init().
I haven't checked in details how GIR works to introspect, but it looks
like it loads the library to inspect and runs functions, hence
triggering some CRITICALS because virtual methods (supposed to be
initialized with gimp_base_init() run by libgimp) are not set. This new
code won't trigger any critical because the vtable method are now not
necessary, at least for all built-in units.
Note that GimpUnit is still in libgimpbase. It could have been moved to
libgimp in order to avoid any virtual method table (since we need to
keep core and libgimp side's units in sync, PDB is required), but too
many libgimpwidgets widgets were already using GimpUnit. And technically
most of GimpUnit logic doesn't require PDB (only the creation/sync
part). This is one of the reasons why user-created GimpUnit list is
handled and stored differently from other types of objects.
Globally this simplifies the code a lot too and we don't need separate
implementations of various utils for core and libgimp, which means less
prone to errors.
Adds SVG versions of ImageMap custom
icons and conditionally uses them if
have_vector_icons is enabled. If not, we
fall back to the original PNG icons.
Since ImageMap mixes custom and
stock icons, this keeps the icon size
consistent across the UI.
Per Denis Rangelov, tooltips for the
coordinates and area displays as well
as the shortcut menu were added.
Also, removes a reference to IMAP_ARROW
which no longer applies since that icon
was removed in favor of using the stock
cursor icon.
Despite the good intentions, 4f965557 makes Debian contributors who
follows gimp-web-devel instructions to download more deps than needed
and makes unclear what are the crossroad deps. Let's fix it.
This makes crossroad and msys2 scripts clone without the "_" prefix, which
will improve quality of life of most contributors that just clone them.
Just for consistency, also remove the "_" prefix from other pices of code.
The original script required a specific WinSDK version. Now, it autodetects.
This is useful if we need to move to another runner and welcome locally too.
Also, downloading the arm64 artifact was mandatory to get a x64 msix, which
is silly. Now, packagers are free to package to either arm64 or x64 alone.
This is useful locally but could be useful on CI too when some arch fail(?).
Resolves#11313.
We reference JPEG and TIFF images when
we send them from their loading plug-ins
to the PSD plug-in for PSD formatted
metadata. We should remove this extra
reference when returning the image back
to its original loading plug-in.
Inspired by Mark Sweeney's work.
This patch allows the active image, brush,
pattern, and gradient areas in the toolbox
to scale based on user icon scale
preferences.
Note that if the pattern itself is smaller
than the icon size, it currently won't scale
larger. This is a separate issue in the
renderer.
Yuri Chornoivan