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.
The way we were creating a GimpData identifier was simply wrong, because it was
based on the assumption that the source file uniquely identifies a GimpData (cf.
gimp_tagged_get_identifier() which clearly says that the returned string must
uniquely identify this data). The very simple counter-examples for why this is
a mistake to consider a data file to be a good unique identifier are collection
files. For instance, TTC files (TrueType Collection) contain multiple fonts.
Instead I am adding the concept of "collection" with the assumption that
**within a given collection**, data names are unique (I do hope this to be and
stay true). So I add gimp_data_get_identifiers() and gimp_data_identify() to get
identifiers and check for identity.
The collection will use the old implementation of gimp_data_get_identifier()
because it is quite nice to have paths relative to data and config directories
(it allows some cases of data relocation without losing data identification).
The new implementation to compute a GimpTagged identifier on the other hand will
construct a string from the quality of being internal or not, the data name and
its collection.
It does absolutely nothing except sitting there, providing an is-a
relation (both ways because GimpData is its only subclass). This will
simplify having more libgimp API on GimpResource, without having to
add different PDB code for app and libgimp.
Much like for images and items. Change the PDB to transmit IDs
instead of names for brush, pattern etc. and refactor a whole
lot of libgimp code to deal with it.
modified: libgimp/gimpplugin-private.h
* Don't generate our own marshallers if they are available in GLib
already
* Don't set the c_marshaller parameter in `g_signal_new()` if it's a
default marshaller provided by GLib. See commit message of commit
39e4aa3c57 on why this is the case.
Basically this commit makes sure that all return values that are marked
as "Returns:" also have a `(nullable)` annotation if it is mentioned on
the same line that NULL can also be returned.
This will prevent a few problems in GObject-introspection.
When an error occurs, we want to prevent overwriting any previous
version of the file by incomplete contents. So run
g_output_stream_close() with a cancelled GCancellable to do so.
See also discussion in #2565.
Absolute paths not to be used in $XDG_CONFIG/GIMP/{version}/tags.xml.
These are actually only an identifier, and not used as a path at all
anyway. Moreover MyPaint brushes even generate checksum (which allows
to remap the GimpData appropriately even if the paths are changing).
But anyway it's better not to have absolute paths when we can prevent
so.
... leading to a crash
Add gimp_data_is_copyable() and gimp_data_is_dulicatable().
Use gimp_data_is_duplicatable() when setting the sensitivity of the
various "foo-duplicate" actions, instead of inspecting the object's
GimpDataClass::duplicate pointer directly, since this is no longer
an indication of whether a GimpData object is duplicatable or not
(since commit 33de4d5530).
Make internal data objects non-renamable, even if they're writable,
through gimp_data_is_name_editable(). Currently, the only such
object is the custom gradient.
Prevent changing the name of non-renamable data by making the name
entry of GimpDataEditor non-editable whenever
gimp_viewable_is_name_editable() is FALSE, even if the data is
otherwise editable.
Prevent the vairous PDB -rename() functions from renaming non-
renamable data, by adding a GimpPDBDataAccess flags type,
specifying the desired access mode for the data -- any combination
of READ, WRITE, and RENAME -- and replacing the 'writable'
parameter of the gimp_pdb_get_foo() functions with an 'access'
parameter. Change the various .pdb files to use READ where they'd
used FALSE, and WRITE where they'd used TRUE; use RENAME, isntead
of WRITE, in the -rename() functions.
... which copies the contents of a GimpData into an existing GimpData,
without creating a new instance.
Add a copy() virtual function to GimpData, which subclasses can
override to implement copying; gimp_data_copy() may only be called
for types that implement copy(). Keep the duplicate() virtual
function around, but provide a default implementation that creates
a new object of the source type, and uses copy() to copy the source
object into it.
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
Introduce virtual function GimpViewable::is_name_editable() and class
member "gboolean name_editable" for the default value. Default to
FALSE and only return TRUE if the name can actually be edited by the
user.
When attemting an edit, check the new API and beep instead of starting
the edit.
- 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
Each of the following cleans up tag refcounting, fixes access to
released memory, or other small glitches. Not sure which change
actually fixed the bug:
gimp_data_remove_tag(): remove the found tag, not the passed in tag
(which is to be treated only as a value for comparison).
gimp_tagged_remove_tag(): don't continue the loop after the tag to
remove has been found, there can only be one matching tag, and the
list element has become invalid.
gimptagentry.c: keep references around for the members of
entry->common_tags, and make sure the references are always dropped
properly. In assign_tags(), reference the "add" and "remove" lists for
paranoia and safety reasons.
- 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
if the gradient itself isn't changed.
GimpData: implement GimpObject::name_changed() and set the "dirty"
flag to TRUE. Don't set dirty in GimpData::dirty()'s default impl
because that calls gimp_object_name_changed() anyway.
GimpData: add gimp_data_set_folder_tags() and remove the tag logic
from gimp_data_set_filename(). The function gets the toplevel data
directory passed so it knows where to stop assigning tags.
GimpDataFactory: when loading data, keep track of the currently
processed data hierachy's toplevel directory, and pass it to above new
function. Also make sure obsolete files don't get folder-tagged.
Previously flag writable was used. This caused ritable and editable
brushes to sort first. This was not clearly understood criteria.
Now user brushes in writable folders are sorted first.
This patch does following things for this purpose:
* Adds intrernal flag to GimpTag api
* Modifies GimpData gimp_data_set_filename to use the last element
of the path, unless blacklisted, as internal tag for the resource.
* Modify tag cache to not save internal tags
* Removes a check for existing tags when objects are added to tag cache
Jehan