Even when we already notify of an update, we should leave the ability to
query the last gimp_versions.json manually.
It would allow also people who disabled automatic check at startup
(whether through preferences or because the build disabled the feature
altogether) to still make update checks, and to not be forever stuck
with the result of an outdated version check.
In GimpPaintTool, track the cursor position separately from the
current paint core position, so that the brush outline doesn't lag
behind the cursor while painting.
... containing a floating selection
When destroying a GimpGroupLayer, remove all the children signal
handlers before destroying the container, so that we don't attempt
to reallocate the group's projection in response to
"update-bounding-box" signals emitted during layer destruction,
which can happen for floating selections.
The idea is to be able to advertize a new revision of the same version
of GIMP. For instance, this would apply when we release a
`gimp-2-10-14-setup-3.exe` Windows installer (then we are at revision
3, provided we started at revision 0).
The revision number is obviously only relevant to a given platform and
version. Also the concept of build ID allows to differentiate various
builds for a same platform, in particular to not look at revisions of
third-party builds. The build ID can be any string. Maybe we could just
use reverse DNS build id (such as "org.gimp.GIMP_official") to identify
the official GIMP build. So in the end, we only compare revisions for an
identical (version, platform, build-id) tuple.
Allows to disable the automatic update check at startup. I believe some
packagers will want such options, in particular on Linux distribution
(where they control their own release schedule and won't want GIMP to
pop new version warning up because they have been slow to update their
package).
Note that it is still possible to query version checks manually in the
about dialog, but the automatic check/popup is gone with this option.
In the Warp tool, handle the brush-outline and cursor prefernces
(namely, show-brush-outline, snap-brush-outline, and
show-paint-tool-cursor) similarly to the paint tools.
Add a new "Snap brush outline to stroke" toggle to the "Image
Windows" preferences page. When enabled, the brush outline in
paint tools snaps to the individual dabs while painting, instead of
following the cursor precisely (this is the existing behavior).
When disabled, the brush outline follows the cursor while painting
in the same way it does while not painting.
Disable the option by default. This seems to be what most other
programs are doing, and it does give paitning a smoother feel.
Change the default mode of the 3D Transform tool from CAMERA to
ROTATE. Canvas interaction is limited in camera mode, while
rotation is the main function of the tool.
Add a new GimpToolInfo::experimental boolean field, and mark
GimpNPointDeformationTool and GimpSeamlessCloneTool as
experimental. In gimp_tools_deserialize(), don't reject the file
if the only missing tools are experimental, but rather add them to
the passed container. In particular, this prevents us from
rejecting the default toolrc file when experimental tools are
enabled.
Now that painting is done in a separate thread, the display update
rate has a far smaller impact on it. Increate the GimpDrawTool
update rate to 120 FPS. This makes brush-outline motion much
smoother.
In the Foreground Select tool, use the drawable bounds (including
its offset) as the trimap buffer extents, which is now supported by
the rest of the code. This is both more streamlined, and works
around a GEGL bug (independently fixed by commit
gegl@378cd512c35fe2eb255492f90b503a67ab38d7a3), causing
gegl:matting-global to segfault when the drawable and trimap bounds
are differnet.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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! :)
In GimpToolPalette, allow for a single-column layout, which is more
practical now that we have tool groups. Note that other widgets in
the toolbox pane might still prevent a single-column layout, in
particular, the empty-dock label.
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.
Tim Sabsch