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.
libgimpbase:
- Mew GimpFileChooserAction enum type: basically a near-mapping of
GtkFileChooserAction (GTK is not accessible from libgimpbase) with
an added GIMP_FILE_CHOOSER_ACTION_ANY.
- New GimpParamSpecFile param spec type: based off
GimpParamSpecObject, it has a default value, but also a none_ok and
action argument. This way, we can also know from the argument type
if this is a file argument meant for selecting a normal file or a
folder, or for saving into a file, or for creating a directory.
libgimp, plug-ins:
- All existing file arguments (until now using a standard
GParamSpecObject param with GFile value type) were moved to the new
GimpParamSpecFile.
- Script-Fu in particular will now generate the appropriate param type
depending on whether it is an SF-FILENAME or SF-DIRNAME.
- File arguments are now stored between runs as a URI rather than as a
path. As far as I can tell, a GFile always has a URI, but not always
a path (in particular remote file won't have a path).
For diagnosis purposes, it is useful for people to be able to copy and paste
the compatibility warning text that GIMP shows when loading a PSD with
unsupported features. This patch makes that label selectable, which allows
for copying.
This is again a change in gettext 0.23 whose release notes say:
> The value of the xml:lang attribute, inserted by msgfmt, now conforms to W3C standards.
Our xpath selection now recognizes both the old and new (proper) format
so that it works both with older and new versions of msgfmt.
f4582d97 uses gimp-font-get-lookup-name, which is now
marked as private PDB. This patch replaces that usage with
gimp-resource-get-name, which is public and standardized.
… gimp_file_create_thumbnail().
One more case where "save" is misleading, and even more as it's not a
procedure where we control where an image is stored. We only say
basically "make a thumbnail which maps to this file according to my
platform's rules".
As a side fix, I also improved a bit the logic so that it allows @file
to be the exported or — as last fallback — the imported file.
And finally improve the function's docs.
Resolves#12753
gimp-fonts-get-list now returns a vector rather than a list,
so we needed to change calls for length to vector-length
and replace car with vector-ref.
Followup of the save/export difference, plug-ins can only register
"export" handler procedure (save handlers are registered by core). Also
rename _gimp_pdb_set_file_proc_save_handler() though it's private so it
doesn't matter much.
Now gimp_file_save() is a special case, because it can indeed "save" to
XCF or "export" to any other format. So I just leave it named this way,
but I make the function's documentation more exhaustive.
Not sure what I had in mind with the class method copy() in libgimp
GimpLayer. The core duplicate code already takes care of returning an
object of the right type. Also the GimpTextLayer implementation was not
a perfect copy (only text, font and font size were copied). Now it is
because, again, core has all the duplication code necessary.
Finally this makes this function visible to PDB, hence Script-Fu, again.
The PSD export dialog did not allow you to choose what metadata to
export, nor whether the color profile and thumbnail should be exported.
The metadata and thubmnail were not exported at all.
A recent commit changed this export dialog to GimpExportProcedureDialog,
which now allows us to easily add support for these types by
indicating we support these for psd, which is what this commit does.
When using GIMP_DEBUG=file-psd to have debug output in the terminal,
there are two issues:
1. When exporting there is a critical because nowadays we work on a
copy of the image, which doesn't have a filename attached to it, so
let's just remove this debug statement.
2. When loading the merged image, we do not load all layer resources,
since we don't need them. In this case it is expected that the layer
offset isn't at the end of the resources. We now skip writing this
debug statement in this specific case. The offset will be adjusted
in the lines below this.
The libgimp wrapper was just calling the PDB procedure. Get rid of the
wrapper and make the PDB proc public. Also reorder the name argument to
be in the second place, just like it was for the wrapper.
We had 2 flags to indicate that a PDB argument could be nullable:
null_ok and none_ok. That was a huge mixup and the PDB generation code
was using sometimes one, sometimes the other. Let's settle for only
none_ok.
This fixes a bunch of annotations.
Among other issues, this bug impacted exporting images with CMYK
simulation profiles. Because the image was duplicated for export, we
lose the simulation profile information after
gimp_export_options_get_image () is called.
This patch ensures the profile, simulation intent, and simulation
black point compensation toggles are carried over to the new image.
After the few specific args (drawable/filter ID, opacity, blend mode, op
name…), the op argument names can be passed either as string or with the
new argument name syntax. The error message though focus on argument
name type.
Also fix the argument count for the various possible cases (when
configuring with (gimp-drawable-filter-configure) or
(gimp-drawable-merge|append-new-filter), the start arg count is
different).
This syntax is now the official syntax for non-core PDB procedures.
I.e. that while core procedures will still use ordered arguments (e.g.:
`(gimp-image-get-layers 1)`), plug-in PDB procedures called from
Script-Fu will have named arguments in any order.
Say for instance that you want to call python-fu-foggify from Script-Fu.
Whereas we used to run:
> (python-fu-foggify RUN-NONINTERACTIVE 1 (car (gimp-image-get-layers 1)) "Clouds" '(50 4 4) 1.0 50.0)
Now we should call:
> (python-fu-foggify #:image 1 #:drawables (car (gimp-image-get-layers 1)) #:opacity 50.0 #:color '(50 4 4))
Now we can note:
* Every argument is preceded by a #:label which is the argument name.
This makes these calls much more readable (some plug-in procedures can
have dozen of arguments and these end up as list of integers, floats
and strings, which are hard to read and hard to debug) and semantic.
* Order doesn't matter anymore. For instance here, I put #:opacity
before #:color.
* As a direct consequence, we can drop any argument which we wish to
keep with default value. E.g. in the old style, we had to put the
#:run-mode, #:name ("Clouds") and #:turbulence (1.0) because we were
changing the last argument #:opacity (50.0). Now we can drop all 3
default arguments.
Having non-ordered argument is in fact the starter of this feature,
because it is already the case for calling PDB procedures in the libgimp
API (and therefore in all GIR bindings). By saying that the order of PDB
procedures is not part of the API, we actually allow to add arguments
and even to reorder them in the future without breaking existing scripts
in the 3.0 series.
This became even more serious when I was considering to make the generic
metadata arguments public. Since they are appended to the end, after all
plug-in-specific arguments, if I do this, adding any argument in an
export plug-in would break order. It won't matter anymore!
Note that it doesn't matter for core PDB procedures (where this syntax
is not used) because these are also C functions and therefore order and
number of arguments matter anyway. Also these don't have dozens of
arguments.
As a helper for Script-Fu developer, in particular as we already
released 2 RCs and therefore some people already started to port their
scripts, the old syntax will still work yet will produce a warning
showing how to call the same thing with the new syntax. For instance,
with the above first call, the warning will be:
> (script-fu:2059912): scriptfu-WARNING **: 22:54:47.507: Calling Plug-In PDB procedures with arguments as an ordered list is deprecated.
> Please use named arguments: (python-fu-foggify #:run-mode 1 #:image 1 #:drawables (2) #:name "Clouds" #:color '(50 4 4) #:turbulence 1.000000 #:opacity 50.000000)
Note that the argument name syntax is coming from the Racket scheme
variant: https://docs.racket-lang.org/arguments/index.html
Common Lisp has a similar syntax, either with just a colon, or also a
sharp + colon (it's unclear to me the difference, something about
interned vs. uninterned symbols).
After discussion with Liam on IRC, we decided to go with the #: syntax
of Racket.
A main consequence of this is that the Procedure Browser plug-in in GIMP
doesn't show now private PDB procedures. I was always finding this
annoying as their presence in the procedure browser would encourage
people to use these in plug-ins and scripts (even when sometimes we
added explicit description that these should not be used).
Now it's clearer. The procedure are much more hidden to plug-in
developers (and if they still use them, it's at their own risk,
especially of having broken plug-ins when we change signature of these
as they are not meant to be used, and therefore we don't promise
stability for these).
Core procedures are all the procedures created for libgimp basically. In
opposition, procedures created by plug-ins are not core procedures.
GimpProcedure class in libgimp now has a gimp_procedure_is_core() which
will tell you if a procedure is core or not.
Private procedures already existed, except that they were only marked as
"private" in libgimp (e.g. _gimp_font_get_lookup_name()) starting with
an underscore and marked as G_GNUC_INTERNAL. Now we also store this
information in the procedure object itself for reuse.
Certain cloud providers return a blobname
rather than the actual filename with
g_file_get_uri (). Since our code only checks
the suffix and extension of non-native files,
we received "Unknown File Type" when
trying to load images from those providers.
This patch replaces g_file_get_uri () so that
we get the display-name instead, which
should always have the extension. This
may be changed in the future when we
switch to a FileChooser portal.
This same pattern is also used on the
GimpThumbBox so we see the display-name
rather than the blob name.
Thanks to Khalid Abu Shawarib for the
additional information!
While testing an AppImage, I noticed a thick border around the
"Show All Files" in the File Open dialogue. This is because the
background color for the actionbar is not defined, and if the internal
padding is increased by the system theme, it's visible. Therefore
we define the color.
I also noticed that the GtkSwitch had a rectangle border rather than
a rounded one. This patch defines the border radius as well.
Using the app. prefix/group for the top menu works better for the
GIMP_GTK_MENUBAR variant of the menubar (which is what is used on macOS
to get the macOS-style menu).
The whole action group code should be reviewed and straightened up
eventually!
when creating a new image.
We add a new function `gimp_metadata_set_creation_date` to
`libgimpbase/gimpmetadata` to handle setting all relevant
metadata tags.
We add a local function `gimp_image_new_add_creation_metadata` to
add the creation date metadata to relevant functions that create
new images.
We write tags for both the creation date and several modified dates
for IPTC, XMP and Exif metadata. All these use different ways to
express date/time and timezones and I can already see we need to have
another look at other places where we handle modified dates.
This solves the second part of #7287, adding metadata about the
date/time a new image was created.
When starting from an image we created in GIMP, saving/exporting with
metadata and/or thumbnail (thumbnails are part of the exif metadata)
failed, because our metadata was not initialized for newly created
images.
To fix this, create a metadata object in `gimp_create_image`, that way
when creating a new image in the gui, but also when creating an
image programmatically, gets metadata attached at the start.
We need to do that here, because we need to have metadata available
even for images that we import that do not have metadata attached.
