I've been hesitating because we can consider this an API behavior
change. On the other hand, it just feels like an obvious bug. It makes
sense that all images loaded with gimp_file_load() are loaded clean and
without any undo history. So let's just fix it.
- Merging down a pass-through group onto a layer below does not make any
sense, considering how the below layer is the input to the
pass-through.
- Adding ability to blink problematic items when merge down fails. This
will help people to figure out what is the problem.
Without this, libgimp was creating raster GimpLayer objects when these
had been rasterized, which only made kinda sense when the old "discard"
procedures were not reversible. Yet even this was not entirely true,
since it was still possible to undo, but unfortunately these objects are
long lived. Once you get a GimpLayer, it won't ever change into a
GimpTextLayer (or others)!
So we need to have an object of the correct child type then we'll use
gimp_rasterizable_is_rasterized() to decide how to make use of the
object.
Share the whole rasterize logic of the text, link and vector layer into
an interface. I didn't write it as an abstract parent class, because we
might have more rasterizable items in the future, which may not be
layers (e.g. there were discussions of vector masks).
We need 2 lines in the PDB for it to be an empty line in the C file,
which in turn will be interpreted as markdown-like lists for the
gi-docgen generated HTML docs.
- Consistently add the text about inserting items into the image after
creation, with correct function links/references.
- Consistent grammar for function blurb.
- Make @name argument nullable for gimp_path_new().
This patch moves the enums for GimpTextOutline
and GimpTextOutlineDirection so that they are
accessible to plug-ins/scripts. This will allow
for us to add PDB functions to get/set text outline
properties.
… gimp_file_load().
We make sure that the load procedure associated to the file is the one
used for the inner-file (in case of imbricated files into container
formats).
Also let's set the imported file unless it's a XCF inner format.
As discussed with NikcDC, this will be useful, for instance for the SVG
export to know the mime type of the linked file. If not PNG, JPG or SVG,
we may want to output a small warning that some viewers may not be able
to read such files, since the SVG spec makes the support of these 3
formats only as mandatory.
… PDB API which will return a newly allocated GFile.
Though gimp_temp_file() was so far the only such case where a returned
GFile was being leaked, it may happen again. So the PDB must instead
assume that all returned GFile-s have their own reference and take over
said reference.
And therefore update all other functions to increase the internal
GFile-s reference counts.
While there are cases when you want to edit the mask straight away (this is
often the case when starting with a white or black mask), in many other cases,
the mask may be already as you want it per its initialization (e.g. when
initializing with a channel, selection, the alpha channel, etc.).
Until now, the Add Mask dialog was always switching to the "Edit Layer Mask"
mode by default, which forced an additional unneeded click each time you created
a mask (and were in a case where you initialize the mask as you want it
directly).
Now adding "Edit mask immediately" feature in the "Add Layer Mask dialog":
* It's checked by default to keep historical behavior.
* As most other dialogs, the last value is remembered, allowing people with
repetitive workflow not to have to repeatedly set the settings each and every
time.
* This default is also visible and settable in Preferences > Interface > Dialog
Defaults.
This patch adds additional API for setting the stroke/fill
properties of vector layers. You can now set/get color, stroke
width and stroke style via the PDB. Pattern get/set API is not
yet implemented.
This patch also updates a missing parameter check for GimpVectorLayer
in gimp_config_param_spec_duplicate (), and adds additional API
in /app to make it easier to safely retrieve GimpVectorLayerOptions.
Revert the logic of opening all files as link layers back into loading
their current content as normal layers.
Instead just add a new action dedicated to open images as link layers
and add it to the File menu.
Per UX discussions with Aryeom.
This commit changes the following:
- It's now possible to set whether to store an absolute or relative path
when editing link layer properties.
- New layer dialog doesn't propose an "Image link" fill type anymore.
Link layers won't be created this way (see in a future commit).
These are layers who content depends on another source (right now only
an external image). This can be useful when for instance working at
several people on a single artwork, hence being able to load new
versions of an image without even touching anything in the XCF (for
instance, say you draw an animated character while someone else is
taking care of the background).
Similarly to what we do for text layers, once you start modifying the
contents, it turns into a "normal" layer. The link information is still
available though, so it is possible to revert to the monitoring state
with the menu item "Monitor Linked Image" which appear when a link layer
became a normal layer.
This is not finale as I'm still experimenting. In particular, I have not
implemented XCF saving/loading yet for this new layer type.
This patch adds PDB functions to get and set the PaintOptions
fade-length and fade-repeat properties. This settings can be
used together with gimp_context_set_emulate_brush_dynamics ()
to further control how the paint strokes are drawn in a script
or plug-in.
While there is a style "background color", the idea of a "widget
background color" is completely bogus, the widget background can be a
gradient or whatever.
- Get rid of "background" in GimpViewable's preview API, only leave the
"foreground color" there for things like brushes or fonts.
- In GimpViewRenderer, add the background types to be used to class and
instance, so each renderer type can choose what it needs.
- Render all previews to alpha surfaces, and do the background
for all renderers generically in gimp_view_renderer_real_draw(),
then render the preview surface on top of it.
These functions should not be for the PDB only. The core will soon need
these too (e.g. to load resources linked from a XCF file).
So gimp_pdb_get_data_factory() is moved to gimp_get_data_factory() in
Gimp class. And gimp_pdb_get_data_factory_item() is moved to
gimp_data_factory_get_data() in GimpDataFactory class.
This patch improves vector layer UX based on feedback.
In summary:
* Makes vector layer editable from the Path tool
* Adds initial PDB for creating vector layers in scripts
* Size vector layers to the path size, rather than image
* Transform tools utilize the path for resizing
* Path tool automatically selects vector layer path
This reverts commit 246f9d284f.
This only reverts the part modifying libgimp* headers. All the part
switching to #pragma once in app/ was kept. See #14668.
To prevent losing all information about a type (and also reporting a
different API by dropping a parameter when retrieving an operation's
pspecs, create a placeholder type with a known name and type and put the
rest of the information into its blurb. A little hack-y but filter
browser can now show information of parameters with unsupported types.
Whatever a plug-in does, it should not be able to trigger WARNINGs or
CRITICALs on the core process. Here this was possible when requesting an
array of param specs with gimp_drawable_filter_operation_get_pspecs() on
a GEGL operation, while GIMP doesn't support all types for this filter's
arguments. Trying to send unsupported type specs through the wire would
fail.
Unfortunately just saying that we must add support for these types is
not enough because we simply cannot support every possible types. First
because even in current GEGL core filters, there are types we might
never support (e.g. audio fragments?). But even more because third-party
filters could have custom types too (just like our own filters have
custom GIMP types).
So instead, acknowledge that some types cannot be sent through the wire,
verify when it's one such argument and simply output an informational
message on stderr (because the info of a non-supported type is still
interesting in case this is something we should in fact add support for;
it's much better than silently ignoring the argument).
This will be used in particular for adding GimpTRCType to libgimp.
Otherwise it generates some broken gimp_TRCtype_get_type() function
name.
For this use case, we need to look-ahead a bit in the regular
expression.
gimp_file_save () lets you save an image to
any supported file format, but it did not
update the GimpImage's file or exported
file accordingly. This patch adds code to
do just that, patterned after /app/file/file-save.c's
file_save ().
This also depends on the same settings to render brushes with theme
colors, because this is data, not user interface. Therefore following
theme colors is not necessarily what creators would expect.
