when they are added to items, images or globally, from the PDF or an
XCF file. None of the validation functions does anything currently,
they simply return TRUE.
Change the gimp-image-get-name procedure to return the same string
as shown in the image title, and mention in its API docs that this
string is meant for annotating UI elements only.
return_vals[1] being present and being a string doesn't neccessarily
mean it comes from the plug-in, it might just as well be its first
return value, which gets generated and NULL-initialized by the plug-in
execution code even if the plug-in didn't actually return anything.
Port selection/path stroking to using the PDB-controllable
paint options that live in GimpPDBContext.
Change gimp_item_stroke()'s "use_default_values" boolean which was
introduced at a time where we had no better way by a GimpPaintOptions
parameter. If a non-NULL paint_options is passed (when called from the
PDB), use it for stroking; if NULL is passed, use the actual paint
tool options from the GUI (when called from the menus or the stroke
dialog). In the PDB wrappers, get the right paint options object from
the PDB context associated with the calling plug-in.
Which contains all the API from the "color" group, but with a
gimp_drawable namespace and with support for high bit depths. The
group is actually a copy of "color" with cruft removed and some API
ported to using float instead of integer API.
Deprecated all "color" functions that already have a ported version in
"drawable_color".
This is unfinished WIP, some functions in "drawable_color" still have
the old API.
and use it globally instead of two different methods, one of which was
forgotten to be ported to the new aspect ratio range where 0.0 means
1:1. Add a FIXME comment in paint_tools.pdb where I think setting the
default size is a bug, see #721249.
We must always call gimp_item_convert() even if the source drawable is
in the same image, or we might end up with a layer of wrong pixel
format. This was probably broken for years.
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
- don't include <gdk-pixbuf/gdk-pixbuf.h> in headers in app/
- instead, include it in many .c files instead of <glib-object.h>,
finally acknowledging the fact that app/ depends on gdk-pixbuf almost
globally
- fix up includes as if libgimpbase depended in GIO, which it soon will
The documentation was missing information about GIMP_ADD_CHANNEL_MASK
mask type, also about possible failure cases, and had an unclosed
bracket typo.
Also make nicer output and list formatting with the new pdb paragraph
feature.
Single newlines in procedure descriptions are still considered normal
spaces. But 2 newlines are transformed into 1 newline. 3 newlines into
2 newlines. And so on.
This allows for a start of nicer output in the procedure browser or C
file comments (and consequently in generated html doc).
The current documentation have users think the argument layer is going
to be cropped, whereas it actually only serves as a base for determining
cropping extents. The active layer is the one to be cropped.
Slightly more complete documentation explaining this.
and invert masks using invert-linear and other drawables using
invert-gamma. drawable_invert_cmd_callback() still always uses
invert-gamma even though it can be used on layer masks.
- Add new enum GimpComponentType which contains u8, u16, u32 etc.
- Change GimpPrecision to be u8-linear, u8-gamma, u16-linear etc.
- Add all the needed formats to gimp-babl.c
- Bump the XCF version to 5 and make sure version 4 with the old
GimpPrecision enum values is loaded correctly
This change blows up the precision enums in "New Image" and
Image->Precision so we can test all this stuff. It is undecided what
format will be user-visible options in 2.10.
so we can make histograms of the gamma-corrected image data. Pass
TRUE all over the place so the histogram works perceptually. This
needs more thinking...
This reverts commit d2cac94a49
and commit 7241a35b93.
gimp-drawable-foreground-extract will be revived before 2.10, the
warnings are a nice reminder :)
Michael Natterer