gimp_suggest_modifiers(): change "shift_format" and "control_format"
parameters to "extend_selection_format" and "toggle_behavior_format",
which fixes the longstanding problem that the function did the right
thing only by accident.
tools: use gimp_get_extend_selection_mask() instead of GDK_SHIFT_MASK
which is not 100% semantically correct in all cases, but at least a
step in the right direction to make the tool modifiers easier to
improve.
Add new XCF property FLOAT_OPACITY and always save both the old 8-bit
and the new float opacity of layers and channels. Float opacity is
saved after the 8-bit one so when loading, it overwrites the limited
8-bit value with the proper precision. Do not increase the XCF version
number because old GIMP versions will simply skip the unknown
FLOAT_OPACITY and keep using the 8-bit value.
This (doesn't quite) fix an obscure part of the tool preset bugs: when
changing the brush on a GimpPaintOptions instance, we might or might
not change the brush size, aspect etc. to the set brush's native
values, possibly overwriting the intended values from a tool preset.
Implement GimpConfig::copy() and copy the affected values again after
the entire object has been copied, so we actually use the value of
gimp_config_copy()'s "source" object.
This would fix that particular tool preset problem if there wasn't
another bug that is still unfixed, stay tuned...
In order to make things more obvious here. Before, a tool preset could
only be rstored from the list by selecting it, which only worked if
another preset was active before. Now the selected preset can easily
be restored again.
Switch the axes of the GimpColorSelect color area so that on the X
axis, we always modify the first of the two channels of RGB or HSV
that are edited here, and on the Y axis the second.
This reverts commit 2cef834198.
This feature is "undiscoverable" according to Mitch, and we are not sure
how much the endpoint colors are special to the user.
This reverts commit 15b5b2c8b3.
This feature is "undiscoverable" according to Mitch, and we are not sure
how much the endpoint colors are special to the user.
Must not call the deprecated gimp_drawable_preview_get_drawable() on a
preview that was not also created using the deprecated
gimp_drawable_preview_new(). Instead, pass the GimpDrawable to
preview_update() using the signal's user_data.
Change the logic in gimp_metadata_get_colorspace() to be like in the
respective KExiv2 function, which looks pretty well done. No guarantee
of correctness, this just looks more logical than before :)
The common code relies on X11 pointer grabbing semantics, which does
not work well on OS X. An attempt using event taps also proved
problematic, in particular with regard to setting the mouse cursor.
This patch implements a fully separate code for use on OS X platforms.
It works by simply overlaying the desktop with big transparent windows
on which the mouse cursor is set and motion events are captured. Evil,
but it works.
Some refactoring: add gimp_metadata_get,set_colorspace() and a new
enum GimpMetadataColorspace which so far can be one of { UNSPECIFIED,
UNCALIBRATED, SRGB, ADOBERGB }. The setter is untested and I don't
know if it's doing the right thing, please review. Use the getter in
gimp_image_metadata_load_finish(), so complex metadata logic and
profile creation/setting are separated.
Now the history of recently used colors is not updated when selecting
in the color dialog anymore, but when a color is actually used.
Tools supported right now are: Ink, MyPaint brush, all PaintBrush tools,
bucket fill and eraser (background color on non-alpha drawables).
Moreover from now on, colors already saved are properly moved to first
position when reused.