which gets added automatically by procedure_commands_get_display_args().
Move the non-interactive and run-with-last-vals code to
gimp_gegl_procedure_execute() (not execute_async()) because it makes
more sence to call it synchronously anyway (not implemented yet).
This commit should change no behavior.
Since commit bc4589968c, GimpFilterTool
assumes that color picking is only ever enabled through color picker
toggles, created using gimp_filter_tool_add_color_picker(). However,
the curves tool enables color picking using the color tool functions
directly. CRITICALS ensued.
Use the new gimp_filter_tool_enable_color_picking() function, added
in the previous commit, and handle picking through the filter tool
interface, instead of the color tool interface. This fixes the
issue.
Subclasses of GimpFilterTool should use these functions to control
picking, instead of using gimp_color_tool_{enable,disable}()
directly. This makes sure that the tool's picking state is
consistent, and allows the caller to control the pick identifier,
and use abyss picking (not currently needed by any subclass, but
maybe in the future, who knows.)
Return only the config object's GType and do the g_object_new() in the
caller (one caller only needs the type, there is no need to create a
dummy object just to get to its type).
around calling the actual execute vfuncs, Seen a crash when quitting
GIMP while a script-fu window was open, the progress was already
finalized. Now it simply prints the error message about the failing
script on the concole.
so they show up in recent filters, and don't need their own callbacks.
This has the problem that they now show a GUI with no options, but
that simply puts on more pressure to fix this general uglyness of ops
without editable properties.
We don't search recursively but only at the first level. If a plugin is
in its own subdirectory, the entry point has to be named the same (minus
extension) as the directory. For instance my-plugin/my-plugin for a
binary, or my-plugin/my-plugin.(py|exe|…).
This way, a plugin can load shared objects (libraries, other script
files, etc.) without polluting the main plug-ins directories, and in
particular without interfering with other plug-ins.
This is a first step to fix bug 757057 (DLL files which were used in
various plugins).
Commit 1e6acbd4e1 modified the
generated enum recipes to run gimp-mkenums from the source
directory, instead of the build directory, so that only the
basenames of the corresponding header files would appear in
the comment at the top of the generated files. This was a
mistake -- $(GIMP_MKENUMS) is expecting to be invoked from the
build directory.
Switch back to running gimp-mkenums from the build directory. To
avoid including the relative path from the build directory to the
source directory in the generated file, add a @basename@ production
variable to gimp-mkenums, which exapnds to the basename of the
input file, and use it instead of @filename@ in the recipes for the
generated enum files.
When regenerating an enum file, don't copy it back to the source
directory if it hasn't actually changed. This allows using a read-
only source directory where the enum header is newer than the
generated file, as long as they're not really out of sync.
OTOH, *do* touch the generated source-dir file even when unchanged,
in order to avoid re-running its recipe on the next build, however,
allow this to silently fail (which is harmless).
The layer blend space, composite space, and composite mode
properties have a special AUTO value, which may map to different
concrete values based on the layer mode. Make sure we can change
this mapping in the future, without affecting existing XCFs (saved
after this commit), by encoding these properties as follows:
When saving an XCF, if the property has a concrete (non-AUTO)
value, which is always positive, encode it as is. If the property
is AUTO, which is always 0, encode it as the negative of the value
it actually maps to at the time of saving (note that in some cases
AUTO may map to AUTO, in which case it's encoded as 0).
When loading an XCF, if the encoded property (stored in the file)
is nonnegative, use it as is. Otherwise, compare the negative of
the encoded property to the value AUTO maps to at the time of
loading. If the values are equal, set the property to AUTO;
otherwise, use the concrete value (i.e., the negative of the value
stored in the XCF).
Note that XCFs saved prior to this commit still load fine, it's
simply that if we change the AUTO mapping in the future, all their
AUTO properties will keep being loaded as AUTO, even if the
resulting concrete values will have changed.
... to the warp tool
The interpolation and abyss policy options control the sampler type
and abyss policy of the map-relative node. The high quality preview
option determines whether to use the same sampler for map-relative
during preview as the one used during commit, or whether to use a
fast nearest-neighbor sampler.
A bit too much? Maybe :)
... and to disable/control the rate of the periodic stroke.
The warp tool is now fast enough to enable stroking directly in
the motion handler, which gives better-quality response to motion
than stroking periodically. It's not quite fast enough to enable
exact motion, though :/
Allow individually enabling/disabling stroking during motion and
periodically, and allow controlling the rate of the periodical
stroke.
because the scale is useless otherwise with its range of 2..10000,
and because I needed a test case for the next commit (the
gimp_scale_entry_set_logarithmic() API was unused).
When using the MOVE behavior, don't append the current cursor
position to the stroke path in the timeout proc if the cursor
hasn't moved since last time. It has no effect, except for
requiring an unnecessary update.
When undoing a warp stroke, don't disconnect the current warp node
from its predecessor; rather, keep the graph as-is, and only
reconnect the render_node to the previous node. This avoids
invalidating the undone node, so that redoing it (which, likewise,
only involves reconnecting the render_node) doesn't require
reprocessing, making it much faster.
The spacing parameter controls the stroke spacing of the warp op.
It's similar, but not identical, to the brush spacing parameter of
the paint tools. It provides a tradeoff between speed and quality.
Change the UI range of the hardness parameter from [0, 1] to [0, 100],
to match the other parameters.
"layers-text-tool" action shows as "Text Tool" while "vectors-path-tool"
shows as "Path Tool". That's very confusing with tools-text and
tools-vectors respectively.
These actions are mostly about entering in edit mode with the active
layer or path. For text layers, it will enter text edition on canvas,
whereas just open the attributes edition dialog on other layers. For
consistency, layers-text-edit is renamed as well too layers-edit-text.
This also fix the side effect of commits 10099bd and 526918b where I
didn't realize that layers-text-tool was also working on non text layers
on purpose (being very badly named). Now there is a separate layers-edit
and layers-edit-text.
Thanks to Pat David for English corrections. :-)
Limit the number of lines drawn in the transform tool canvas grid to
one line every 5 image pixels. This should probably be done in display
pixels, didn't change that yet.
When transform tools are applied on a path, set their bounding box as follow:
- if a selection exists, use the selection bounds
- else if the path has a valid bounding box, use it
- else use the image canvas bounds
Also disable transform tools on an empty path (path without strokes) since
there is no data to transform.
Add support for The following GEGL op property keys, which shall
contain GUM expressions of the specified type, controlling the
corresponding UI attributes of the property's widget:
- sensitive [boolean]: controls widget sensitivity.
- visible [boolean]: controls widget visibility.
- label [string]: controls widget label (or the label of the
associated label widget).
- description [string]: controls widget tooltip text.
When any of above keys are present, the values they evaluate to take
precedence over the static values the corresponding attributes would
otherwise have.
GUM is a small DSL, used in some property keys of GEGL operations
to dynamically control UI attributes based on context. This commit
only adds an interpreter for the language; see the next commit for
the actual handling of the relevant keys.
See the comment at the top of gimppropgui-eval.c for a description
of the language.
Note that the interpreter is licensed under the LGPL.
If focus is on the layer list for instance, running this action from
right-click menu raises the on-canvas toolbar, ready for edition, with a
visible text cursor. But if the canvas has no focus (since you clicked
on the layer list, it has the focus), you still have to move your mouse
over and click the text on canvas. That doesn't make sense and there
would be barely any reason to use this over selecting the text tool then
clicking the canvas.
... non-text layers.
Since commit 10099bd, the action will be non-sensitive with non-text
layers, so if it happens, there is a bug somewhere. Therefore
g_return_if_fail() on this condition.
Moreover opening the edit attributes dialog was absolutely confusing on
what this action is supposed to do. We should not have these kind of
random behaviors.
When a layer is removed from a layer stack, and its backdrop needs
invalidating, emit the UPDATE signals for the backdrop only after
the layer has been removed from the container.
A subclass of GimpDrawableStack, for layer stacks. Invalidates the
layers' backdrop as/when necessary, according to the value of their
excludes_backdrop property.
Make gimp_drawable_stack_update() protected, instead of private, so
that we can use it in GimpLayerStack.
A boolean flag, specifying whether the backdrop is clipped to the
layer. That's the case when the layer's composite mode is dst-atop
or src-in.
This is a read-only property, derived from the other attributes of
the layer. We compute its value through a virtual function, so that
GimpGroupLayer will eventually be able to specialize it for pass-
through groups.
The next commit uses this property to actually do something useful.
Takes a layer mode and a composite mode, and returns the region
included in the composition.
Use this function in GimpOperationLayerMode, instead of testing
for specific composite modes directly. Will also be used by
the next commit.
Indentation cleanup in gimp_layer_modes.h
... so that we can use it for other functions that involve
compositing regions (which we do in the next commit).
Rename gimp_operation_layer_mode_get_affect_mask() and
friends to _get_affected_region().
With bigger and denser default images, the older 18px font default is
very small (~ 4pt font at 300PPI).
I decided to settle for a 15pt font, i.e. 62 px at 300 PPI, which seems
like quite an acceptable relative size for our FullHD defaults.
It is bigger than a default font size for —say— a text processor, but
GIMP is not really designed to process large walls of small text anyway.
Rather shorter texts at bigger sizes (i.e. designs, etc.). So this seems
like quite an ok default.
Note that as any defaults, this only goes as far and won't be what most
people need most of the time anyway. But at least we should get rid of
this ridiculous 18px default.
Michael Natterer