... "threads" property.
Actually there is no need of having a public GEGL_MAX_THREADS as written
in the previous commit. We can just retrieve the max for a GObject
property.
Raise GIMP_MAX_NUM_THREADS to 64, following the changes in GEGL (see
GEGL commits 6d128ac and f26acbb). This is still considered unstable and
to be used at one's own risk (cf. GIMP commit 1f5739d) but at least, it
could allow discovering and fixing bugs.
It would be nice if GEGL_MAX_THREADS could be public so that to not have
to edit this by hand at each change.
- trailing whitespaces cleaned out;
- vectors are called "path" in all visible strings;
- do not check for floating selection and active channel: oppositely to
layers, a vector can be selected in the same time as a channel, and
while there is a floating selection.
and update the grid as soon as a constraint is changed, not only on
the next motion. Change GimpTransformTool to forward the events to the
widget if it exists, but still handle them if it doesn't (yes this
code duplication is ugly, but the widget can hardly handle events if
it doesn't exist...).
More than 2000 lines of code less in app/, instead of
if (instance->member)
{
g_object_unref/g_free/g_whatever (instance->member);
instance->member = NULL;
}
we now simply use
g_clear_object/pointer (&instance->member);
Change the text selection to draw an outline around each selected
glyph. It looks just as ugly as before but at least keeps the text
readable regardless of its color.
if did revert to the previous selection and thus break stuff like
enbaling quick mask or inverting the selection, because I merged the
undo magic it does into gimp_rectangle_select_tool_halt(), whereas
before it was done by the former gimp_rectangle_tool_cancel(), so only
on explicit cancel not HALT from whatever source.
Do the same in the new code and move the undo magic from halt() to
rectangle_response(CANCEL), which is exactly the same distinction as
with the old GimpRectangleTool code.
When the user provides a filename without an extension in the save
dialog, we add one for them, update the filename in the dialog, and
retry. However, the updated filename is made up of only the
basename, leaving out the dirname part, if specified. This means
that if the user enters "/somedir/somefile", the new filename
becomes "somefile.xcf", which refers to the current directory,
instead of "somedir".
Fix this by maintaining the dirname when adding a file extension.
Don't unconditionally call COMMIT in rectangle_response(), because
that now implicitly HALTs the tool. Instead, check if we got here
because of a click, and call our commit() directly.
which is the same as g_object_class_list_properties() but filters
out the properties for which we don't want to create a GUI.
Use it in gimp_prop_gui_new().
GimpOperationTool's aux inputs were not properly ported to the new way
filter tools work (complete destruction and re-creation of the tool
dialog).
Split creating the operation GUI and adding it to the dialog into
separate functions, and call them at the right places.
Call HALT generically in gimp_tool_control() after calling COMMIT, and
remove all hacks in tools that call both COMMIT and HALT or call
halt() from commit().
Some tools interact with their subclasses (e.g. filter tool and
operation tool), and it's essential that COMMIT runs through the
entire class hierarchy before HALT.
Probably breaks something, please test.
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.
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.
- introduce new state "boolean is_first" which tracks if the currently
drawn rectangle is the first with this instance
- cancel the widget if there was no movement when creating the first
rectangle
- undo to the previous rectangle if the user created a zero-extent
rectangle
- also undo to the previous rectangle if a newly drawn rectangle is
canceled with button-3 release
We can't rely on g_object_unref() in halt() for breaking all property
GBindings between the tool options and GimpToolRectangle, because we
might be in the middle of a signal emission which also refs and keeps
the rectangle alive until the last callback returns. So we had
dangling rectangles interacting with tool options.
Remember all bindings in a list, and break them explicitly when we
shut down the rectangle in halt().
Also, forgot to unset the display's highlight in the rectangle
selection tool.
because of bailing out early after emitting "response". Instead, don't
ref the object around this function, and move the "response" emission
to the end of the function.
The tool manager still keeps an active tool which it unrefs on
destruction, triggering a final HALT on the tool, which may want to
lookup tool options to reset something. Happened with the new
widget-ported rectangle select tool.
- enable the setting code in gimp-gegl.c again
- but set the default to one thread in GimpGeglConfig, with a CPP warning
- rename "processors" to "threads" in the GUI
- add a warning box about unexpected results when increasing #threads
Michael Natterer