In the various libgimp data-selection functions, replace spaces
with hyphens in the callback-proc parameter names. Spaces in
parameter names are invalid, which is now enforced by GIMP/GLib,
causing procedure registration to fail.
I had this warning when cross-building for Windows 64-bit:
> libgimp/gimpui.c:187:52: warning: passing argument 2 of
> 'gdk_win32_window_foreign_new_for_display' makes pointer from integer
> without a cast [-Wint-conversion]
> note: expected 'HWND' {aka 'struct HWND__ *'} but argument is of type 'guint32' {aka 'unsigned int'}
(cherry picked from commit cf6dae6f83)
Pass the swap-compression option set in the preferences down to
plug-ins, so that they use the same swap-compression algorithm as
the main app.
(cherry picked from commit 5cc289b642)
When exporting to a format that supports layers, but doesn't
support layer masks, merge layer groups with a mask before applying
their mask, since masks can't be applied to layer groups.
(cherry picked from commit 643279bd31)
...for gimp_context_set_antialias(antialias)
Mention gimp_context_set_antialias() in the stroke docs, and mention
the stroke functions in the antialias docs.
(cherry picked from commit 7a589951c9)
This new capacity was created just 3 commits ago (9933f46f85).
The point was that the real fix is to remove the implication
HANDLE_LAYERS => HANDLE_ALPHA, but this breaks public API behavior,
which is why I didn't go with it.
Still it just felt wrong to add a NEEP_OPAQUE capability when it should
be the same thing as not setting HANDLE_ALPHA. After discussion on IRC,
we decided that this implication was basically a bug, and since in all
core plug-ins, when HANDLE_LAYERS was set, we were also setting
HANDLE_ALPHA, no core plug-in code even has to be changed. As for
third-party plug-ins, let's assume that none has been relying on this
wrong assumption.
(cherry picked from commit 667b4d71c9)
Currently capability GIMP_EXPORT_CAN_HANDLE_LAYERS implies
GIMP_EXPORT_CAN_HANDLE_ALPHA. Though in many cases, multi-layer implies
alpha for basic compositing, our export plug-ins sometimes use the
concept of "layer export" for multi-pages or collection files.
Additionally sometimes alpha may not even be supported at all whereas
layers are. This will be the case in the next commit which will make use
of this new capability.
(cherry picked from commit 9933f46f85)
In GimpTileBackendPlugin, avoid storing read/written tiles in the
libgimp tile-cache, since caching is already done by GEGL.
(cherry picked from commit 47dcd4b93a)
gimp_plug_in_handle_proc_install(): print the procedure name when
bailing out of a wrong proc install call. For an obsolete full-path
menu label, also print the label. Original patch by Liam Quin.
(cherry picked from commit 07e3c1c15b)
In libgimp, add a note to gimp_install_procedure() stating that
passing a full menu path as "menu_label" is deprecated.
In GimpTileBackendPlugin, change the default tile multiplier,
specifying the ratio between the backend tile-size, and GIMP's
tile-size, from 2 to 1. Since we're reading/writing each GIMP tile
using a separate command anyway, using a large multiplier doesn't
provide any benefits, while it does have drawbacks. In particular,
it reduces the chance that a write operation will affect an entire
tile, which allows us to avoid reading the tile data from GIMP.
(cherry picked from commit a5e2945b68)
Add an internal _gimp_tile_ref_noinit() function, which increases
the ref-count of a tile *without* initializing its data (in
particular, without reading its data from GIMP, or zeroing it.)
Use this function, instead of gimp_tile_ref(), when storing a tile
in GimpTileBackendPlugin, to avoid unnecessarily reading the tile
data from GIMP.
(cherry picked from commit 5ffdb9aa41)
In GimpTileBackendPlugin, return NULL when fetching z>0 tiles,
instead of simply ignoring the z coordinate, so that the mipmapped
tile is rendered locally. Likewise, avoid storing z>0 tiles.
Note that this is suboptimal, since all the necessary level-0 tiles
need to be sent to the buffer as a result. Ideally, we should
extend the wire protocol to handle mipmapped tiles.
(cherry picked from commit d0ae39f017)
We were not taking into account tags that can appear multiple times,
such as "keyword", they are handled by gexiv2 with the
get_tag_multiple() and set_tag_multiple() functions.
gimp_metadata_deserialize_text(): when deserializing our XML format,
check if a tag is already set on the metadata as "multiple" and if yes
retrieve it, append the new value and set it again.
gimp_image_metadata_save_finish(): take care of "multiple" values when
copying tags to new metadata created for saving.
This should preserve all values across an "import, edit, export".
Thing will still break when using the metadata editor, it doesn't
handle multiple values at all, but that code is very hard to
understand.
(cherry picked from commit d708ac0b21)
The whole bucket fill specific enum stuff is on its way out, so let's
keep this one out of libgimp for now until we decide how to present
line art filling in the PDB.
(cherry picked from commit 368f2e596a)
This was my initial choice, but the more I think about it, the less I am
sure this was the right choice. There was some common code (as I was
making a common composite bucket fill once the line art was generated),
but there is also a lot of different code and the functions were filled
of exception when we were doing a line art fill. Also though there is a
bit of color works (the way we decide whether a pixel is part of a
stroke or not, though currently this is basic grayscale threshold), this
is really not the same as other criterions. In particular this was made
obvious on the Select by Color tool where the line art criterion was
completely meaningless and would have had to be opted-out!
This commit split a bit the code. Instead of finding the line art in the
criterion list, I add a third choice to the "Fill whole selection"/"Fill
similar colors" radio. In turn I create a new GimpBucketFillArea type
with the 3 choices, and remove line art value from GimpSelectCriterion.
I am not fully happy yet of this code, as it creates a bit of duplicate
code, and I would appreciate to move some code away from gimpdrawable-*
and gimppickable-* files. This may happen later. I break the work in
pieces to not get too messy.
Also this removes access to the smart colorization from the API, but
that's probably ok as I prefer to not freeze options too early in the
process since API needs to be stable. Probably we should get a concept
of experimental API.
(cherry picked from commit cd924f453a)
Add flag GIMP_METADATA_SAVE_COLOR_PROFILE to GimpMetadataSaveFlags and
initialize it from gimp_export_color_profile() in
gimp_image_metadata_save_prepare().
Adapt all plug-ins to use the bit from the suggested export flags and
pass the actually used value back to
gimp_image_metadata_save_finish().
This changes no behavior at all but creates hooks on the libgimp side
that are called with the context of an image before and after the
actual export, which might become useful later. Also, consistency
is good even though the color profile is not strictly "metadata".
(cherry picked from commit c667fdc5c0)
Pass the GEGL tile-cache size, swap path, and thread-count to plug-
ins as part of their config, and have libgimp set the plug-in's
GeglConfig accordingly upon initialization.
GTK/OSX does not automatically assign focus to the new windows (upstream
issue), so activateIgnoringOtherApps is called. However, if it is called
before gtk initialized it may cause number of focus issues.
... and G_TYPE_INSTANCE_GET_PRIVATE()
g_type_class_add_private() and G_TYPE_INSTANCE_GET_PRIVATE() were
deprecated in GLib 2.58. Instead, use
G_DEFINE_[ABSTRACT_]TYPE_WITH_PRIVATE(), and
G_ADD_PRIVATE[_DYNAMIC](), and the implictly-defined
foo_get_instance_private() functions, all of which are available in
the GLib versions we depend on.
This commit only covers types registered using one of the
G_DEFINE_FOO() macros (i.e., most types), but not types with a
custom registration function, of which we still have a few -- GLib
currently only provides a (non-deprecated) public API for adding a
private struct using the G_DEFINE_FOO() macros.
Note that this commit was 99% auto-generated (because I'm not
*that* crazy :), so if there are any style mismatches... we'll have
to live with them for now.
In the command handler of GimpTileBackendPlugin, forward unhandled
commands to gegl_tile_backend_command(), instead of asserting that
they're within range (which has already been disabled by commit
bc3b076caf). See GEGL commit
30047e65723ebb44fcde9c6b5f60ceecb43b0895.
(cherry picked from commit 668fee966a)
In gimp_tile_backend_plugin_command(), disable the range check for
the input tile command. This check prevents us from adding new
tile commands to GEGL without breaking the ABI; yet, the next GEGL
release will add a new command. We're going to have to decide what
to do about this, but for now, let's just disable the check, so
that at least GIMP 2.10.6 is compatible with newer versions of
GEGL, no matter how we end up handling this.
In subdirs containing a generated foomarshal.h header, add the
generated sources to BUILT_SOURCES, so that they're generated
before the rest of the source files are built. Otherwise, since
there is no rule specifying the dependency between the rest of the
source files and foomarshal.h, and since foomarshal.h is not
checked into git (and hence doesn't exist when doing a clean
build), compilation of the said source files may fail if they're
built before foomarshal.h is generated.
(cherry picked from commit a5102a7dba)
Add a gimp-register-file-handler-priority procedure, which can be
used to set the priority of a file-handler procedure. When more
than one file-handler procedure matches a file, the procedure with
the lowest priority is used; if more than one procedure has the
lowest priority, it is unspecified which one of them is used. The
default priority of file-handler procedures is 0.
Add the necessary plumbing (plus some fixes) to the plug-in manager
to handle file-handler priorities. In particular, use two
different lists for each type of file-handler procedures: one meant
for searching, and is sorted according to priority, and one meant
for display, and is sorted alphabetically.
(cherry picked from commit b4ac956859)
...upon exporting an image
Step 1: make it configurable just like "Export EXIF" etc.
app, libgimp: add "export-color-profile" config option
Add it to the preferences dialog, and pass it on to plug-ins in the
GPConfig message. Add gimp_export_color_profile() to libgimp.
Nothing uses this yet.
(cherry picked from commit 8c9c091021)
Pass the current icon theme directory to plug-ins through the
config message, and add a gimp_icon_theme_dir() libgimp function
for retrieving it. Note that we already have a similar
gimp_icon_get_theme_dir() PDB function, which we keep around, since
it can be used to dynamically query for the current icon dir,
unlike the former, and since it returns a dynamically-allocated
string, while the rest of the config-related functions return
statically allocated strings.
Use the new function, instead of gimp_get_icon_theme_dir(), in
gimp_ui_init(). This allows gimp_ui_init() to run without making
any PDB calls. Consequently, this allows us to start plug-ins that
call gimp_ui_init() without entering the main loop in the main app.
We're going to add a plug-in that displays an interactive dialog
while the main app is blocking waiting for an operation to
complete, and we need to be able to start the plug-in without
entering the main loop, to avoid the possibility of arbitrary code
being executed during the wait.
Bump the protocol version.
