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.
Get rid of most seeking by writing the tile offsets to a table in
memory, instead of directly to the file after each tile. Only seek
back after writing all tiles, in order to save the entire table at
once.
- add gimp_image_get,get_xcf_compat_mode()
- add a compat toggle to GimpFileDialog which is shown and sensitive
only for a save (not export), and if the image structure allows
to save an old version at all. The button also has a tooltip
which explains why it is sensitive and what it does
- add "gboolean xcf_compat" to file_save_dialog_save_image()
- in file_save_dialog_save_image(), call image_set_xcf_compat_mode(TRUE)
only around the call to file_save() and set it to FALSE after saving
- in xcf_save_invoker(), honor the image's XCF compat flag and save an
RLE-compressed XCF if possible
The above is very convoluted and doesn't pass the "xcf_compat" boolean
directly because we can't change the parameters of gimp-xcf-save, and
because the gimp-xcf-save might be called indirectly.
Change XCF saving to never seek past the end of the partially written
file. The only places where we still did this was when skipping the
offset tables for layers, channels, levels and tiles.
Now we write an all-zero offset table first, and then only seek around
in areas of the file that already exist. This also simplifies the code
a bit. Changed comments to make it clear what happens.
Don't use xcf_seek_end() because that seems to be broken on certain
file systems / operating systems / FUSE mounts / whatever. Instead,
seek to explicitly calculated file offsets.
Ported Massimo's patch to master and added comments --Mitch
The same commit in gimp-2-8 is a57e49b1bb
- use G_FILE_CREATE_NONE instead of 0
- don't put "Could not open <file> for writing: <error>" around the
returned error, the returned message is already verbose
Add gimp_image_get_xcf_version() and use it when saving XCFs. The
function also returns GIMP versions in integer (comparable) and string
form to be used by GUI logic that allows to save compatible files.
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!
- change start() and set_text() to use "format" and "..." instead of
"message", allowing to format progress messages in place
- s/cancelable/cancellable/
- move "cancellable" to be the second argument of start()
and keep GIMP_ICON_TYPE_STOCK_ID as a deprecated alias. Change all
plug-ins accordingly and increase the pluginrc file version number so
it gets regenerated with "icon-name" instead of "stock-id".
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.
The code was technically correct previously: It wrote the uninitialized
length only as a placeholder to overwrite it later on. Yet it's better
to not confuse tools (or people) analysing the code. Besides that having
0 for the length in the file while the payload is being written may aid
debugging e.g. crashes in that code later on.
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
- 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.
