You can now set any paint tool to mirror painting relatively
horizontal/vertical axis or a central point (any combination of these 3
symmetries).
This has been implemented as a new multi-stroke core, where every stroke
is actually handled as a multi-stroke (default of size 1).
This is also the first usage of custom guides for symmetry guiding.
Current version has to be activated in the playground.
When checked, diagonally neighboring pixels are considered connected
when calculating the affected area.
This commit also adds a corresponding diagonal_neighbors parameter to
gimp_drawable_bucket_fill(), and modifies the callers, other than the
bucket fill tool, to pass FALSE for this parameter, to retain the
current behavior.
Need to keep GimpPDBContext's stroke options (which is a context too)
in sync with the PDB context itself, so setting any of the context's
properties properly affects subsquent strokes, and also avoids running
into inconsistent states like happened in this bug.
Add PDB sample point API similar to how the guide API works. Add core
API similar to the core guide API to make guide and sample point APIs
as similar as possible.
file-procedure.[ch] is gone and its functions moved to
GimpPlugInManager where they belong (the manager keeps around the
lists of load, save and export procedures).
Utility functions from file-utils.[ch] that have nothing to do with
image files moved to core/gimp-utils.[ch].
Allow to set profiles on grayscale images. Change profile validation
to check for image type and profile type. Actually the patch simply
makes some pieces of code less restrictive. Change user-visible
strings in the profile dialogs accordingly. Change PDB docs
accordingly.
Add new PDB procedures gimp-context-get/set-stroke-method and honor
the new setting in gimp-edit-stroke and gimp-edit-stroke-vectors.
Internally, keep a GimpStrokeOptions around in GimpPDBContext to keep
track of the newly added PDB state, and use it for the stroke
operations instead of creating a scratch GimpStrokeOptions.
Blurbs use third person and need a final point.
Some description were wrong or inaccurate. Add also units where
needed (radius in pixels, angle in degrees).
Some returned values have to be freed.
to not return a reference that has to be dropped. Also allow NULL to
be returned if the managed cannot have a profile. If it can have one,
get_color_profile() still always returns a profile (either the
assigned one, or a generated built-in one).
...when a color profile is active
This commit doesn't fix anything, but it prepares the code to do the
right thing:
It passes the actual raw image pixels through the entire color picking
mechanism to the widgets which display colors, particularly
GimpColorFrame.
This is needed for GimpColorFrame's "Pixel" mode (as opposed to its
RGB, HSV etc. modes) which is supposed to show the raw pixel values
from the image.
Before this commit, it was recreating the raw pixel values from the
GimpRGB value it knows, which will become impossible when we correctly
pick color managed GimpRGB values soon.
not only as parasite. This way we avoid having to create the profile
in each call to gimp_image_get_color_profile(). Also keep the built-in
profiles around in gimp_image_get_builtin_color_profile(). Add/remove
refs and unrefs as needed in all users of these functions.
- gimp-image-set-filename PDB wrapper: implement the same there in
a few lines
- xcf-load.c: use gimp_image_set_file() instead, and get rid of the
last use of filename in xcf/ in favor of GFile
it used to be a typedef to gpointer and actually was a cmsHPROFILE.
Change its API to be more "standard", remove the public close()
function. The object caches both the cmsHPROFILE and the data/length
ICC blob, so conversions between the two become obsolete (simply call
get_lcms_profile() or get_icc_profile()).
Adapt everything to the new API, but port it in a naive way for now,
the code doesn't take advantage of the new possibilities yet (like
refcounting).
