When auto expanding layers, there is an option that allows user to fill
the newly expanded part with the pattern. But without this change, it
was not possible to change the active pattern without switching to some
other tool like bucket fill tool. This commit allows that.
Also added option in Edit->Preferences->"Tool Options"->"Paint Options
Shared Between Tools" that decides weather the options should be shared
between different tools.
… new action_pixel_size of GimpMyBrushTool.
MyPaint brush tool clearly shows the limits of my trick to have some
enum actions work with absolute values whereas others work with
per-mille values between the property min and max.
Indeed firstly MyBrush's "radius" value is logarithmic and can be
negative. Since the enum trick relies on the fact that negative values
are the semantic enumerated constants, it's broken in such case. The
second issue is that while it was acceptable to use int size for most
paint tools (even though they were double), here radius only goes from
-2.0 to 6.0; so using int values only would leave us with jumping brush
sizes.
So now I create a proper double action which simply takes pixel size and
use this from the on-canvas brush size changing. No weird trick, no int
or sign limitations.
I also add a new optional action_pixel_size in GimpToolControl.
Note: I'm also updating a bit the logic for the MyPaint brush outline
function gimp_mybrush_tool_get_outline(). Indeed after skimming a bit
through mypaint-brush.c code in libmypaint, I am not sure at all we need
to use the offset_by_random like this. And really this shown outline
seems more indicative than anything else when I see the actual size
printed by the various brushes. Finally here it was counter-productive
as I needed to get easily the logarithmic radius from the pointer
interaction on canvas.
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...
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.
Shubham