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)
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.
Add new PDB group "drawable_edit" which has all procedures from the
"edit" group which are not cut/copy/paste.
The new group's procedures don't have opacity, paint_mode
etc. arguments but take them from the context instead. Unlike the old
gimp-edit-fill, gimp-drawable-edit-fill now uses the context's opacity
and paint_mode.
The new gimp-drawable-edit-gradient-fill procedure uses even more
context properties which are also newly added with this commit
(gradient_color_space, gradient_repeat_mode, gradient_reverse).
And some cleanup in context.pdb.
This is still WIP, nothing in the edit group is depcreated yet.
because it confuses gtk-doc and breaks some links. Also change the
"Index of new symbols in GIMP 2.x" sections to be what seems to be the
modern standard (looked at the GLib and GTK+ docs), and update some
other stuff.
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.
Move the pixbuf layer and image thumbnail function from libgimpui to
libgimp and move gimp_layer_new_from_pixbuf() to gimplayer.[ch] where
it belongs. Change gimp-2.0.pc accordingly, adapt plug-in Makefiles
and update devel-docs.
