This is meant to replace gimp_image_get_colormap() (see also #9477).
We likely won't need a gimp_image_set_palette() because we can simply edit the
image's colormap/palette with GimpPalette API now and it is directly updated.
For instance, the following code changes the first entry in the image palette to
red, immediately:
```python
i = Gimp.list_images()[0]
p = i.get_palette()
c = Gimp.RGB()
c.r = 1.0
p.entry_set_color(0, c)
```
For this to work fine, I added a new concept to GimpData, which is that they can
be tied to a GimpImage (instead of a GFile). Image palettes are not considered
internals, they are just tied to their image, therefore they can be edited by
scripts/plug-ins.
Additionally with this commit, editing an image's colormap from libgimp API also
generates undo steps now.
GLib has a specific type for byte arrays: `GBytes` (and it's underlying
GType `G_TYPE_BYTES`).
By using this type, we can avoid having a `GimpUint8Array` which is a
bit cumbersome to use for both the C API, as well as bindings. By using
`GBytes`, we allow other languages to pass on byte arrays as they are
used to, while the bindings will make sure to do the right thing.
In the end, it makes the API a little bit simpler for everyone, and
reduces confusion for people who are used to working with byte arrays
in other C/GLib based code (and not having 2 different types to denote
the same thing).
Related: https://gitlab.gnome.org/GNOME/gimp/-/issues/5919
Missing functions were:
* gimp_image_get_selected_channels()
* gimp_image_get_selected_vectors()
* gimp_image_list_selected_channels()
* gimp_image_list_selected_vectors()
* gimp_image_set_selected_channels()
* gimp_image_set_selected_vectors()
* gimp_image_take_selected_channels()
* gimp_image_take_selected_vectors()
There are discussions of renaming GimpVectors to GimpPath, which would
also be consistent with the GUI and make the always-plural less akward
in API. We'll see. For now keeping named like this.
s/gimp_image_base_type/gimp_image_get_base_type/
s/gimp_image_width/gimp_image_get_width/
s/gimp_image_height/gimp_image_get_height/
Sorry plug-in developers, more porting work! But really this seems like
the right thing to do in order not to get stuck with inconsistent naming
for many more years to come.
… gimp_image_policy_color_profile().
These functions allow a plug-in to explicitly execute the Rotation and
Profile conversion policies on an image (which may be any of
Rotating/Discarding/Ask or Converting/Keeping/Ask respectively). These
policies are automatically executed when loading an image from GIMP
interfaces, but they won't be when loading an image from the PDB. Then
it is up to the calling code to decide what to do (which can be either
some arbitrary code or following the user policy).
Color picking on a single layer still works as it used to. On multiple
layer, it will now pick on the composited color, similarly to sample
merged if only selected layers were made visible.
The PDB/libgimp function gimp_image_pick_color() is also updated to work
on multiple drawables too, giving the same ability to plug-ins (the only
call to this function in core plug-ins have been updated).
and in an attack of madness, changes almost all file plug-in
code to use GFile instead of filenames, which means passing
the GFile down to the bottom and get its filename at the very
end where it's actually needed.
Turn all ID param specs into object param specs (e.g. GimpParamImageID
becomes GimpParamImage) and convert between IDs and objects in
gimpgpparams.c directly above the the wire protocol, so all of app/,
libgimp/ and plug-ins/ can deal directly with objects down to the
lowest level and not care about IDs.
Use the actual object param specs for procedure arguments and return
values again instead of a plain g_param_spec_object() and bring back
the none_ok parameter.
This implies changing the PDB type checking functions to work on pure
integers instead of IDs (one can't check whether object creation is
possible if performing that check requires the object to already
exist).
For example gimp_foo_is_valid() becomes gimp_foo_id_is_valid() and is
not involved in automatic object creation magic at the protocol
level. Added wrappers which still say gimp_foo_is_valid() and take the
respective objects.
Adapted all code, and it all becomes nicer and less convoluted, even
the generated PDB wrappers in app/ and libgimp/.
I.e.: gimp_image_get_(layers|channels|vectors)(), gimp_image_list() and
gimp_item_get_children().
Instead of returning an array of IDs, these will now return a GList with
the right objects ready to use.
No need of is_id_arg() anymore in pdb/lib.pl. Let's reuse the {id}
value. Also I had to add an additional trick for GimpDisplay which we
will now generate as such in libgimp PDB files, but still need to show
as GimpObject on app/pdb/.
As previously, only the new classes and the PDB generation for a first
step.
By default the new API will be used. But if we build with
GIMP_DEPRECATED_REPLACE_NEW_API macro, then the same function names will
call the old API with ids.
This way, we don't have to update all our plug-ins at once (which I
tried and is very tedious work).
Note that bindings won't have access to the deprecated API at all.
This means that all functions which were returning or taking as
parameter an image id (as gint32) are now taking a GimpImage object
instead.
The PDB is still passing around an id only over the wire. But we create
an object for plug-ins to work on.
This is quite a huge API break, but is probably the best bet for the
future quality. It will make nicer API instrospection (and nicer API in
binding), will fix the issues with pspec on GimpImageID in Python
bindings (which makes the current Python API unusable as soon as we need
to work on images, which is most of our plug-ins!), etc.
Also it will allow to use signals on images, which will be a great asset
when we will finally have bi-directionnal communications (i.e. plug-ins
would be able to connect to image changes, destructions, and whatnot).
These procedures freeze/thaw the corresponding containers of the
image, allowing plug-ins that perform many changes affecting any of
these containers to suppress updates to the corresponding dialogs,
significantly improving performance.
...in both the core and libgimp.
Images now know what the default mode for new layers is:
- NORMAL for empty images
- NORMAL for images with any non-legacy layer
- NORMAL_LEGAVY for images with only legacy layers
This changes behavior when layers are created from the UI, but *also*
when created by plug-ins (yes there is a compat issue here):
- Most (all?) single-layer file importers now create NORMAL layers
- Screenshot, Webpage etc also create NORMAL layers
Scripts that create images from scratch (logos etc) should not be
affected because they usually have NORMAL_LEGACY hardcoded.
3rd party plug-ins and scripts will also behave old-style unless they
get ported to gimp_image_get_default_new_layer_mode().
Based on original patches from Hartmut Kuhse and modified
by Michael Natterer. Changes include:
- remove libexif dependency and add a hard dependency on gexiv2
- typedef GExiv2Metadata to GimpMetadata to avoid having to
include gexiv2 globally
- add basic GimpMetadata handling functions to libgimpbase
- add image and image file specific metadata functions to libgimp,
including the exif orientation image rotate dialog
- port plug-ins to use the new APIs
- port file-tiff-save's UI to GtkBuilder
- add new plug-in "metadata" to view the image's metadata
- keep metadata around as GimpImage member in the core
- update the image's metadata on image size, resolution and precision
changes
- obsolete the old metadata parasites
- migrate the old parasites to new GimpMetadata object on XCF load
Make gimp_image_get_uri() and gimp_image_get_filename() behave as in
the GIMP 2.6 days. Add new functions gimp_image_get_xcf_uri(),
gimp_image_get_exported_uri() and gimp_image_get_imported_uri().
which all take "parent" parameters and allow to insert items in a
tree. We don't have channel or vectors trees (yet) but API symmetry is
more important here than a currently useless parameter.
2009-03-04 Sven Neumann <sven@gimp.org>
Bug 574149 – Can't get name/filename of files loaded from URI
* tools/pdbgen/pdb/image.pdb: added new procedure
gimp-image-get-uri.
* app/pdb/image-cmds.c
* libgimp/gimpimage_pdb.c: regenerated.
* plug-ins/pygimp/pygimp-image.c: wrap the new procedure into an
Image attribute.
svn path=/trunk/; revision=28103
2009-01-17 Michael Natterer <mitch@gimp.org>
* all files with a GPL header and all COPYING files:
Change licence to GPLv3 (and to LGPLv3 for libgimp).
Cleaned up some copyright headers and regenerated the parsers in
the ImageMap plugin.
svn path=/trunk/; revision=27913
2008-09-24 Sven Neumann <sven@gimp.org>
* tools/pdbgen/pdb/layer.pdb
* tools/pdbgen/pdb/image.pdb: added new scale procedures that
allow to specify the interpolation explicitly. Fixes bug
#486977.
Also pass the progress parameter to the scale and rotate
functions.
* app/pdb/image-cmds.c
* app/pdb/internal-procs.c
* app/pdb/layer-cmds.c
* libgimp/gimpimage_pdb.[ch]
* libgimp/gimplayer_pdb.[ch]: regenerated.
* libgimp/gimp.def: updated.
svn path=/trunk/; revision=27039
2008-04-21 Michael Natterer <mitch@gimp.org>
Move the shadow tiles from the image to the drawable.
Fixes bug #100469.
* app/core/Makefile.am
* app/core/gimpdrawable-shadow.[ch]: new files implementing
the shadow tiles.
* app/core/gimpimage.[ch]: remove the shadow tile manager from the
GimpImage struct. Remove gimp_image_get_shadow_tiles() and
_free_shadow_tiles().
* app/core/gimpdrawable.[ch]: add the shadow tile manager
here. Remove get_shadow_tiles() and merge_shadow(). Free the
shadow tiles in finalize and when the drawable gets removed from
the image.
* app/core/gimpdrawable-brightness-contrast.c
* app/core/gimpdrawable-color-balance.c
* app/core/gimpdrawable-colorize.c
* app/core/gimpdrawable-curves.c
* app/core/gimpdrawable-desaturate.c
* app/core/gimpdrawable-equalize.c
* app/core/gimpdrawable-hue-saturation.c
* app/core/gimpdrawable-invert.c
* app/core/gimpdrawable-levels.c
* app/core/gimpdrawable-operation.c
* app/core/gimpdrawable-posterize.c
* app/core/gimpdrawable-threshold.c
* app/core/gimpimagemap.c: changed accordingly. Free the shadow tiles
after using them.
* app/plug-in/gimpplugin-cleanup.[ch]: add
gimp_plug_in_cleanup_add_shadow() and _remove_shadow() which keep
track of whether shadow tiles were created on behalf of a plug-in
procedure.
(gimp_plug_in_cleanup): free shadow tiles which were created but
not destroyed by a plug-in procedure.
* app/plug-in/gimpplugin-message.c (plug_in_handle_tile_request):
call gimp_plug_in_cleanup_add_shadow() whenever a plug-in requests
shadow tiles.
* tools/pdbgen/pdb/drawable.pdb: use the new drawable shadow
API. Add new procedure gimp-drawable-free-shadow. Call
gimp_plug_in_cleaup_remove_shadow() when it gets called.
* tools/pdbgen/pdb/image.pdb: deprecate gimp-image-free-shadow.
Calling it has no effect any longer.
* app/pdb/drawable-cmds.c
* app/pdb/image-cmds.c
* app/pdb/internal-procs.c
* libgimp/gimpimage_pdb.[ch]
* libgimp/gimpdrawable_pdb.[ch]: regenerated.
svn path=/trunk/; revision=25510
2007-11-05 Sven Neumann <sven@gimp.org>
* tools/pdbgen/pdb/image.pdb: create a libgimp C wrapper for
gimp-image-get-vectors-by-tattoo; this function was accidentally
forgotten in the 2.4 libgimp API.
* app/pdb/image_cmds.c
* libgimp/gimpimage_pdb.[ch]: regenerated.
svn path=/trunk/; revision=24066
Jehan