When loading a PSD with multiple extra layer channels, the PSD loader
crashes. We increase the number of layer_channels with 2 for every
extra channel found, which we only should do for the first extra to
skip the alpha channel.
We fix this by adding a check to see if this is the first extra channel
and in that case skip the alpha channel slot. Any other extra channel
will be added in the next available slot.
We also add an extra check in case we have extra channels when we do
not have an alpha channel in the layer. Not sure howe likely this is.
In that case we move the last extra channel to the slot reserved for
the alpha channel. That way we won't try to free non-existent alpha
channel data.
Note that eventually we should probably try to add these extra layer
channels are extra image channels in GIMP, since GIMP doesn't have the
concept of extra channels per layer.
The border-drawing code for Layer icons
has been ported to GeglColor. Note that
GimpViewRenderer still uses GimpRGB for
gimp_cairo_checkerboard_create (), which
will be fixed in a larger commit.
In 9bee3bed, Border Average's return
value was set to NULL rather than a valid
GeglColor when the procedure was
created, which caused a warning on
launch. This has been fixed.
Now the development and stable logos will be generated from gimp-data.
In other changes, the gi-docgen logo is installed as a symlink using
install_symlink() which exists since meson 0.61.0 so I bumped our meson
dependency (in practice we were already using this function anyway and Debian
bookworm has meson 1.0.1 so it's all good).
Finally I don't install a wilber.png anymore, which was only used by script-fu
testing, and which was the same as gimp-logo.png (except 256x256 instead of
128x128). Unless mistaken, all script-fu tests loading this image still work
with the change. The only one where I needed further change was buffer.scm
(which was checking the dimensions).
See gimp-data@9aa6e35.
In GIMP 2.10 the number of segments was restricted to MAX_FANS.
That was later changed to 1024 without increasing MAX_FANS
which can crash the plug-in.
Also change the max displacement angle back to 90 degrees. The interval
0 to 90 degrees is enough to return all possible values.
Fixes#11108
...to fully use and return GeglColor.
Also, fix gimptext-parasite sending a
GimpRGB to create a GimpText instead of
the now required GeglColor, and update
documentation in gimp_checks_get_colors
to reference GeglColor instead of GimpRGB.
Resolves#11092
Same fix as in 2b3b2af2, since Blinds and Jigsaw
were the two plug-ins which used GimpAspectPreview
before the port to GimpProcedureDialog.
After the port to gimp_procedure_dialog_get_drawable_preview (),
the preview widget was being sized to the original drawable's dimensions
while the drawable was being redrawn with only its thumbnail dimensions.
This created a scrollbar that showed unallocated/overwritten buffers.
To fix, we update the preview size and boundaries whenever the preview
is changed. This removes the scrollbar and returns to 2.10 behavior.
In addition to the port, mnemonics were added to both file-pdf-save-multi
and file-pdf-save's GUI parameters.
Some runtime warnings were also fixed, such as trying to use a NULL string
parameters to make a file and trying to access properties from file-pdf-save
that don't exist in file-pdf-save-multi.
Resolves#11083
Per bootchk, changes in function calls to
palette_entry_get_color () and
gradient_segment_get_left_color () were
broken in Python scripts due to GelColor
being used post Color Space Invasion.
This patch fixes the calls and returns.
More descriptive name for script-fu-interface-dialog
Delete SF flag for gimp_ui_init already called: gimp_ui_init can be called often.
FUTURE: might be faster to call just gegl_init when mode is non-interactive.
After the color space invasion, the
Clip Warning filter no longer had color
areas for its shadow, highlights, and
bogus color properties. This patch ports
them to GeglColor so the widget can be
created correctly.
GimpRGB structs are also converted to
GeglColor in GimpPanedBox and two
plug-ins.
Without this, there is no easy way to quietly check for existence of a resource by name.
Needed when plugin authors can name defaults for resource args by name.
Add tests to script-fu/test/tests
So far, we did not consider that group layers could also be part of
a set of layers that have clipping set. This means that clipping groups
can be nested.
To support this we have completely rewritten the layer parser to detect
all clipping groups and mark them in a first pass. We now go through
the layers from the last (top) layer to the first (bottom) in this
first pass, because that makes it easier to detect the start/end
pairs of a clipping group.
In the second pass we handle the clipping groups first before adding
layers, except when a regular group is also the start of a clipping
group. In that case we need to handle the clipping after creating the
regular group, or we get an incorrect order.
Unsupported psd layers were dropped when loading psd images. This
causes problems when handling psd clipping groups, see issue #8453.
PSP also does not drop unsupported layers, so let's keep the layers
and accept that they will usually show up empty. This will help in
fixing clipping groups in a next step.
While we are at it, also remove the warnings that are only shown when
define CONVERSION_WARNINGS is TRUE (defaults to FALSE). We already
have a better way to show unsupported features, so at least for the
unsupported layers it is not needed anymore.
There are still some CONVERSION_WARNINGS warnings left over in the
blend modes conversion, which do not have a similar warning in our
unsupported features dialog.
- Replaces GimpRGB in Channel Dialog
with gdouble array, as was done in
channel_options_color_changed ()
- Replace %ld with G_GSIZE_FORMAT
in libgimp checkboard color message to
fix warning in Windows build
- Set file-gih documentation text as
translatable.
Per bbb30eac, the GimpHSV object is replaced with
gegl_color_get_pixel () in "HSV double" color format.
GimpCellRendererColor still needs to be updated to
accept GeglColor rather than GimpRGB.
This commit fixes several issues with the plugin.
* Move plug-in to GimpProcedureDialog framework (see #9250)
* Use GimpPalette instead of (soon to be deprecated) Colormap (see #9477)
* Make plugin UI height, make it resizeable, update font sizes,
paddings, etc (see #10533)
Further improvements most likely are needed because plugin still uses
GimpRGB and GimpHSV (former is used by GimpCellRendererColor, latter for
H, S, and V values)
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/10533
Resolves: https://gitlab.gnome.org/GNOME/gimp/-/issues/10749
During the GimpProcedureConfigDialog port,
the "gimp-brush-pipe-parameters" parasite loading
code was unintentionally removed. This parasite
was used to restore the GIH parameters if it was
loaded as an image.
This patch restores that code on initial export as
GIH, then removes the parasite since the parameters
will be saved as part of the GimpProcedureConfig
going forward.
Allow (script-fu-use-v3) in script, or in SF Console.
Definitive description is in script-fu/docs/using-v3-binding.md
Makes SF interpret v3 of SF dialect.
- marshals single return value from PDB without wrapping in list
- marshals boolean return value from PDB as #t #f instead of integers
- marshals boolean to PDB from #t and #f or TRUE and FALSE
- marshals void return from PDB as () instead of (#t), but that is moot.
The version of SF dialect is distinct from the version of the PDB API.
Dialect v3 is opt-in: the initial dialect of all SF tools remains v2.
Commit also allows #t,#f for defaults of SF-TOGGLE instead of TRUE, FALSE
but that is an independent enhancement (but closely related.)
Affects interpreter state of the current process.
Not an attribute per se of a plugin.
While in this state, a plugin should not call PDB procedures
which are themselves v2 script plugins,
or a few utility scripts in script-fu-util.scm,
but that is rarely needed.
Does not remove symbols TRUE and FALSE from dialect.
A script can also call (script-fu-use-v2) to revert.
That is also discouraged but useful e.g. for testing.
Fixes#9883
There were menus that put their entries
directly in the tab menu rather than in a submenu.
This moves them to submenus to bring back GIMP 2.10 behavior.
Stray entries added by scripts are also moved to the right
submenu.
Call gimp_ui_init during query phase as well as run phase.
Maybe gimp_main() should do this.
Since space invasion from GimpRGB to GeglColor,
plugins that declare defaults for formal args of type GeglColor
need babl and gegl at plugin registration time.
Due to changes in our metadata handling API for plug-ins, the exif and
xmp metadata read from exr images was being overwritten by empty
metadata.
Fix this by following the new API and also add messages when loading
metadata fails. That way it will be easier to catch in the future if
metadata loading gets broken again.
When defining jpeg_exr a closing \0 is automatically added by the
compiler. So when we compare it using sizeof, we do not compare
6 bytes but 7. Since there won't be three 0's, this will fail.
Fix this by reducing the size by 1 and also update the comment to
make this clear and further to add that this was changed after
darktable 4.0.0.
Resolves#11004
During the port to GimpProcedureDialog, the code
that assigned the current monitor object for
Windows and MacOS was accidentally removed.
This patch restores this code in the proper place.
At script create time, create a GimpRGB i.e. pixel from the declared name of default color.
At plugin procedure registration time, convert that pixel to GeglColor,
and use that color to declare the color arg using GeglParamSpecColor(default=color)
Fixes a faulty fix a few commits back where we lost the declared color name.
The proper dataflow is name->color->paramspec-with-default-color.
Extract methods related to color into new file.
So method names document what is being done.
So related code is together.
Ditto for resource.
No functional change.
Preparing for changes to reset/default and changes to representation of pixels
in lists of differing lengths rgb vs rgba.
Fixes errors introduced by my prior commit c0ca0b74
1. SF is storing colors in GimpRGB, not GeglColor.
Storing using wrong pointer type seemed to work, but would not build on newer compilers.
2. spurious error message "CRITICAL....Two different plugins tried to register..."
Due to calling gimp_ui_init too early, in the class instance init.
When testing on Debian with acertain invalid PCX imagea that return
"Invalid number of bytes per line in PCX header", we get an error:
free(): double free detected in tcache 2
On Windows this doesn't cause an error, most likely due to a different
implementation of fclose.
The problem is that in case of errors fclose was called twice. Since
the file is opened outside the load_image functions, let's handle
closing also only outside that function.
In addition to that, change all g_message error notices to use
g_set_error instead, that way we always return a GError in case of an
error.
Further we also fix a possible error case of overwriting an existing
error by using g_prefix_error when the error is already set.
Previous pcx commit da217088d0 fixed
loading pcx images that had an off by one value for bytesperline.
However, it did not take into account that a value of 0 would be
invalid, causing a crash.
We fix this by adding a check for 0 and also failing in that case.
Since PDB now traffics in GeglColor instead of GimpRGB.
Change GimpParamSpecRGB to GeglParamSpecColor when declaring args to procedure.
Declared default is temporarily "black".
Change conversion of gvalue to scheme representation, now from GeglColor.
Incidental change to interpreter to init gegl early,
since now needed during registration phase.
Since the color space invasion, GimpRGB
properties do not create widgets anymore.
For Python plug-ins, we need to add
GeglColor properties as GObjects with
GeglColor value types as a workaround.
This patch does this and updates the
Foggify plug-in with the new datatype.
As noted in a comment on issue 10873,
choosing Selection for Fixed Gear throws
a TypeError. This is because with the change
from GimpRGB to GeglColor, we can no longer
directly access the red component with an index.
Instead, we need to call Gegl.Color.get_rgba() to get
that value, which is what this patch does.
To reflect increased generality, its not just "coffee" but any gradient.
Delete "realistic looking": subjective and adds no content.
Better tooltips for the arguments.
Fix it by also enhancing, making the gradient an argument with a default
instead of a fixed choice of the gradient named "Coffee".
Instead of fixing by looking up the gradient ID in the body of the script.
Right now, I just transform any GeglColor return value into a RGB u8 triplet,
because that's also how we were supporting GimpRGB anyway, though it's seriously
limited.
Ideally we'd add some real concept of generic color abstraction in Script-fu
too, which could support any color model, space and precision.
Resolves#10830
The supersample-max-depth parameter
of gimp-drawable-edit-gradient-fill
required a value between 1 and 9.
Previously this wasn't enforced, so several
scripts called it with a value of 0.
Now that it's enforced, those scripts were
broken. This fixes the calls in weave,
gradient-example, test-sphere, burn-in,
and coffee (although it has other issues)
It was a bit sad that we'd release GIMP 2.99.18 with no plug-in using
GeglColor argument yet, so at least with this, we'll have one as a demo
of what needs to be done.
For the time being, only the same format as GimpRGB params is supported, which
means creating a color either as CSS strings or as RGBA list values, which means
that we can only input sRGB values right now in ScriptFu (even when calling
GeglColor-using API).
This is the second part to fix issue #10811.
Clicking on the Save button threw an exception as the wrong class was
used to invoke the `set_alternative_button_order_from_array()` method.
Since `Gtk.Dialog.set_alternative_button_order_from_array()` is
deprecated and the GIMP functions with the same name suppress
deprecation warnings in the C code, we suppress the warning here as
well. The `warnings.catch_warnings()` function is not thread-safe
according to the Python documentation, which should not pose a problem
here.
Also, the file chooser dialog now allows specifying a new file instead
of overwriting an existing file.
The invasion extended to some core widgets too, in particular GimpColorPanel (a
subclass of GimpColorButton). There was quite a lot of code depending on these
widgets.
This includes improvements on the out-of-gamut colored corner being shown for
unbounded component types out of the [0; 1] range (with some small margin of
error to avoid e.g. a -0.0000001 value to show as out-of-gamut).
There are still improvements to be made on the color rendering. In particular,
it still draws as CAIRO_FORMAT_RGB24 cairo surface. We should probably move to
draw as CAIRO_FORMAT_RGBA128F eventually (more precision and even allowing to
draw unbounded colors with a possible option, instead of always clipping).
Also adding the libgimpwidgets API gimp_widget_get_render_space().
We pass 2 GeglColor through the wire now. Since it is passed very early
(when sharing the configuration), I had some issues with initialization
order of GEGL, and in particular when calling gegl_init() before
gegl_config() inside _gimp_config(), I had a bunch of such criticals:
> Plugin script-fu: GLib-GObject: CRITICAL: Two different plugins tried to register 'GeglOpPlugIn-transform-core'
Anyway in the end, I store the passed colors as raw bytes and strings in
the GPConfig object, and re-construct the GeglColor last minute in
_gimp_config().
One of the big improvement in this commit is that text layers are now much
better at space accuracy. They were already space-aware, yet rendered as sRGB u8
only before being converted to the image's space. It means that text layers had
the following limitations:
* Any color out of sRGB gamut were trimmed.
* Precision was always 8-bit (even if the image was high-bit depth).
Now GimpTextLayout keeps track of its source space (for RGB and CMYK only, this
won't be as easy when we will support more backend, since Cairo has only RGB
support for image data) and the image TRC (in case it bypasses the color space's
TRB) and it draws within this gamut and space.
It means first that we are not limited to sRGB colors; we will draw text main
color in the full image gamut, with still 2 remaining limitations:
* Unbounded colors are impossible because Pango format (to color text) uses
hexadecimal (so even with half/float images, you can't draw out-of-gamut text
unfortunately).
* Main color precision is still 8-bit, yet a tiny bit better than before as we
at least follow TRC (so we avoid some of the precision loss when converting,
even though the bit-depth is still the biggest loss).
The outline color on the other hand is drawn through Cairo API entirely, in
float. This means that the outline color will now be without any precision loss.
Note that this depends on CAIRO_FORMAT_RGBA128F which is only available since
Cairo 1.17.2 which is not in Debian bookworm (our current baseline for GIMP
3.0). It means that the old precision will still happen with older Cairo
version, as determined by #if code at compilation.
- app: gimp_context_get_(foreground|background)() are now returning a GeglColor.
- libgimp: PDB functions named similarly in libgimp are returning a newly
allocated GeglColor too.
- A few other PDB functions (the ones using these functions) were updated and
their signature changed to use GeglColor too, when relevant. Plug-ins which
use any of the changed libgimp functions were fixed.
- GimpContext: signals "(foreground|background)-changed" are now passing a
GeglColor.
- libgimpconfig: new macro GIMP_CONFIG_PROP_COLOR using gegl_param_spec_color().
- GimpContext: properties "foreground" and "background" are now GeglParamColor
properties.
- app: All code interacting with GimpContext objects were updated to receive a
GeglColor (that they may still convert, or no, to GimpRGB for now).
- app: gimp_prop_gegl_color_button_new() was added as an alternative to
gimp_prop_color_button_new() when the property is a GeglParamColor. Eventually
the former should replace completely the latter.
- libgimpwidgets: gimp_prop_color_area_new() now works on GeglParamColor
properties only.
- libgimp: gimp_procedure_dialog_get_widget() will generate a GimpColorArea for
GeglTypeParamColor arguments.
Also the color is internally stored as GeglColor, though there are still get
APIs and signals using GimpRGB.
The equivalent PDB functions are also changed to use GeglColor, same as app/
functions.
This is a first commit to really getting rid of GimpRGB within core and
PDB/plug-in code. This will make color conversion reliability a lot better as
GeglColor will handle conversions for us. The goal is that we should keep origin
color space (for instance when picking colors in a GimpPickable, or when storing
in the FG/BG colors or in paletters) until the last second and convert at use
only.
It's still very much work-in-progress.
Resolves#10802.
Since the GimpProcedureDialog port, the Windows version
of the Screenshot plug-in has been missing the
"Screenshot Delay" option. This is because Windows did not
have the SCREENSHOT_CAN_DELAY_WINDOW_SHOT enum
set. Adding that back in restores the option.
After ab626e79, Script-Fu v3 now has the
SF-OPTION parameter again. This patch
ports a few scripts that use it or were
not otherwise covered by other merge
requests.
Note that further improvements are
necessary to allow these to work on
multiple layers simultaneously.
For version 3 scripts, using script-fu-register-filter
Widgets for SF-OPTION and SF-DIRNAME
Fixes#9992
Test case is Sphere v3.
Note that SF-VECTORS is still not supported,
until there is a VectorsChooser widget in libgimp.
A step towards deprecating old-style scripts using script-fu-register,
and deleting script-fu-interface, the duplicate dialog for SF.
But we still need to change or replace script-fu-register (for non-filter plugins)
to use GimpProcedureDialog.
Add tests of context stack ops.
Add test of paint methods.
Test convert to all precisions.
Test paint dynamics.
Test PDB as database.
Test PDBProcedure methods.
Test display methods.
Test drawable operations.
While the script is made aware of multiple selected layers,
it still only works on the top selected layer.
Mnemonics were also added to the GUI fields,
and an unused "type" parameter was removed.
MINGW64
- uses 0x601 as value for _WIN32_WINNT. No need for us to define
it to that value or even lower values in some places.
This also gets rid of: warning: "_WIN32_WINNT" redefined
- has 0x0502 for WINVER, so get rid of us setting it to 0x0500 in
gimp-app-test-utils.h. It also seems that the need to use G_OS_WIN32
has disappeared here.
- DIRECTINPUT_VERSION is 0x0800, no need for us to set it to that value.
- AI_ADDRCONFIG was apparently missing from the MINGW headers in the
past, but not anymore.
Resolves#10651
The "Remove All Guides" script calls
gimp-image-find-next-guide, which per
its description can take in 0. However,
the parameter sets 1 as the minimum
value.
This patch fixes the range so that it can
accept 0, which enables the Remove All
Guides script to work again.
It also updates the script to the new
multi-layer aware API.
Resolves#10530.
In GTK2, setting a window's scrollbar policy to GTK_POLICY_NEVER
hid the scrollbars. In GTK3, this also makes the window automatically
resize to fit the contents. Since ImageMap displays the full drawable
with no scaling, this caused the plug-in window to be very large for large
layers.
GTK_POLICY_EXTERNAL in GTK3 works the same as the GTK2 version of
GTK_POLICY_NEVER, so using it instead fixes the problem.
The default width and height magic numbers were also replaced with
constants.
- file-psd, sig[4] and block_len variables are initialized to stop uninitialized warnings
- file-xpm, g_file_peek_path () is cast to (char *) to stop "discarded const" warnings
- gimpconfig-serialized.c, %llu is used instead of %lu to stop overflow warning
During the API port, the Map Object
plugin had some parameters added and
others changed to GimpChoice strings.
This broke the Spinning Globe filter which
called on the map-object plugin.
This patch updates the procedure call and
fixes ranges in the map-object plugin so
spinning-globe works again,
but larger scope warnings persist.
No functional change.
I did this while chasing #10590 and #10591
The refactoring moves replicated code into functions.
So readers can understand better without having to compare sections
of replicated code.
The comments also highlight issue #10590.
Use g_connect_signal_swapped for "resource-set" signal from Resource Choosers,
to match the signal handler expecting "callback data" in the first arg.
Otherwise the first arg is the object emitting the signal.
Resolves#10611.
In GTK3, GtkRadioButtons are set using the "active" property
rather than selected, so the callback needed to check the
GTK_STATE_FLAG_ACTIVE flag instead of GTK_STATE_FLAG_SELECTED
when changing grid types.
The code was also reformatted to match current coding style.
- To set color values in the 0-255 range we now have to use set_uchar.
- Because setting a default color is not working, the color in config
could be None, which if the color wasn't changed caused a CRITICAL.
Let's check for None and if that is the case then manually set our
default color.
When cancelling foggify we get the following error:
AttributeError: 'GimpProcedureConfig-python-fu-foggify' object has no
attribute 'end_run'
The end_run function was removed a while ago, so just remove this line.
The grid state was not correctly updated when changed from within the
grid settings dialog.
Instead of using g_simple_action_set_enabled we need to use
g_simple_action_set_state, since we don't want to change whether the
action is enabled or disabled, but the checked/unchecked state.
Previously, the console's font color was hardcoded to #006000.
This did not stand out well on darker theme.
This patch pulls the widget's foreground color from GtkStyleContext
to ensure it contrasts sufficiently with the console background color.
- Fix "no icons" errors generating loaders.cache with .cmd (CI-Cross).
! This is a sub-optimal fix, but it's better than a useless build.
- Fix "no interpreter" errors generating .interp with Meson (CI-Native)
and generating .interp and copying .typelib with .cmd (Local-Native).
! This is a sub-optimal fix to Local-Native, but plug-ins will work.
- Fix "no iso" error copying iso_639.xml with Meson (Local-Native).
Resolves#10537.
During the port, the "green_invert" variable
was repeated twice rather than using the
"blue_invert" variable. This prevented the
fractal from updating when blue was changed.
Our handling of Photoshop's Blend Clipped Layers as Group is flawed
causing the order of layers to be messed up which may cause certain
parts of the image to become invisible or having the wrong colors.
This only fixes the incorrect layer ordering. Correct handling of
group layers with clipping needs a more extensive rewrite.
This is a manual revert of eac1df4b61
since other changes were made to the same lines.
Although using legacy layer modes for several blend modes improves
compatibility with Photoshop, we found out during testing of the
image from issue #10498, that it negatively impacts loading of PSD's
that use Blend Clipped Layers as Group.
We convert this specific PSD setting by adding a layer group and
setting Composite Mode to Blend to Background.
However, our legacy layer modes do not support Composite Mode, meaning
that PSD's using this can show up using smeared colors.
Since this hasn't been in a release yet, let's revert this and rethink
how we want to handle the combination of these PSD settings.
Resolves#9933.
We used png_get_valid (pp, info, PNG_INFO_tRNS) to check if
an indexed PNG had transparency when exporting.
However, this function does not return TRUE/FALSE but instead
the contents of that PNG chunk. Since we use index 0 for transparency,
this function always returns 0. The non-transparent indexed export code
ran regardless, creating incorrect PNGs.
We set pngg.has_trns earlier if the image has transparency, so it's safer
to use this variable instead.
Magic number 1 changed to 2 in one place. Missed in earlier fix for #10127.
Changed magic number to a defined macro constant so it might not happen again,
should GimpConfig change again.
Substantive change is call gimp_item_get_by_id instead of gimp_drawable...
And a few type changes from GimpDrawable* to GObject*.
Lots of renaming of functions, substituting "item" for "drawable."
Update comments.
Made one function static that was already private.
Fix the test case gimp_vectors_set_selected
Add more tests
Enhance testing framework, add function assert-PDB-true
Enhance some tests: make test files order independent
Fix tests broken by recent changes to GIMP
Some 2.10 modes, even in perceptual space, don't produce the same
result as PS. Now, the mapping table takes this into account, which
avoids surprises for the user.
The mapping table was generically indicating 2.10 modes as first choice,
which was resulting in terrible PSD compatibility in some cases. This
commit fixes this using legacy modes verified with latest PS version
(see attached files in MR).
Comprehensive rewrite of the DDS import routine, in the interest of
easier maintainability and readability. Adds formats.c/h, containing
tables and functions related to reading and parsing uncompressed files.
Importer now supports nearly all non-video uncompressed formats.
Includes a variety of minor-to-moderate fixes made along the way
which could not be pulled out into separate commits due to dependence
on other aspects of the rewrite.
Resolves#10454.
When porting to GimpProcedureConfig, all
light types were set to "Point" when 2 - 6
should have been "None" by default.
This patch fixes the defaults.
1. Recent changes to arg validation reveal bug in call to gimp-drawable-edit-gradient-fill,
supersampling arg must be >0
2. Make easier for testers to invoke by reducing the declared drawable capability
to SF-ONE-OR-MORE-DRAWABLE
Now use gimp-resource-delete
Drive-by fix of bad call to gimp-context-set-pattern.
Fixes other calls to gimp-font-delete, etc. in a test script.
Partly fixes 9867.
Per the official format specification and hardware implementation,
BC1 cutout pixels are always black with 0 alpha, whereas previous
versions of the plugin interpreted them as white. Commit f97e718e
partially fixed this, but made the behavior an import option that
also ignored the alpha component. This commit reverts the addition
of this option in favor of consistently following the spec.
The export properties "save-type" and "mipmaps" were left as ints
in Commit 427130be due to uncertainty on whether options could be
conditionally disabled on GimpChoice properties. From testing it
this functionality appears to work fine and is used in other plugins.
Now all combo props are GimpChoices and fully configurable from dds.c
Moves most of the code relating to YCoCg and Alpha Exponent into
misc.c/h, in the interest of making the rest of the codebase cleaner.
Removes the decode option from the import menu, as encoded files are
always decoded now (there used to be a menu button for doing this
after import, but with it gone there's no reason ever to not decode).
Finally, the remaining functions in color.c were only ever called once,
so these were extracted and inlined, and the empty file deleted.
Partial refactor of parts of ddsread to better handle DX10+ files.
Though not included here, this is necessary to import formats that
have no DX9 equivalent, namely BC6H and BC7, as the current handling
simply downgrades DX10 files and imports them like DX9 ones.
Extensive formatting and cleanup in the read-write files, and addition
of some comments where they seemed appropriate. Renamed a couple of
single-letter variables to be more descriptive.
Also removed an unnecessary global variable in ddswrite.c, and made
the "config" variable in ddsread a GimpProcedureConfig type, as was
previously done for ddswrite.
Fixes two major issues with mipmap generation, namely sRGB transforms
being applied both backwards and in 8-bit precision, causing severe
color degradation. sRGB transforms are now handled correctly and all
mipmap generation is done at 32-bit floating-point precision.
A new cubic filter has also been added (Catmull-Rom) which rounds-out
the existing lineup of cubic filters.
Also includes extensive code cleanup (sorry I couldn't separate this)
to mipmap.c/h and color.c/h
Recently some extra input validation was added, which caused the
gimp-image-set-selected-layers command in script-fu to fail with an
invalid value for argument 2.
This is caused by the object array contents always being set as
GIMP_TYPE_DRAWABLE, while the actual type may be a layer, etc.
So, let's set the actual type of drawable being used here by using
G_OBJECT_TYPE on the first data element.
These were using gimp_procedure_new, which was causing warnings like
LibGimpConfig-WARNING **: 13:56:33.270: couldn't serialize property
GimpProcedureConfig-plug-in-metadata-editor::image of type GimpImage,
and
gimp_plug_in_destroy_proxies: ERROR: GimpImage proxy with ID 1 was
refed by plug-in, it MUST NOT do that!
This also saves us from having to define image and run-mode parameters
ourselves.
We remove two warnings:
1. warning: format '%ld' expects argument of type 'long int', but
argument 5 has type 'GType' {aka 'long long unsigned int'}
Since GType is gsize, and this is not used in translations, use format
specifier G_GSIZE_FORMAT.
2. warning: enumeration value 'SF_IMAGE' not handled in switch (and more
similar ones).
Add a default block to let the compiler know we handle all values.
Currently we only use and retain "critical" PNG chunks,
discarding any safe-to-copy but non-image chunks.
This adds code to store them as parasites and then
include them on export, thus preventing loss of data.
when loading a BMP image with an invalid compression value.
The invalid compression check was missing a goto out (error exit)
causing the GError to be overwritten, which caused a GLib warning.
We add the missing goto statement here.
Overwriting a GIF animation results in loss of frames if a previous export turned off
animations.
This sets a parasite on import which we check for on overwrite. If it was an
animation originally, we overwrite as an animation as well.
This adds an import option for DDS DXT1/BC1 images to always use
transparency. This is the default behavior, since this was what always
happened until now and it seems that DDPF_ALPHAPIXELS is very rarely
set for these type of images.
However, as the mentioned issues explains, advanced compression
algorithms can use this transparency data instead to mean a black
pixel. There is however, no certain way to determine this.
For that reason, we add an option here, that, if disabled, will
interpret fully transparent values as a black pixel.
Some games apparently need dds images to be vertically flipped.
We already have an option to flip dds images on export, so it makes
sense to also allow flipping on import.
In addition to the requested DXGI variants we also load the older
D3DF versions, including handling of the signed versions.
We also set signed when the pixelformat flag DDPF_BUMPDUDV (added in
the previous commit) is set.
This adds support for loading RGBA DDS images with 16- and 32-bit per
channel. Loading is supported for 16-bit half float, 32-bit float,
16 and 32-bit unsigned and signed int.
This supports both the DX10 formats and the D3D FOURCC versions.
16- and 32-bit per channel images with less than 4 channels are not
yet supported.
When saving a PDF, you have the option to export layers as pages.
This works for a single layer group that contains multiple layers.
However, the option is disabled because the plug-in only checks
"top level" layers.
This patch adds code to check if the single layer is a layer group,
then enables the option if there are more than one layer in that group.
This completes commit 685c8bde99 where the http:// scheme was automatically
transformed into https:// in some cases, in particular while typing (when
pasting for instance, it was still possible to add an http URL). So let's block
"toggled" signal handlers when the URL is explicitely edited to prevent this
annoying issue.
(cherry picked from commit b991f8b361)
While exiv2/gexiv2 could be able to load metadata from JXL files
directly, success is not guaranteed (depends on version and
configuration, for example support could be disabled or compressed
metadata could not work).
Loading metadata via libjxl should work all the time.
It is also important not to display dialog to rotate the image
according the orientation from EXIF, because in case of JXL,
the orientation is stored in codestream and it has priority.
Certain dds images can have non-zero unexpected pitch_or_linsize values.
Until now we were only computing this ourselves in case it was zero.
Let's just always compute it and print an error to the terminal if it
differs from the value in the file.
A sample can be found in Galactic Civilizations 3: Bokeh_Hex.dds.
This change also allows us to safely load the poc in security issue
ZDI-CAN-22093 as that issue was apparently only caused by an invalid
value of pitch_or_linsize.
Optimize dds loading a bit by moving code that doesn't change outside
the loop:
1. The number of bits to be shifted when the source isn't exactly 8 or
16 bits depends on bytes per sample and isn't changing inside the loop.
2. Use rowstride variable to compute width * d->bpp once.
3. The check for rowstride > hdr->pitch_or_linsize doesn't change
inside the loop so move it out.
Inside the loop we only check the DDSD_PITCH flag once and move both
the size check and the fread check inside it.
There were 2 issues here:
1. When more than 8 bits per sample are used, a previous commit changed
it so that we would be using 16-bit integer mode instead of 8-bit.
However, the actual code for this specific format was not updated to
reflect that.
We fix this by computing 16-bits per channel values and upshifting the
10 and 2-bit samples to 16 bit per channel.
2. The computation of masks was incorrect. It computed each channel
mask separately, based on whether it was <= 8 or not.
However, if any channel needs more than 8 bits, all masks should be
computed 16 bits since we will then 16-bit integer mode.
We fix this by checking all channel bits together, and if any is higher
than 8, but not more than 16, we use 16-bit masks.
I also took this opportunity to add support for 32-bit masks if we
ever need those.
@Wormnest noted remaining regressions after 8faad92e.
The second fread() only runs if the DDSD_PITCH flag is set,
so the error handling check should also be conditional.
Additionally, the ZDI-CAN-22093 exploit no longer runs but
still could cause a plug-in crash. This patch adds an additional
check to ensure the buffer size was within bounds.
@Wormnest pointed out that compressed files are likely smaller than
width * height * bps, so our check to prevent ZDI-CAN-22093
also caught valid files.
The size check is removed from load_image () and moved to load_layer ()
before the two fread() functions, as we know exactly how much we'll
try to read at that point.
...by adding parameters and porting to
GimpProcedureConfig/GimpProcedureDialog.
Code was also rearranged to match the ordering
of other plug-ins.
As a note, the help message is "Special effects that nobody understands".
It would be nice if someone with more familiarity with this plug-in could
update the help messages to explain the parameters.
Note that "save-type" and "mipmaps" were left as ints rather than GimpChoice,
as some options are conditionally disabled and I don't know if that
is available in GimpChoice just yet.
A DDS loading bug related to 6ad54ca3 was also resolved.
The correct header value to check for the pixel size was not "depth" but "bpp".
I also remove (without replacement) 2 usages of gimp_get_data() without
associated gimp_set_data(). According to the comment, it looks like the
associated data was likely set by the GAP plug-in instead. Let's drop this.
Finally I see a lot of arguments, several of them being float arrays, so I
wondered if they were related to the curve and point arrays we are storing as
aux arg now. Apparently these arguments are not even used in the plug-in, right
now, which is explained in commit e318651c99. Maybe if these were actually
used/set and if we implement float array (de)serialization, would this aux
argument become useless?
Lastly, I deleted some code paths which were never used. For instance, stored
bval.total_steps was never set to anything else than 0 anywhere (so I removed
both the variable and the other code-path, which actually ended up being the
GAP-related data get). Additionally in p_bender_calculate_iter_curve(), there
was a big else block which was only happening when the GAP-related variables
were set. It got deleted too (as is a function only used in this block of code).
The argument is the serialized description of the generated fractal. Actually it
may even be useful as a non-aux argument. A GFile argument could eventually be
interesting too, though one arg per setting would be better of course (it allows
more easily to generate animated frames for instance). In such a case, the GFile
would be used in priority, otherwise the other args.
Notes:
* I didn't port to GimpProcedureDialog though it looks like it would not be too
hard (most of the GUI would still be custom GTK code, yet we could have the
generic "reset to initial|factory values" buttons and load/save).
* The custom "Reset" button (identical to what "reset to factory values" would
do) works fine anyway.
* The "run with last vals" works fine where there were indeed previous runs
(which may be in previous sessions), but crashes when it's actually the first
run ever. Some of the base structure data were not initialized. It should not
be too hard yet would require a bit of code reorganization to fix this.
- Argument "parameter-uri" becomes "parameter-file" (GFile instead of URI
string).
- Adding a "settings-data" auxiliary bytes argument to handle all settings for
the time being, instead of using gimp_get_data() and gimp_set_data().
- "last_file_name" was also removed from the ValueType struct, using the
"settings-data" arg instead.
- Fixing the non-interactive usage which was missing a gegl_init() call.
- Use GIO for various reading and writing to a CML parameter file.
- Better bubbling up of error messages.
- Fix the loading of the last section of CML parameters file.
- Also fixing deactived file dialog when clicking the open button a second time.
We use a GBytes auxiliary argument (i.e. not visible in the public API) which
perfectly replace gimp_[gs]et_data() API, in even better (since it also works
across sessions).
The "Reset to initial values|factory defaults" still don't work. We could make
these work even with the AUX args, but I feel like this would be far too much
work for a non-optimal solution anyway. The real solution can be when we get
more public arguments to this PDB procedure to handle every setting
individually. This can happen after GIMP 3 release (especially now that
arguments number and order don't break the PDB API anymore).
I added a bunch of arguments, in particular nearly all the settings in the main
dialog, except for "Colormap" as I'm unsure yet how to handle it. It looks like
a mix of GimpChoice and GimpDrawable. I guess it could just be both (2 args,
using values from the GimpChoice if GimpDrawable arg is NULL).
And I didn't make the settings in the "Edit Flame" dialog into arguments as I'm
not sure if the "Speed" and "Variation" in particular should be args, or are
just temporary args only meant to construct a flame (in particular, it looks
like it builds data defining the flame?). These data should be their own args
probably?
Maybe we could also have the "file" as alternative way to init the flame data
(the "Open" button)?
For now, I'm just storing the whole settings struct as an aux argument, so that
"Load/Save Settings" work, as well as the initial values from previous run.
Also the whole code is still a bit of a mess. I feel like we could really
simplify a lot of the code, all these values stored globally or duplicated now
in both the GimpProcedureConfig and the control_point structure.
I added a few specific validations for range types (int, double…), and a
generic validation at the end, meant to catch all yet uncaught invalid
argument cases (yet with less details on the what and why).
These are stored in the Extended Block. This block also holds metadata
in Exif, IPTC, and XMP formats, but those are not yet implemented in this
patch. A comment stating Exif was implemented in PSP 10 was corrected
to PSP 8 as well.
Changes only to ScriptFu.
The third term (the default) of a SF-FONT etc. spec is now ignored.
Test case is SF>Test>Sphere. There are still crashing issues
related but separate.
If we leave a space between the macro name and opening parenthese for argument
lists, the args are not considered macro args (which will be discovered when
using it). I experienced this issue while testing code on some plug-in
yesterday, so thought I might as well fix all these broken macros for casting to
the specific GimpPlugIn subclass, so that we won't have a next time.
The gimp_procedure_run() already existed, though it was with an ordered
GimpValueArray array of arguments. Its usage feels redundant to the series of
gimp_pdb_run_procedure*() functions (which is confusing), but
gimp_procedure_run() was actually a bit more generic, because it does not
necessarily calls GimpProcedure-s through the PDB! For instance, it can runs a
local GimpProcedure, such as the case of one procedure which would want to call
another procedure in the same plug-in, but without having to go through PDB. Of
course, for local code, you may as well run relevant functions directly, yet it
makes sense that if one of the redundant-looking function is removed, it should
be the more specific one. Also gimp_procedure_run() feels a lot simpler and
logical, API wise.
A main difference in usage is that now, plug-in developers have to first
explicitly look up the GimpPdbProcedure with gimp_pdb_lookup_procedure() when
they wish to call PDB procedures on the wire. This was done anyway in the
gimp_pdb_run_procedure*() code, now it's explicit (rather than calling by name
directly).
Concretely:
* gimp_pdb_run_procedure(), gimp_pdb_run_procedure_config() and
gimp_pdb_run_procedure_valist() are removed.
* gimp_procedure_run() API is modified to use a variable args list instead of a
GimpValueArray.
* gimp_procedure_run_config() and gimp_procedure_run_valist() are added.
* gimp_procedure_run_config() in particular will be the one used in bindings
which don't have variable args support through a (rename-to
gimp_procedure_run) annotation.
Passing (name, type, value) triplets is actually useless because we can get the
type information from the procedure/config anyway. That only adds one more
verification to do. Let's just change the function so that we pass (name, value)
couples instead, pretty much like in `g_object_set()`.
As far as plug-in API is concerned, at least the calling API, order of arguments
when calling PDB procedures doesn't matter anymore.
Order still matters for creating procedures with standard arguments (for
instance, "run-mode" is first, then image, or file, drawables or whatnot,
depending on the subtype of procedure), but not for calling with libgimp.
Concretely in this commit:
- gimp_pdb_run_procedure_argv() was removed as it's intrinsically order-based.
- gimp_pdb_run_procedure() and gimp_pdb_run_procedure_valist() stay but their
semantic changes. Instead of an ordered list of (type, value) couple, it's now
an unordered list of (name, type, value) triplets. This way, you can also
ignore as many args as you want if you intend to keep them default. For
instance, say you have a procedure with 20 args and you only want to change
the last one and keep the 19 first with default values: while you used to have
to write down all 20 args annoyingly, now you can just list the only arg you
care about.
There are 2 important consequences here:
1. Calling PDB procedures becomes much more semantic, which means scripts with
PDB calls are simpler (smaller list of arguments) and easier to read (when
you had 5 int arguments in a row, you couldn't know what they refer to,
except by always checking the PDB source; now you'll have associated names,
such as "width", "height" and so on) hence maintain.
2. We will have the ability to add arguments and even order the new arguments in
middle of existing arguments without breaking compatibility. The only thing
which will matter will be that default values of new arguments will have to
behave like when the arg didn't exist. This way, existing scripts will not be
broken. This will avoid us having to always create variants of PDB procedure
(like original "file-bla-save", then variant "file-bla-save-2" and so on)
each time we add arguments.
Note: gimp_pdb_run_procedure_array() was not removed yet because it's currently
used by the PDB. To be followed.
Similar to commit 6905b0bbef for "file-pat-save-internal". For interactive
usage, nothing is changed, but for non-interactive ones, we can now choose a
list of drawables to export.
Pending more changes, relative to the discussion in #7370.
This goes with our planned change of not making GimpProcedure arguments order
relevant anymore regarding the PDB API. In particular, it means we don't want to
use GimpValueArray for various procedure arguments API, but directly
GimpProcedureConfig objects.
This change will allow to add or reorder arguments in the future, so that we
won't have to create new PDB procedures when adding new arguments, while still
keeping PDB API stability.
Add Border enlarges an image by twice the specified border size and creates the border in this
additional space. If an image already has the intended final size, this behaviour is not desired.
This change adds a toggle to (dis)allow resizing, similar to the drop shadow script.
This came up in a reddit thread by /u/rapidexchange
https://www.reddit.com/r/GIMP/comments/6csofx/im_new_to_gimp_so_sorry_if_this_is_a_stupid/
Adds code to read in PSP_SELECTION_BLOCK.
If there was an active selection in the PSP file when it was
saved, that selection will now be active in GIMP as well on load.
Improper counting of args declared by scripts versus pspecs in a ProcedureConfig.
Scripts don't declare run_mode, while pspecs have run_mode and an extra internal pspec
that is not an argument.
bootchk had the case in commit 6781a35668. I again had it with gfig. I think it
just makes sense to init GEGL, especially as the errors are not that explicit
and that the plug-in code may not even call GEGL code directly (so it makes it
harder to guess).
After the recent port.
* contrast-retinex: Initialize format & src_buffer to NULL
* curve-bend and map-object: Remove no longer needed functions
* file-load-gif: Fix C++ style comment
Resolves#10119.
If the user sets the "Image Spacing" and "Hole Width" values
to 0, the hole creation code gets stuck in an infinite loop.
This patch adds a check to the allocation code for the hole
to make sure both its dimensions are greater than 0. If not,
then the hole is not created in the first place.
If the GIF has a value other than 0 or 49 in its PixelAspectRatio
header, then we now use it to set the non-square pixel resolution.
For reference, GIFs calculate this value like so:
PAR = (Value + 15) / (float) 64.
- Fonctions were renamed: s/gimp_text_fontname/gimp_text_font/ and
s/gimp_text_get_extents_fontname/gimp_text_get_extents_font/
- The size_type arguments were removed. Even in 2.10, this argument was marked
as "dead" and ignored. It was only kept for API compatibility.
- The font name (string) was replaced by a GimpFont argument.
gimp_text_font() is easily tested in the Python console with:
> Gimp.text_font(Gimp.list_images()[0], None, 10, 40, "Hello World!", 1.0, True, 100, Gimp.context_get_font())
And gimp_text_get_extents_font() with:
> Gimp.text_get_extents_font("Hello World!", 100, Gimp.context_get_font())
Hardcoded colors don't work well with theme customization (on a dark theme in
particular, it was bad).
Anyway built-in units are already grayed-out and non-editable. I don't think
further styling is needed.
… function gimp_font_get_pango_font_description().
Also updating file-pdf-save which is the only plug-in using these right now.
Note that I am not fully happy with the new function
gimp_font_get_pango_font_description() because I experienced some weird behavior
in file-pdf-save which is that some fonts were wrong if this is called after
pango_cairo_font_map_set_resolution().
But let's say this is a first step looking for improvements.
...and to GimpProcedureDialog.
Also resolves#25 by adding the missing PDB parameters to the GUI.
Note that there are a few remaining tasks:
* The config values are being copied to mapvals.
Eventually the rest of the code needs to be updated
to directly use the config.
* The material tab uses icons from the Lighting plug-in. They didn't show up before the port; this needs to be fixed.
* The drawable buttons are huge compared to the original plug-in. The styling needs to be looked at.
Converted to GimpProcedureDialog as well, and changed the
string argument for the combobox to GimpChoice.
Some widgets are still standalone and could be further improved
to work with GimpProcedureDialog.
A new aux parameter for upper/lower border area was added so this could be generated
as part of the GUI.
I received warnings about serializing the FloatArray and GBytes parameters, so I did not integrate
the existing variables with GimpProcedureConfig in this current version.
The only missing feature is that we don't constrain the various argument
drawables to RGB/grayscale or to the same dimension as the input drawable. This
could actually be quite easily implemented, either through a set of constraint
flags, or a more flexible callback function (similar to the API of
gimp_drawable_combo_box_new()). It could either be implemented on the argument
level (which has the advantage of letting libgimp handle argument sanity of
plug-in developers, even in non-interactive calls, with generic error messages)
or within the new GimpDrawableChooser API.
I was actually implementing this when I realized that this plug-in works fine
even with images of different dimensions. As for the format, GEGL handles format
conversion automatically. There is absolutely no reason to limit ourselves.
So let's drop this feature for now, because we should not over-engineer. If it
turns out useful and we get requests, we can always create later either a
specialized arg macro GIMP_PROC_ARG_CONSTRAINED_DRAWABLE() or a method to
specialize the widget with gimp_drawable_chooser_new_constrained() for
instance).
A few minor code style issues were also fixed.
Note that there's only one procedure parameter (Preset name),
but it's not retained between runs.
I want to ask about this before making a full conversion to
GimpProcedureDialog widgets.
This name was really irking me because it's not a button (anymore? Maybe it used
to be just a button). Depending on the specific widget, it will have several
sub-widgets, including a label. And it can theoretically even be something else
than a button.
So let's just rename these widgets with the more generic "chooser" name.
- Increase the default size to 40x40 and multiply it by the current window scale
factor to have decent preview size.
- Make the brush preview always square with a GtkAspectFrame: even though
brushes are not necessarily square, this is a much more obvious size rather
than letting GTK choose a random allocation size which ends up very weird
looking.
- Scale down the brush to the biggest possible dimensions which fit the square
preview area (if the brush native size is already smaller, I don't scale up
though) while keeping aspect ratio: previous implementation was really weird,
as we were only seeing a tiny corner of much brushes as we weren't scaling
them down. Obviously I use new gimp_brush_get_buffer|mask() functions for
this as it supports scaling.
- Implement drawing color brushes too: the previous implementation was only
drawing the brush mask, which was absolutely not what would be expected for
such brushes.
- Add a white background behind color brushes with transparency.
- Simplify and clean up the code.
One of the consequences of this new implementation is obviously that it's
mandatory to call gegl_init() when using this widget.
- Move the property widget functions for GimpResource properties into a new
libgimp/gimppropwidgets.[ch] file. This mirrors the files
libgimpwidgets/gimppropwidgets.[ch] which are for more generic property types.
- Rename the functions gimp_prop_chooser_*_new() to gimp_prop_*_chooser_new().
- gimp_prop_chooser_factory() doesn't need to be public.
- Add a label to GimpResourceSelectButton, make so that the
gimp_prop_chooser_*_new() functions set the property nick to this label and
add this label to the size group in GimpProcedureDialog.
- Removing useless or redundant code.
- Simplifying various logics.
- Using GimpResource directly in temporary PDB procedures, not resource names.
- Better cleanup of the core resource chooser when the plug-in dialog quits (we
need it to ask core to close also any visible resource chooser dialog).
- Replace the "Close" button by more common OK/Cancel. In particular, the
GimpPdbDialog now properly keeps track of the initial object and when hitting
"Cancel" (or Escape key), this initial object is set back.
- Clean up some of the comments, especially when the code is self explanatory.
There is still much more to clean and improve, but it's a first welcome step.
One instance of `(GIMP_VALUES_GET_INT (args, 0)` was missed during the initial conversion.
This caused a compiler error. The value is now retrieved from the GimpProcedureConfig
object.
Having windows ID as guint32 is a mistake. Different systems have
different protocols. In Wayland in particular, Windows handles are
exchanged as strings. What this commit does is the following:
In core:
- get_window_id() virtual function in core GimpProgress is changed to
return a GBytes, as a generic "data" to represent a window differently
on different systems.
- All implementations of get_window_id() in various classes implementing
this interface are updated accordingly:
* GimpSubProgress
* GimpDisplay returns the handle of its shell.
* GimpDisplayShell now creates its window handle at construction with
libgimpwidget's gimp_widget_set_native_handle() and simply return
this handle every time it's requested.
* GimpFileDialog also creates its window handle at construction with
gimp_widget_set_native_handle().
- gimp_window_set_transient_for() in core is changed to take a
GimpProgress as argument (instead of a guint32 ID), requests and
process the ID itself, according to the running platform. In
particular, the following were improved:
* Unlike old code, it will work even if the window is not visible yet.
In such a case, the function simply adds a signal handler to set
transient at mapping. It makes it easier to use it at construction
in a reliable way.
* It now works for Wayland too, additionally to X11.
- GimpPdbProgress now exchanges a GBytes too with the command
GIMP_PROGRESS_COMMAND_GET_WINDOW.
- display_get_window_id() in gimp-gui.h also returns a GBytes now.
PDB/libgimp:
- gimp_display_get_window_handle() and gimp_progress_get_window_handle()
now return a GBytes to represent a window handle in an opaque way
(depending on the running platform).
In libgimp:
- GimpProgress's get_window() virtual function changed to return a
GBytes and renamed get_window_handle().
- In particular GimpProgressBar is the only implementation of
get_window_handle(). It creates its handle at object construction with
libgimpwidget's gimp_widget_set_native_handle() and the virtual
method's implementation simply returns the GBytes.
In libgimpUi:
- gimp_ui_get_display_window() and gimp_ui_get_progress_window() were
removed. We should not assume anymore that it is possible to create a
GdkWindow to be used. For instance this is not possible with Wayland
which has its own way to set a window transient with a string handle.
- gimp_window_set_transient_for_display() and
gimp_window_set_transient() now use an internal implementation similar
to core gimp_window_set_transient_for(), with the same improvements
(works even at construction when the window is not visible yet + works
for Wayland too).
In libgimpwidgets:
- New gimp_widget_set_native_handle() is a helper function used both in
core and libgimp* libraries for widgets which we want to be usable as
possible parents. It takes care of getting the relevant window handle
(depending on the running platform) and stores it in a given pointer,
either immediately or after a callback once the widget is mapped. So
it can be used at construction. Also it sets a handle for X11 or
Wayland.
In plug-ins:
- Screenshot uses the new gimp_progress_get_window_handle() directly now
in its X11 code path and creates out of it a GdkWindows itself with
gdk_x11_window_foreign_new_for_display().
Our inter-process transient implementation only worked for X11, and with
this commit, it works for Wayland too.
There is code for Windows but it is currently disabled as it apparently
hangs (there is a comment in-code which links to this old report:
https://bugzilla.gnome.org/show_bug.cgi?id=359538). NikcDC tested
yesterday with re-enabling the code and said they experienced a freeze.
;-(
Finally there is no infrastructure yet to make this work on macOS and
apparently there is no implementation of window handle in GDK for macOS
that I could find. I'm not sure if macOS doesn't have this concept of
setting transient on another processus's window or GDK is simply lacking
the implementation.
...and to GimpProcedureDialog.
selection-to-path-dialog.c was also removed as the code can now be contained
within selection-to-path.c thanks to the new API.
The various information (width, height, image type and number of layers) are
those of the full image, not of the thumbnail. Make it clear in the docs of
GimpRunThumbnailFunc.
Additionally:
- file-xmc was returning the proper information but variables were wrongly
named, which was confusing.
- Fix file-ico thumbnail proc which was returning the thumbnail width/height.
- In file-darktable, initialize width/height to 0 so that we just don't show any
size when we don't get the information. It's better not to show anything than
completely wrong information (the thumbnail target size).
We were choosing the bigger icon in the ICNS list. Instead let's choose the
bigger icon within the target size bounding box. In case there is no smaller (or
equal size) icon, we falls back to the smallest bigger icon.
Also make sure we set width and height to the full image size, as this is used
as information on the full image (not the thumbnail).
SVG is a vector format which is easy to render exactly within the size×size
bounding box. Let's make sure we do so.
This makes for much sharper SVG thumbnails (and also possibly faster thumbnail
render).
… than a GimpValueArray.
Similar to other GimpProcedure, move to using a config object. A difference is
that thumbnail procedures are always run non-interactively.
Also fixing WMF load thumbnail procedure: the dimension computation was wrong
when the image was wider than tall.
Also the palette argument is now a proper GFile argument (not a string).
There is also a palette argument for the export procedure, but it's currently
unused. A palette storing function will need to be implemented.
Some bit of additional logic cleanup was done.
Again, I am losing a tiny bit of UI, in particular the ratio fields, but also
the update of the size label (this was kinda broken anyway, as it updated only
when updating some fields, not others).
Also moving the default resolution to 300 PPI.
Last but not least, I transformed the "paths" int argument to a GimpChoice
argument.
The new dialog is not fully on-par with the old one. We lost the X and Y ratio
fields as well as the ability to constrain dimensions to each other. This should
be improved when we'll get proper automatically generated widgets for dimension
arguments.
Anders Jonsson