Add new XCF property FLOAT_OPACITY and always save both the old 8-bit
and the new float opacity of layers and channels. Float opacity is
saved after the 8-bit one so when loading, it overwrites the limited
8-bit value with the proper precision. Do not increase the XCF version
number because old GIMP versions will simply skip the unknown
FLOAT_OPACITY and keep using the 8-bit value.
- 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
GIMP's OVERLAY mode was identical to SOFTLIGHT. This commit fixes the
issue and introduces a NEW_OVERLAY mode and enum value.
- change gimp:overlay-mode to be a real (svg-ish) overlay mode
- when compositing, map OVERLAY to gimp:softlight-mode
- when compisiting, map NEW_OVERLAY to gimp:overlay-mode
- bump the XCF version when NEW_OVERLAY is used
- map OVERLAY to SOFTLIGHT when loading and saving XCF
- map OVERLAY to softlight in all PDB setters
- map OVERLAY to softlight when deserializing a GimpContext
- change all paint mode menus to show an entry for NEW_OVERLAY
instead of OVERLAY
- change PSP, PSD and OpenRaster to use NEW_OVERLAY
These changes should (redundantly) make sure that no OVERLAY enum
value is used in the core any longer because it gets mapped to
SOFTLIGHT at all entry points, with the downside of introducing a
setter/getter asymmetry when OVERLAY was set in a PDB api.
and g_warning() for programming errors only.
Use g_printerr() for "normal" errors which may happen in a program
lifetime (in particular corrupted XCF file errors are not necessarily
programming errors).
Our code was planning zlib and fractal compressions for eons, but would
crash against a file which would be actually using these. It means that
if we implement one of these compressions for 2.10, anyone with GIMP 2.8
(and likely earlier too) would crash when opening a legit file using the
new compressions. That's very bad.
Never use g_error() in non-fatale, expected, situations!
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.
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
- 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.
Apply and heavily modify patch from remyDev which adds "lock position"
to GimpItem, similar to "lock content". Lock position disables all
sorts of translation and transform, from the GUI and the PDB.
Cleaned up some aspects of the lock content code as well because a
second instance of similar code always shows what went wrong the first
time.
The last tile is not followed by a next tile, so we don't have an
offset to the next tile and have to guess the number of bytes to load,
using the largest possible tile. That guessing was based on a maximum
of four bytes per pixel.
In fact, it broke much more than that because the way XCF loading
replaced the image's mask prevented the image's "mask-changed" signal
from ever being emitted. Add private API gimp_image_take_mask() which
properly sets the mask and use it for image construction and the XCF
selection loading hack.
Also, make group layer type conversion much less hackish by using the
same kind of temporary states that are used for reallocating its
projection on size change.
because it would require really evil hacks to honor these properties
in the gegl projection if they were on the mask, and because they
actually belong to the layer.
Conditional jump or move depends on uninitialised value(s)
==28817== at 0x6AA386: gimp_coords_manhattan_dist (gimp/app/core/gimpcoords.c:175)
==28817== by 0x6AB428: gimp_coords_bezier_is_straight (gimp/app/core/gimpcoords-interpolate.c:213)
==28817== by 0x67663B: gimp_bezier_stroke_segment_nearest_point_get (gimp/app/vectors/gimpbezierstroke.c:676)
==28817== by 0x676C86: gimp_bezier_stroke_nearest_point_get (gimp/app/vectors/gimpbezierstroke.c:631)
==28817== by 0x4D79E3: gimp_draw_tool_on_vectors_curve (gimp/app/tools/gimpdrawtool.c:1175)
==28817== by 0x4D7CD5: gimp_draw_tool_on_vectors (gimp/app/tools/gimpdrawtool.c:1242)
==28817== by 0x511CE7: gimp_vector_tool_oper_update (gimp/app/tools/gimpvectortool.c:989)
==28817== by 0x50B059: gimp_tool_oper_update (gimp/app/tools/gimptool.c:970)
==28817== by 0x546F3C: gimp_display_shell_canvas_tool_events (gimp/app/display/gimpdisplayshell-tool-events.c:401)
==28817== by 0x52A42E2: _gtk_marshal_BOOLEAN__BOXED (gtk-2-24/gtk/gtkmarshalers.c:86)
Steps to reproduce:
G_SLICE=always-malloc valgrind gimp-2.7 app/tests/*/*.xcf
B (Activate Path tool)
Introduced two virtual functions to a GimpViewable
'set_expanded' and 'get_expanded'
and a PROP_GROUP_ITEM_FLAGS to load/save the expanded state
of layer_groups and use them.
