This is just some preparation for fixing issue #1805, but actually
"target" is a much better name so I went the full way and also changed
GUI labels and the color picker tool options config property
accordingly.
If anyone notices at all, how horrible is it to lose your saved pick
target...
(cherry picked from commit b140b283dc)
After last commit, all paint tools work correctly with a separate
paint thread, so we can remove the option for specific paint tools
to opt out. Particularly, GimpMybrushTool now uses a separate
paint thread too.
Note that the separate paint thread can still be disabled through
the GIMP_NO_PAINT_THREAD environment variable.
Add gimppainttool-paint.[ch], which takes care of painting during
motion events in GimpPaintTool. Perform the actual painting in a
separate thread, so that display updates, which can have a
significant synchronization overhead, don't stall painting.
Allow specific paint tools to opt-out of a separate paint thread,
and avoid it in GimpMybrushTool, since it doesn't seem to work.
The separate paint thread can be explicitly disabled by setting the
GIMP_NO_PAINT_THREAD environment variable.
Remove all stock items added since 2.8, restore accidentially removed
ones, and rename the newly added GIMP_STOCK_* defines to GIMP_ICON_*.
(will move to having GIMP_ICON_* defines instead of magic hardcoded
strings for all icons).
Add generic tool actions for spacing, hardness and force, and the
GimpToolControl infrasctructure to redirect them to tool-specific
actions. Add tool-specific actions for GimpBrushTool, GimpMybrushTool
and GimpWarpTool as redirect targets. Also fix some existing tool
action callbacks to use the right increase/decrease steps.
- GimpContext API and property
- a GimpDataFactory
- List and grid views with GimpDataFactoryView
- actions and a context menu
None of this is connected to the actual tool yet, or depends on
libmypaint in any way.
