Implementing a shiny new GimpFileProcedure doesn't mean the libraries
we use to load/save files are automatically capable of handling remote
files, so we still need this flag.
Add a gimp-rotate-image-arbitrary action, and a corresponding
"Image -> Transform -> Arbitrary Rotation..." menu entry, which
activates the rotate tool in image mode (similarly to the
corresponding action for layers).
... so that the original transform-type of the rotate tool is
restored once the layer is rotated. Additionally, make sure to
set the tool's transform-type even if it's already active.
... which temporarily changes the transform-type of the tool,
restoring the original type once it's halted. To be used when
activating a transform tool through an action for a specific
transform type.
Add a new "Image" transform type to the transform tools, in
addition to the existing "Layer", "Selection", and "Path" transform
types. The "Image" mode transforms the entire image, rather than a
single item. In tools with a preview, the preview shows the
transformed image projection. The clipping mode controls how the
canvas is clipped during the transform; in particular, the ADJUST
clipping mode resizes the canvas to fit its transformed size.
In GimpCanvasTransformPreview, use a GimpPickable, instead of a
GimpDrawable, as the preview source, so that we can use it with the
image projection, rather than just with drawables.
... which controls whether or not the image is rendered by the
shell. We'll use this to hide the image while showing its
transform preview in the next commits.
Add a new gimp_image_transform() function, which transforms the
entire image, including all layers, channels (including selection
mask), vectors, guides, and sample points, according to a
transformation matrix. The canvas is resized according to the
clip_result parameter, the same way drawables are resized during
transformation; the layers are resized using ADJUST mode
regardless.
... which takes the symmetry axis as a parameter, instead of hard-
coding the axis to the middle of the image, and which additionally
takes the clipping mode as a parameter, controlling whether to clip
or resize the canvas. Note that the actual canvas size never
changes, but it may be offset when flipped around an off-center
axis, without clipping.
Implement gimp_image_flip() in terms of gimp_image_flip_full().
which are GimpProcedure subclasses with API to register as load/save
handlers and their own kind of run functions that get their standard
arguments passed directly instead of packed into a GimpValueArray.
They also register their standard arguments themselves, which removes
quite some boilerplate from load/save plug-ins.
Remove gimpprocedure-private.[ch] because install() and uninstall()
are now virtual functions of GimpProcedure.
While doing so, better break the various source categories in libgimp/.
Otherwise we were duplicating some of the header list, hence we forgot
to install some of the headers.
The `GIMP_CONFIG_PROP_*` macros do not automatically set
`G_PARAM_STATIC_STRINGS`, which means each property that uses such a
macro does not have this flag set by default (and almost none set it
themselves). By adding `G_PARAM_STATIC_STRINGS` to
`GIMP_CONFIG_PARAM_FLAGS`, we can prevent this from happening, which
should lead to some unnecessary string copies being prevented.
In the various PDB transform functions, avoid erroneously creating
a floating selection when transforming the image mask, and rather
transform the mask normally.
Remove the special clipping-mode handling for channels throughout
the transform (and drawable-filter) code, and rather use
gimp_item_get_clip(), added in the previous commit, instead. As
mentioned in the previous commit, we only modify the clipping mode
in top-level code, while having lower-level code use the clipping
mode as-is. This not only hides the actual clipping-mode logic
from the transform code, but, in particular, allows code performing
transformation internally to use arbitrary clipping modes.
Also, this commit fixes a bunch of PDB bugs all over the place :)
Add a new GimpItem::get_clip() virtual function, and a
corresponding gimp_item_get_clip() function, which return the
actual clipping mode to be used when transforming (or applying a
filter to) a given item, given the original clipping mode. This
applies only to whole-item transformations (i.e., when not creating
a floating selection), and should be used by the top-level code
applying the transformation, rather than by the actual
transformation code, so that the item can be transformed using a
different clipping mode internally.
Provide a default implementation that simply returns the input
clipping mode, and override for GimpChannel (to always return CLIP)
and for GimpVecotrs (to always return ADJUST).
As discussed on IRC, I am not sure if really this is needed, since
theoretically we now have support for a whole bunch of languages without
doing anything (languages supported by GObject Introspection) and we are
not going to check for all of them.
Yet since now we install one JS plug-in, let's still do a quick check.
We'll see later if we want to change how we handle supported script
languages.
Rather than looking for pygobject-3.0 with pkg-config, run an actual
test in python, loading the 'gi' module.
I also added a version parameter making it possible to even check for a
required version of PyGObject, though it is currently unused (as I have
no idea if we have a minimum requirement for our plug-ins to work well).
This is an improvement of commit 8e938e0960 as I realized that we don't
need any development files, therefore I don't think that searching with
pkg-config was the right idea in our case.
We don't actually need any of the Python dependencies at runtime. We
only check for these to make packagers aware of the runtime need. Force
the build to go forward even with these deps.
If we decide to look for Python dependencies, we should also look for
pygobject as it provides the GI binding to Python.
I'm still not sure if we should look for these runtime dependencies at
configure time. But for the time being, if we continue doing so, let's
do it right.
The file path was already the same as ARGV first argument (i.e.
System.programInvocationName as I added this myself!). Why did I even
bothered with this annoying trick!
This makes the code much simpler, which is better for demo code.
Right now it is not working, always because of the same bug about not
being able to create GParamSpec (pygobject#227). As a consequence, I
tried a workaround by creating object properties and using their spec
instead. But it turns out that in pygobject, I cannot create random
properties for custom types (well I could for boxed types or GObject
subclasses, not for GimpImageID or GimpDrawableID). Cf. pygobject#357.
So I am stuck again.
Anyway I still push this demo file which would just work as it is, if we
coult at least got the image/drawable ID.
I comment out the Makefile.am part for now until we can get the issues
sorted out.
and proper callback annotations. Also move the three callback typedefs
from gimpcolortypes.h to gimpadaptivesupersample.h because they are
needed nowhere else.
Michael Natterer