This patch does the following to reduce the
height of the Load PDF GUI:
* Hides the title label if the PDF does not
have a title.
* Reduce the padding around elements
* Reduces the requested height of the
GimpPageSelector widget.
* Alter the GimpPageSelector widget so
that the layer/image combobox and the
range entry are on the same line.
New libgimp functions:
- gimp_param_spec_display_none_allowed()
- gimp_param_spec_drawable_filter_none_allowed()
- gimp_param_spec_image_none_allowed()
- gimp_param_spec_item_none_allowed()
I believe that now all param spec strucs which needed to be hidden are
effectively hidden!
New libgimpbase functions:
- gimp_param_spec_choice_get_choice
- gimp_param_spec_choice_get_default
Now the only GParamSpec in libgimpbase whose struct is visible is
GimpParamSpecObject. This can't change since it is derived into param
specs defined in libgimp and therefore needs to be visible.
Actually it does more harm than good on CI, causing inconsistency and work.
The plan was to use it in all jobs but it is simply impossible for Flatpak
(https://gitlab.gnome.org/Infrastructure/Infrastructure/-/issues/1502)
and seems that for Crossbuilds too (tested both crossroad and quasi-msys2).
Actually, only Windows jobs can use it, but started to fail on x86 runners.
On the other hand, sometimes the build is faster without ccache and we do
not have the burden of contacting managers etc. Just pkg caching is fine.
As a consequence, here are needed new functions:
* libgimp:
- gimp_param_spec_resource_defaults_to_context()
- gimp_param_spec_resource_none_allowed()
* libgimpbase:
- gimp_param_spec_file_get_action()
- gimp_param_spec_file_none_allowed()
- gimp_param_spec_unit_percent_allowed()
- gimp_param_spec_unit_pixel_allowed()
… GimpParamSpecUnit's default value.
When I reparented GimpParamSpecUnit to GimpParamSpecObject in commit
ba3da3d338, I clearly forgot to get rid of the redundant default value.
It was working with LC_ALL or LANG but not with LANGUAGE which is an
additional system above the locale system AFAIU.
Concatenating both LANGUAGE environment variable and the locale-set
language, we get a more resilient opaque string value to compare.
Resolved by @Nizhile
In 4bdb8792, a patch porting chrome-it.scm to not rely on
removed brushes included an apparent typo. A decimal
was left off a curve point, resulting in incorrect outcomes.
This patch by @Nizhile fixes the problem.
Resolves#12795
After the Color Space Invasion, gimp_gradient_get_uniform_samples ()
returns an array of GeglColors rather than GimpRGB values and a status
variable. This patch fixes the Spyro-Plus plug-in to expects the new
return values.
It also restores code that utilized the second color gradient in the output
when the Gradient's Repeat Mode is Triangular Wave. This appears to
have been lost during the port from GIMP 2.10.
Without a proper way to compare GFile, gimp_config_reset_properties()
does not reset the config argument to default. This breaks the "Reset to
Factory Defaults" feature in particular.
This same widget is used for GFile args and GimpParamSpecConfigPath
specs. The latter are string-based. So we need different code to handle
both types of arguments.
This was crashing when a change was coming from the config object,
rather than from the GUI, such as when doing a reset to factory values.
Now that GimpParamSpecFile makes file validation depending on the action
set in the param spec, when trying to open a non-existing file (which
can happen through GUI, for instance when opening through the Document
History dockable or Open Recent menu), we had a quite obscure error
about a value "out of range" used "for argument 'file' (#2, type
GFile)", which is because core tried to set the GFile for a non-existing
file into the second parameter of the plug-in PDB. This is not a very
nice error for end-users.
The old error was much nicer as it used to say things like:
> Could not open '/path/not/existing.png' for reading: No such file or directory
But in fact, this string came from the plug-in, which means:
* first that the error can be different depending on the format
(inconsistency of error message);
* depending on bugs in plug-ins, it may just crash or return no error
messages;
* finally we were making a useless call to a load plug-in while we
should already know from core that it won't work.
The new message is something like:
> Error when getting information for file "/path/not/existing.png: No such file or directory
This error is generated by core, so it will always be consistently the
same, is understandable too and the plug-in won't even be called.
As a side related fix, I updated the GimpParamSpecFile validation to
only validate local files, just like we do in core. Remote files can
always be set (and we let plug-ins handle them), at least for the time
being.
Per the (quite off-topic) discussion in #12772, the fact it's quite
broken on Windows, apparently not too maintained anymore and its syntax
clashes with gi-docgen syntax…
I forgot to set meta.m_file.action into the GPParamDef! 🤦
As a side update, let's store the action as gint32 in GPParamDefFile. I
realized that otherwise, depending on the actual size of an enum type,
when casting to a (guint32 *), we crop the value! This works out in
Little Endian because we are only in small number territory, but in Big
Endian, we would always crop any action value to 0!
This was not the bug in this specific case, but it could become the
exact same bug (always passing action 0, i.e. OPEN, through the wire) on
Big Endian hardware.
I don't know what I was seeing when I added this several years ago,
but I can't find any psd CMYK images where the merged image is RGB.
It is wrong for the CMYK images we have and there are none so far
that do conform to it, so let's remove this code.
The merged psd image we create when writing psd's is incorrect when
we selected cmyk at export.
The problem is that we are only saving the 3 channels of our RGB
input image, or 1 for a grayscale image.
Move the channel count up and compute it separately for cmyk, then
reuse the count instead of computing it again.
