In GimpCanvasBufferPreview, take a strong reference on the preview
buffer, fixing a segfault in the foreground-select tool when
switching engines while the grayscale preview is active.
(cherry picked from commit ea864e2d5c)
... and gimp_gegl_mask_combine_buffer()
Allow the functions to work with buffers whose top-left corner is
not at (0, 0).
(cherry picked from commit 24534338e7)
While GimpPolygonSelectTool is active, don't let GimpSelectionTool
handle the Shift/Ctrl modifiers, which are handled by the tool
widget, unless they're used in combination with Alt, in which case
they're used to move the selection, instead of control the
selection mode.
(cherry picked from commit 0c917cb359b0ace43f82c68e36e64221ab1bcf91)
Add a new GimpSelectionTool::have_selection() virtual function,
which determines if the image has a selection (default
implementation), or if the tool will create one upon committing
(implemented by subclasses). Use this function in
gimp_selection_tool_oper_update() to determine the tool function;
in particular, don't use SELECTION_MOVE and SELECTION_MOVE_COPY
when there's no selection.
Override have_selection() in GimpFreeSelectTool, and return TRUE if
we have a polygon with three or more vertices, which will create a
selection upon committing.
(cherry picked from commit aeff0d6207463d0ed6f97e39e6b2450a60715863)
This commit removes the empty-dock-pane message, and instead
highlights all empty dockable drop-target areas once a drag
operation begins.
Add new gimp_dockbook_{add,remove}_callback() global functions,
which can be used to register a callback function to be called when
a dockable drag operation begins and ends.
Register such a callback in GimpPanedBox, and use it to highlight
all drop areas the widget handles. Furthermore, when the widget is
contained in a GtkPaned, make sure that it has a minimal size for
the duration of the drag operation, so that the drop area is
visible even if the widget is normally hidden.
In GimpToolEditor, update the visibiltiy-toggle state in response
to the corresponding tool-item's "notify" signal, rather than its
"shown-changed" signal, since the latter is not emitted when the
item's visibility changes while it's not shown.
(cherry picked from commit df19401fb3)
Add a new Gimp::tool_item_ui_list, which is a GimpTreeProxy over
Gimp::tool_item_list. This allows us to use either a hierarchical
or a flat tool list in the UI, by setting the "flat" property of
the new list.
Use Gimp::tool_item_ui_list in GimpToolPalette, so that the toolbox
layout is affected by this choice.
Add a "Use tool groups" toggle to the toolbox preferences, and bind
it to the "flat" property of Gimp::tool_item_ui_list.
(cherry picked from commit 3cda972100)
Add a new GimpTreeProxy container class, which proxies a
GimpViewable tree. The proxy has a dynamically-settable boolean
"flat" property, which controls if the tree hierarchy is preserved,
or if it's viewed as a flat list.
(cherry picked from commit 2caa518b19)
Add a new GimpContainer::search() virtual function, and a
corresponding gimp_container_search() function, which works
similarly to gimp_container_foreach(), except that the callback
returns a boolean. When the callback returns TRUE, the search is
stopped, and the current object is returned.
Implement GimpContainer::search() in GimpList.
(cherry picked from commit c4cc015c43)
Add a new read-only GimpToolItem::shown property, and a
corresponding GimpToolItem::shown-changed signal, which determines
if a tool item is visible throughtout the hierarchy, i.e., if it
and all its ancestors are visible. This replaces
gimp_tool_item_is_visible().
Use the new property and signal in GimpToolPalette and
GimpToolEditor, to simplify the code, and in preparation for a flat
toolbox view.
(cherry picked from commit ee9661237e)
In GimpToolManager, use a weak pointer for tracking the active tool
group, instead of taking a reference on it. This avoids
erroneously extending the group's lifetime, which can cause
problems with the tool-item hierarchy.
In GimpToolGroup, make sure that newly-added tools don't already
have a parent.
(cherry picked from commit 30d833d00f)
When the active tool of the tool group associated with the
currently-selected tool changes, we select the new active tool;
this is currently handled in GimpToolButton. Move this logic to
GimpToolManager, which already handles the other half of the
problem: updating the group's active tool when one of its tools is
selected.
Add a default toolrc file, installed in the sysconf dir, with a
more minimalistic tool layout using groups, inspired by Photoshop
(not identical, though, don't kill me! :)
Reduce the size of the toolbox color area, and make it square.
This allows for a narrower toolbox layout, which is more practical
now that we have tool groups.
Add a new GimpToolButton class, used for tool-buttons in the
toolbox, instead of implementing them directly in GimpToolPalette.
Each GimpToolButton is associated with a GimpToolItem, which can be
either an individual tool or a group.
When a tool button is associated with a group, it displays the
group's active tool, with an arrow at the corner. Clicking the
button selects the active tool, while clicking-and-holding, or
right-clicking, shows a menu of all the tools in the group.
Alternatively, the active tool can be changed using the scroll
wheel.
In gimp_button_menu_position(), position the menu at the same
height as the button, instead of half-way down. This is mostly a
stylistic choice, but it works much better for tool-button menus,
added in the next commit.
Move the logic for translating a tool identifier to a corresponding
action name to GimpToolInfo. It's currently only used in
tools-actions.c, but the next commits will use it in tool buttons.
Allow creating GimpToolInfo objects with a NULL menu label, and do
that for GimpOperationTool. The previous commit effectively
removed it from the Preferences tool editor, and this commit also
removes it from the action search.
Add tool-group support to GimpToolEditor, used to organize tools in
the Preferences dialog, including creating, rearranging, and
deleting groups. Also, major cleanup.
In the default implementation of
GimpContainerTreeView::drop_viewable(), handle the case where the
source and/or destination viewables are not direct descendants of
the tree-view's container, but rather of one of its subcontainers.
Allow calling gimp_scanner_new_string() with a NULL `text` and a
negative `text_len` (which is interpreted as 0), instead of
requiring `text_len == 0` in this case. This allows passing a
negative `text_len` unconditionally to infer the length, even when
the string may be NULL.
Add a new Gimp::tool_item_list list, in addition to
Gimp::tool_info_list. The latter may contain arbitrary tool items,
including tool groups, and is intended for use in the UI (namely,
the toolbox and the preferences tool editor).
In gimp-tools, use Gimp::tool_item_list for representing the UI
tool order (while still using Gimp::tool_info_list as a flat list
of all GimpToolInfo objects), and add support for saving and
loading tool groups to/from toolrc.
Introduce file-version tracking in toolrc, and drop its contents on
version mismatch, or when new tools are introduced. This is
slightly disruptive, but merging new changes with existing toolrc
files is non-trivial, and it doesn't happen very often.
Add support for a sysconf toolrc file, which is used if there's no
user toolrc file (i.e., on first use). If neither file is found,
the hard-coded flat tool order is used. This commit doesn't
provide a default toolrc file, but the next commits will.
Make the gimp-tools serialization and deserialization functions
public, for use in GimpToolEditor in the next commits.
... if not using unique names
Add a new GimpContainer::get_unique_names() virtual function, and a
corresponding gimp_container_get_unique_names() function, which
determines if the container uses unique names for its objects.
Override get_unique_names() in GimpList, to return the corresponding
property.
In gimp_container_deserialize(), don't merge new objects with
existing objects sharing the same name if the container doesn't use
unique names.
Add GimpToolGroup as a new subclass of GimpToolItem, representing a
collection of tools. The end goal is to display tool groups using
a single button in the toolbox.
Tool groups are not recursive: they can only contain individual
tools, not other groups. Each group has a single "active tool",
normally the most-recently-used tool of the group, which is
activated when clicking on the tool's button.
Add GimpToolItem as a common base class for toolbox items.
Derive GimpToolInfo from GimpToolItem, representing an individual
tool. The next commits add support for tool groups, represented by
an alternative subclass of GimpToolItem.
Most of the tool-info properties remain in GimpToolInfo, however,
GimpToolItem takes care of tool-item visibility.
Changed the reflection method to find the middle of the slice the
user is drawing on, and reflecting on that. This reflects the slice
in place, making it easier to rotate it to the intended location.
This fix preserves the order the dabs are drawn on the
slices, to be counterclockwise.
Fixed the brush transform, by setting the reflect output variable,
and calculating accordingly.
(cherry picked from commit ed6517f094)
When dowscaling an image (or a layer group), empty layer groups
can be discarded as a result of their new dimensions being too
small, since we're calculating their new dimensions according to
their fake 1x1 dimensions. However, these dimensions are purely an
implementation detail and shouldn't affect the result, and neither
do we show a warning for them.
Instead, simply avoid discarding empty layer groups.
(cherry picked from commit b99a2631ef)
Restrict last commit's workaround to layer groups only (which is
the only relevant case ATM), since it negatively impacts the warp
tool, which does rely on the ability to perform (accurate) partial
updates with filters to improve performance. It's only a temporary
hack anyway.
(cherry picked from commit 18870975b8)
When a drawable has filters attached, they may influence the area
affected by drawable updates. Currently, we ignore that, updating
the original region regardless. This can lead to drawable updates
not affecting the correct regions. This couldn't be triggered
until now, but since layer groups can now have a transform op
attached as a filter, updates to their sublayers -- which can
happen while the transform tool is active -- run into this problem.
Fix it for now by simply updating the full drawable region when the
drawable has filters. This is a very conservative approach -- we
don't even bother checking if we're only dealing with point
filters, as this change only influences transformed groups right
now. Ultimately, we need to rely on node invalidation to drive
updates, which takes this into account.
(cherry picked from commit 8be0e646bc)
