The mouse controller had many limitations:
* It was not per-device.
* It was a long hard-coded list of events, which made its evolution
annoying and scrolling the list boring.
* It was starting at button 8, while the first buttons were supposed to
be hardcoded interactions. And it stopped at button 12, while some
device might have more buttons nowadays. See !386.
* The "Grab event" does not seem to work in many cases, according to
feedbacks.
The new GimpModifiersEditor will now handle any button (except the first
button, which is reserved for tools), you can even override or change
default canvas actions (panning, rotation, etc.). It should not be
limited with a max button number either (though I haven't tested with a
device really having a lot of buttons since I don't have any such device
but I did emulate huge button numbers on my stylus with xsetwacom and it
did work well; hopefully I'll get feedbacks). And now it can even run
custom actions.
So basically it should deprecate the mouse controller as the modifiers
editor can do everything the controller could, and more (unless I missed
anything).
When no accelerator was set yet, display relevant information, and when
the button is toggled (waiting for shortcut input), display also
relevant info.
intltool has long been dead upstream. Let's not poke the dead corpse,
please.
This commit is quite large, but that's mostly since trying to support a
hybrid of both gettext and intltool with both Meson and Autotools was
really hard, so I stopped trying.
Due to gettext relying on quite some things being at the exactly right
place in the autotools build (like `ABOUT-NLS` and `config.rpath`) we
really needed to cleanup the `autogen.sh` to only call `aclocal` and
`autoreconf`. No more strange magic; I tried to do it without changing
too much in the file, and things just broke. If people want to do
something more custom, they can just change the script directly. This
change also uncovered some problems in our `configure.ac`, like using
deprecated macros.
The following major changes happened:
* meson: Changed `custom_target()` to `i18n.merge_file()` for all
supported file types
* Added `.its` and `.loc` files for the GIMP-specific XML formats, so
that gettext understands them
* For the `.isl` (Window installer stuff) file, there's no easy way to
do this in gettext, so instead we start from an XML file (again with
its own ITS rules etc), translate that with gettext, and then use
`xsltproc` with a bit of magic to output the .isl file for each
language
* the `po*/Makefile.in.in` files are migrated to `Makevars` files,
which gettext natively understands.
Fixes: https://gitlab.gnome.org/GNOME/gimp/-/issues/8028
See the commit 28467cb on the gimp-data-extras repo where I moved this
data in. Not sure why this metadata file was ever pushed to the main
repo as it is obviously for the data-extras package (or else I am
missing some information!).
The old 2017 report where it was originally added:
https://bugzilla.gnome.org/show_bug.cgi?id=763398
In tool-group GimpToolButton tooltips, in addition to showing the
description of the currently-active tool, list the other tools in
the group as well, to improve discoverability.
gegl:focus-blur blurs the image around a focal point. It can be
used to create fake depth-of-field effects.
Add a prop-gui constructor which uses a FOCUS controller to control
the focus geometry.
Add a new GimpToolFocus tool widget, which defines a focus region,
consisting of an inner limit, an outer limit, and a transition
midpoint between them. The widget allows controlling the limits
and the midpoint, and moving, scaling, and rotating the region.
Add a new GimpOperationSettings class, to be used as a base class
for all operation-config types. The class provides options common
to all operations (namely, the clipping mode, input region, and
color options), which were previously stored in GimpFilterOptions,
and were therefore bound to the filter tool, instead of being
stored as part of the operation settings; as a result, these
options would have no effect when reapplying a filter, or when
restoring a preset.
The GimpOperationSettings options do not affect the operation
node, but rather the associated GimpDrawableFilter object. The
class provides a gimp_operation_settings_sync_drawable_filter()
function, which applies the options to the filter.
Modify all custom and auto-generated operation-config types to
derive from GimpOperationSettings, and modify the GimpConfig
functions of the former to account for the GimpOperationSettings
properties, using a set of protected functions provided by the
class.
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.
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.
Add a new 3D Transform tool, based on GimpToolTransform3DGrid,
added in the previous commit. The tool UI provides a notbook with
three tabs, corresponding to the three GimpToolTransform3DGrid
modes:
Camera - allows setting the primary vanishing point, as well as
the camera's focal length, expressed either directly, or as the
camera's angle of view, relative to the whole image or the
transformed item. By default, the vanishing point is aligned
with the item's center, and the angle of view is fixed relative
to the item; this essentially means that each item is transformed
using a local perspective, independent of its position and size
relative to the image. A global perspective can be achieved by
using a common vanishing point and focal length (or an image-
relative angle of view).
Move - allows moving the item using X, Y, and Z offsets.
Rotate - allows rotating the item using X, Y, and Z Euler angles.
The order of rotation of the different axes can be controlled by
a set of numbered buttons next to the sliders, and the rotation's
pivot can be controlled using a pivot selector.
Add a new GimpToolTransform3DGrid tool widget, subclassed from
GimpToolTransformGrid, which can be used to perform 3D
transformations.
The widget can be in one of three modes:
CAMERA - allows adjusting the primary vanishing point by moving a
handle.
MOVE - allows moving the object through dragging.
ROTATE - allows rotating the object through dragging.
By default, controlling the transformation through dragging applies
to the X and Y axes. Holding Shift (or setting the "constrain-
axis" property) restricts the motion to only one of the axes.
For the MOVE and ROTATE mode, holding Ctrl (or setting the "z-axis"
property) allows controlling the Z axis instead.
For the same modes, holding Alt (or setting the "local-frame"
property), applies the adjustments in the object's local frame of
reference, instead of the display's global frame of reference.
Blacklist the "tools-offset" action in the GUI, and only keep
"filters-offset", to avoid duplication. Update gimp:offset's
description, so that "filters-offset" gets a proper tool-tip.
Add a new Offset filter tool, as a front-end to gimp:offset. The
tool replaces, and provides the same interface as, the drawable-
offset dialog, while also providing live preview and on-canvas
interaction.
Note that we don't simply use a custom propgui constructor for
gimp:offset, since we need a little more control.
We currently have brush and pattern I/O code in both the core and
plug-ins. This commit starts removing plug-in code in favor of having
one copy of the code in the core, much like XCF loading and saving is
implemented.
Add app/file-data/ module with file procedure registering code, for
now just with an implementation of file-gbr-load.
Remove the file-gbr-load code from the file-gbr plug-in.
Add on-canvas GUI (simple lines) for circular, linear and zoom motion
blur. The restrictions in the interaction show pretty well that there
is room for improvement here, the line is just a bit too generic, but
it's better than nothing.
This commit completely removes the "Edit -> Fade..." feature,
because...
- The main reason is that "fade" requires us to keep two buffers,
instead of one, for each fadeable undo step, doubling (or worse,
since the extra buffer might have higher precision than the
drawable) the space consumed by these steps. This has notable
impact when editing large images. This overhead is incurred even
when not actually using "fade", and since it seems to be very
rarely used, this is too wasteful.
- "Fade" is broken in 2.10: when comitting a filter, we copy the
cached parts of the result into the apply buffer. However, the
result cache sits after the mode node, while the apply buffer
should contain the result of the filter *before* the mode node,
which can lead to wrong results in the general case.
- The same behavior can be trivially achieved "manually", by
duplicating the layer, editing the duplicate, and changing its
opacity/mode.
- If we really want this feature, now that most filters are GEGL
ops, it makes more sense to just add opacity/mode options to the
filter tool, instead of having this be a separate step.
We currently construct the tool-options GUI for all the tools at
startup, which takes a significant amount of time. Instead,
only register the GUI construction function with the tool-options
object, using the new gimp_tools_set_tool_options_gui_func()
function, and use the registered function to construct the GUI when
actually needed.
Anders Jonsson