Currently, toggling RGB565 makes the RLE toggle insensitive, but
if RLE is checked beforehand RLE is used anyway, with incorrect
results.
Fix this by adding RLE support for RGB565 data.
Need to keep around the operation's name and its description, so
everything can be re-created when an image is clicked.
Instead, completely shut down GimpOperationTool when GimpGeglTool is
halted, so the next click will bring up a dialog with only the
operation selection combo.
There are now (up to) three steps to locate an installed darktable used
to load raw files:
1. The environment variable DARKTABLE_EXECUTABLE. It should point to the
main darktable executable without any file extension. So on Windows
leave the ".exe" away!
2. If the environment variable isn't set there is a platform dependent
part. On OSX it uses Kris' code to look for installed app bundles, on
Windows it checks for the registry key written by darktable's installer.
3. Last but not least we fall back to crossing our fingers and hoping
that darktable is in PATH.
which allow to override stuff from GimpToolInfo for dynamic tools like
GimpFilterTool and friends. When NULL, the getters are falling back to
GimpToolInfo strings.
...and "export_dialog_title"
It's ridiculous to keep this code around for strings that are only
marginally different (and not better) than the strings we can generate
from other strings we have anyway.
to ::can_undo() and ::can_redo(). They still return description
strings and the new naming is slightly off :) but get_undo_desc() will
be needed for something else soon, and half of the time the functions
are indeed used to check whether there are undo/redo staps at all.
Switch the gegl:spiral prop gui from using a line controller to
a slider-line controller, and use sliders to control the "balance"
and "base" properties.
Add supprt for placing sliders on a GimpToolLine -- handles that can
be dragged over the line. The sliders are accesible through a new
"sliders" property, and via the gimp_tool_line_{get,set}_sliders()
functions.
Add a slider-line controller, which works like a line controller,
but whose callback also supplies/takes an array of sliders.
Note that the data type for individual sliders is called
GimpControllerSlider (in particular, it's not line specific), so
that we may use it with other controller/tool-widget types in the
future.
Use the new gimp_filter_tool_get_drawable_area() instead of always
using gimp_item_mask_intersect() which is only right when the
operation is applied to the "selection" region. Also call
gimp_operation_tool_sync_op() when the region is changed in the UI.
Don't offset the ui range of op properties that use pixel-distance
units to the top-left corner of the region, since they're relative;
only do that for pixel-coordinate units. Let their ui range be
[0, width/height].
Pass a "GimpCreateControllerFunc" to all gimppropgui-*.[ch]
constructors which takes a callback (to update the config object when
the on-canvas GUI) and a controller type that determines the
callback's signature, and returns another callback (to update the
on-canvas GUI when the config object changes).
In GimpOperationTool, pass such a GimpCreateControllerFunc that
handles creating and adding on-canvas controller via the new
gimpfiltertool-widgets.[ch]. So far, a simple line like in the
blend tool is supported.
Add a custom GUI for gegl:spiral, and have its origin, radius and
angle controlled by such a line.
which return's the used drawable's offsets and a GeglRectangle
where the filter is applied according to GimpFilterOptions::region
(either the selection or the whole drawable).
and call it from GimpFilterTool's "notify" callback. Remove signal
connections from all subblasses and instead implement ::config_notify().
The config object belongs to GimpFilterTool, and only GimpFilterTool
should know when it's created and can be connected to.
so things from the tool's previous use get destroyed, including their
(maybe dangling) signal connections. Also shut down more stuff in
halt(), including destroying not just hiding the GUI.
because widgets are bound to one GimpDisplayShell. Also, chain up
unconditionally in gimp_color_tool_draw(), we always want to draw the
widget even while picking colors.
The widget is fed events by GimpFilterTool, the actual interaction
with the filters operation and config will be done by subclasses.
The order of precedence when there are multiple possible canvas
interactions is: moving the split preview guide, color picking,
widget.
Piotr Drąg