This is mostly an empty shell whose goal is to serve as base class for
specific dynamically generated per-operation subclasses, which will have
properties mimicking the arguments of the GEGL operation.
Most of the fundamental type args will just use the base GLib param spec
types instead of GEGL ones.
As a special case, the GeglParamEnum arguments are transformed into
GimpChoice param specs on libgimp side. The reason is that most of the
time, enum types are created within the scope of an operation code only
and cannot be properly reconstructed over the wire. I could just
transform these into an int type (which is mostly what is done in GEGL
right now when running an op with such arg), but GimpChoice allow much
nicer string-type args, which make much more semantic code. This class
was initially created for plug-ins, but it would work very well to run
GEGL ops on drawables. So let's do it.
Finally add a gimp_drawable_filter_get_config() to request the current
config of a filter.
Note that right now, we can't do much with this config object other than
observing an operation args and default values. Being able to update a
filter's settings will come up in further commits.
A few functions were added, but the main one is
gimp_drawable_get_filters() to request the list of filters applied
non-destructively on a drawable. We can't do much with these for the
time being, but this will come.
WIP.
Makes the Dock icon only appear when a script plugin has a dialog.
Unfortunately, on MacOS where "transient for" doesn't work,
we need a Dock icon for the separate process so user can "Show window."
See #12150
Done at runtime.
A build-time alternative is: package script-fu binary in a bundle, and set properties.
Fixes both the new-style dialog (GimpProcedureDialog) and the old-style dialog (deprecated.)
The gimp app and extension-script-fu (long-running)
are separate processes and "apps."
An app can be "active": in front and receiving GUI events.
As reported, on MacOS, when an extension-script-fu plugin yields,
the gimp app did not become active.
Also, on the second invocation of a plugin served by extension-script-fu,
the dialog could be hidden or require an extra click
because extension-script-fu was not active.
(Independently interpreted plugins did become active,
because it was a new process and gimpui_init activates on MacOS.)
On MacOS:
1. after the first dialog shown by extension-script-fu,
ensure subsequent calls to plugin make extension-script-fu active.
2. After a plugin yields, plugin manager ensure the Gimp app is active.
Note that this is done whenever a TEMPORARY procedure returns.
Most are calls to extension-script-fu plugins.
But some are also callbacks from Resource choosers running in the gimp app.
When they return, the gimp app remains active, and user must first click in
the plugin dialog to continue working.
Especially when the user clicks OK in a Resource Chooser, closing the chooser,
it would be nice if the plugin dialog became active.
That requires more, FUTURE development.
Special to MacOS: on Linux, "transient for foreign window" ensures this,
but that doesn't work on MacOS.
The fix is somewhat brute force and as simple as possible.
There is a more cooperative API for app activation on MacOS.
An app yields, and apps request, not force, self or other app be activated.
The fix does not use the cooperative API.
To do so would require a platform abstraction layer, in GIMP or Gtk.
The fix also sprinkles the code with #ifdefs.
That could be hidden if there were a platform abstraction layer PAL
The layer would be the greatest common denominator across platforms.
PAL methods would always be called in GIMP code,
but not do anything when the effect was accomplished another way.
For example "gimp_platform_request_app_active"
would request the app was active,
but do nothing on Linux where that is ensured by "transient for."
Previously, just hanging a read, extension-script-fu missed GUI events
that closed dialogs on MacOS.
The fix is a proper event loop for a plugin that persists, reads, and has GUI:
calling gimp_plug_in_persistent_enable and a main_loop,
instead of gimp_plug_in_persistent_process.
The fix is not conditional on MacOS, but seems events missed only on MacOS.
The previous fix for MacOS, #6577, only works for old-style GUI (script-fu-interface.c).
That was not the best fix, and doesn't work for new-style GUI (GimpProcedureDialog).
If symptoms still appear in 2.10.38
(#12150 says dialogs dissappear but a dock icon has spinning ball)
this should be backported to 2.10.
Partially revert f0fb4435
It is safer to wait for Inno to compile successfully before deleting the
.bak langs, which are the condition to auto repairing.
Note: I reinforce that, despite the name, this doesn't look like Vista.
Following de556c0734
Microsoft use of bezel in Win32 and UWP/WinUI3 apps is inconsistent:
sometimes the bezel is there, others not. However, when displayed
the bezel never is that dark. So let's at least hide it, just how
we do in the Devel warning and Inno do in most dialogs.
SSE2 (not the first SSE) instructions are required since 2012 on Windows 8.
Our minimum requeriment for 3.0 series is 10 so Inno built-in 'MinVersion',
by consequence, implies requesting SSE(2) without needing a custom dialog.
Then, let's cleanup this, which will make us gain a few (milli?)seconds.
Just to note, SSE2 (again, not SSE) is required even on Win 7 (since 2018).
This makes the range handles for the Levels tool and other
auto-generated range widgets adapt to any theme color,
just like the Gradient Editor range handles currently do.
It is like a compiler warning, and should not be a full g_warning,
which should mean something will probably fail.
Passing fewer args is a feature since 3.0: the PDB will use defaults.
This provides us fine-grained info on how much time each step take,
making easier to spot stuckness and to quickly understand the logs.
'gimp' jobs normally do not take advantage on this due to log limits
(they expand and crop the log), so I adapted them to only output errors.
---
Also, to reduce logs, all jobs were reviewed with proper GIT_* variables.
We were unconditionally using the selected layers' drawable
when setting up the filter tool's dialogue. As a result, it
would use the wrong drawable as the dialogue thumbnail if a
different layer was selected while editing an NDE Filter.
This patch checks if we're editing an NDE filter, and if so,
uses its drawable instead.
While we want to allow a flexible range for the
Box and Cylinder dimensions when called non-interactively,
having a large range in the GUI makes it difficult for
users to precisely set those values.
This patch adds calls to gimp_scale_entry_set_bounds ()
to match the 2.10 GUI ranges, while letting the values be
larger then that when called via the PDB.
When opening an old XCF, we try to match the fonts specified in the text
layers (and the text tool) with the closest font (if the exact font isn't available).
This patch improves the matching heuristic a bit.
Based on suggestions from Michael
Schumacher in issue #12239.
Until we implement native file picker dialogues,
Windows users can't load images from
Windows shortcut (.lnk) files.
This patch adds a plug-in to open these
.lnk files, extract the path, then try to read
it in via gimp_file_load ().
Similar to file-compressor, the error
messages are suppressed in the GUI so that
users don't get error messages if they click
on a non-image shortcut in the file picker.
Only export 1-bit TIFF for black and white indexed images without alpha
channel. 1-bit TIFF with alpha has poor software support:
- GIMP: cannot read its own exported files
- macOS Preview: ignores MINISWHITE/MINISBLACK
- Windows Photo Viewer: shows as invalid image
- InDesign: ignores alpha channel
- tiff2rgba: fails to process
- Photoshop/Illustrator: corrupted rendering
Any font file path that's invalid utf-8, and/or any metadata (psname,
fullname, family...etc) that's not valid utf-8 should be skipped and not
passed to fontconfig.
This issue has eluded us for a long time and it was recently fixed in
Pango (MR pango!745). We can't bump the minimum requirement because of
our bookworm baseline for GIMP 3.0.0, but we can at least warn when
building for macOS.
We still want the normal GIMP_RELEASE C macro to be set because the
whole development frame should have code behaving like release code, yet
only for the AppStream metadata testing, we want to allow a "TODO"
release date while in +git code.
While not an "official" tupl type for PAM files, software such as
mutools can export CMYK PAM files. This patch adds support
for loading such images.
Note that PAM files do not include color profile information. In
the future, we might add an option to convert using a pre-defined
color profile for this and other formats like EPS.
The "AppImage platform" don't have releases, every tool is blending edge.
Obviously, it is too prone to broke, and for the first time it got broken.
So, let's move it to a separate job and with less frequency to not broke CI.
Two tests were consistently timing out before this change:
save-and-export and ui. The gdk_test_simulate_key documentation mentions that
gtk_test_widget_send_key is the right approach for most testing purposes.
With this change, save-and-export started working for me, whereas ui now fails
properly - investigating this failure was the original point of the change.
Closes#12518
Certain Sony camera's have MakerNote tags in the Exif.SonyMisc3c range.
When exporting with EXIF metadata included this causes a failure saving
the metadata, which means that no metadata at all is saved to the image.
For now, let's exclude these tags, so that all other metadata tags at
least will be saved.
We will keep an eye on exiv2 issue
https://github.com/Exiv2/exiv2/issues/2670
to see if the actual cause will be solved.
A lot of the custom brand makernote tags have interpreted strings
available, even though their type is set to Byte.
Since having those interpreted doesn't have any negative side effects
(real Byte values are correctly converted) let's not exclude these
tags for interpreted string conversion.
Note: the original workaround was superseded by: 9ab48164
The actual workaround (which adress the same issue) is being dropped since,
according to my tests, seems that the MSYS2 issue was fixed. See: #10782
Inspired by Mark Sweeney's work.
This patch passes the user-defined button
icon size from GimpDisplayShell to
GimpStatusBar, and updates the
Soft Proofing button and current tool
icon sizes based off of it.
This patch creates a gimp_colormap_selection_colormap_changed ()
function that gets the new colormap count and updates the entries
and spinbutton maximum in the Colormap Selection widget.
Previously the palette view was being refreshed, but the rest of the
widgets in the dialogue were not being updated to match when a
new color was added.
