Largely based on a patch by Ell, with the enum type renamed and
various small changes. Adds another axis of configurability to the
existing layer mode madness, and is WIP too.
The colon-separated list used in the plugin originally comes from
gimp_help_get_locales() anyway. My previous code was using different
lists of locales in different places, which was inconsistent.
I know this looks absolutely horrible, please spare me comments about
that. This commit has the purpose to let everybody experiment with the
new modes, and suggest improvements of the GimpLayerModeBox widget; we
need *some* way of controlling the new layer mode madness.
These variations on darken only and lighten only have the advantage over the
componentvise versions that they always use the full triplet of either original
or new layer - meaning no new colors/hues will be introduced. This is similar
to how these modes operated/operates in picture publisher and photo-paint.
- set the filter_tool->drawable before showing the tool gui.
- set the sensitivity functions for channel combobox of threshold,
levels and curves tools dialogs only once during dialog creations.
- use the filter_tool->drawable inside the sensitivity functions
C++ won't allow us to use GimpLayerMode in the API where we used to
have GimpLayerModeEffects.
Move GimpLayerModeEffects to libgimpbase/gimpcompatenums.h so it's
not in the API any longer, and instead typedef and define stuff in
libgimp/gimptypes.h, and adapt the compat enum registering code
accordingly.
The porting from 8bit per component scaled some 8bit fractions up to huge
floating point numbers, this works for most values but causes trouble for near
transparent pixel values. This commit copies the inner blend loop from the new
divide layer mode, but keeps the old compositing logic.
... is fully transparent, instead of just src.
The blend func results only affect the intersection of dest and src.
Run time is currently dominated by the compositing step for most modes,
so the difference in performance is pretty negligible, but it does make
a difference for the more expensive modes, like the HSV ones.
The print size displayed in image property and title format should use
gimp_unit_get_scaled_digits() instead of gimp_unit_get_digits() and
adding 1, which is quite random or magic number-y.
For operations needing to override default behavior sub-classes should still be
used.
This commit also enables pinligh, vividlight and linearlight blend mode modes
We can't just switch to a GimpOperationTool by using the normal
gimp_context_set_tool() or gimp_context_tool_changed() because it
needs additional initialization like setting an operation at all.
In gimp_gegl_procedure_execute_async(), g_object_set_data() the used
procedure on the newly created tool.
In gimp_display_shell_initialize_tool(), when we re-create the active
tool because of a drawable change, check for the procedure and invoke
it again, instead of simply creating an empty operation tool by
calling gimp_context_tool_changed().
Optionally convert all imported (not XCFs) images to 32 bit linear
floating point, and optionally add a little noise in order to
distribute the colors minimally. The new options are on a new "Image
Import & Export" prefs page that needs a new icon. Original dithering
patch by pippin.
Since CIE Lab is one of the supported color spaces for doing the blending -
this enum is not only about transfer functions/curves or gamma. This finishes
already started cleanups.
... in status bar.
Follow-up of commits f836892 and d1c3c3d. With high resolutions, the
distance displayed in the status bar when shift-clicking in a paint tool
may lack digit precision and show the same value (in non-pixel unit) for
several consecutive pixels. Compute a more accurate precision than what
gimp_unit_get_digits() can provide in such cases.
When working with high resolution, you may have cases where measured
length won't be displayed with enough digits; i.e. several pixels length
would show up as 0. For instance at 4000 PPI, up to 7 pixels show up as
0 mm, then at 0.1 mm from the 8th pixel (actually reaching over 0.05 mm,
approximating as 0.1), then 0.2 at 24 pixels (actually: 0.152), and so
on. At such a resolution, 3 digits are needed for 'mm' instead of the
1 digit returned by gimp_unit_get_digits() so that we display reliable
lengths.
Therefore we need to compute ideal digit precision. Configured digits
for a given unit will now be used as a minimum value, but actually used
digits may be higher.
Compute the ideal decimal precision for cursor position and length
status so that you get the best precision on physical units depending
on the current resolution, yet avoiding over-precision (which can be
misleading). The unit's "digits" value is now used as a minimum
precision only.
It is used both for blending and compositing, the repeated use of the word
BLEND in code made the logic involving both blending and compositing hard to
read.
Note that in some cases the alloca may be unnecessary, but this keeps
the code clean, and we have to be able to *potentially* do the alloca
anyway, so what the hell.
Implement a common utility function gimp_blend_composite that uses utility
functions for implementing layer modes, with separate (possibly SIMD) optimized
loops for blending and compositing, with configured linear TRC, perceptual
gamma TRC or even using CIE Lab as the space.
from gimp_applicator_new() and gimp_gegl_mode_node_set_mode().
Compositing doesn't depend on the layer format any longer, only on the
layer mode. Painting with "use applicator" unchecked is still broken
in some cases and needs more fixing.
like all other function typedefs and add GimpBlendFunc typedef which
will be needed soon. Also rename get_layer_mode_function() to
gimp_get_layer_mode_function().
...layer group cause a bug in the existing layer size
Change gimp_group_layer_get_size() to return FALSE if there are no
children (there is no content).
In gimp_group_layer_update_size(), skip children where get_size()
returns FALSE. Fixes bogus size calculation.
Temporarily slower - but permits paint modes like overlay/softlight to work at
all for linear TRC pixel encodings. Should be reverted when the non-graph
approach works properly again.
with proper value names. Mark most values as _BROKEN because they use
weird alpha compositing that has to die. Move GimpLayerModeEffects to
libgimpbase, deprecate it, and set it as compat enum for GimpLayerMode.
Add the GimpLayerModeEffects values as compat constants to script-fu
and pygimp.
Make overlay, Lch color, Lch hue, Lch saturation and Lch lightness mode handle
alpha more like how normal does it. This is a change that we ideally might want
applied to other layer modes as well to get rid of MIN() calls.
when parsing of an object property fails, we need to set *expected to
G_TOKEN_NONE to tell the config parser that something has gone wrong,
or it will continue parsing and run into trouble with the inconsistent
state (it will try to set an error over the already set error, causing
a warning).
The "accumulated" (color value) adjective does not look like the best
word in both descriptions. Respectively, the first is an averaged
value whereas the second would be a "merged" or "composited" value.
If native speakers have comments or better propositions, they are
welcome to speak up.
...regardless of image color precision
Split enum value GIMP_COLOR_FRAME_MODE_RGB into RGB_PERCENT and RGB_U8,
which display the current % values, and values in a range of 0..255.
Move the entire drawing control logic to gimp_color_tool_oper_update()
which gets invoked on hovering, and don't mess with it in
button_press() and button_release(). Tested to work with the color
picker, paint and filter tools.
Disable the new "automatic window tabbing" feature introduced on macOS
Sierra. It breaks GTK+ applications and we would need proper support for
this in GTK+ if we want to use it.
Change GimpHistogram to take a "gboolean linear" parameter and always
honor that parameter, so both kinds of histograms can now be created
for all drawables.
Add a horrible "Linear" toggle to the histogram dockable which always
defaults to the active layer's actual pixel format, but can be
switched at any time. This UI is ugly and needs to change.
On the PDB, default to gamma-corrected if the plug-in is unaware of
higher precision, and to the drawable's native pixel format otherwise.
Other places using histograms (e.g. levels, curves) are unchanged.
Set gimp_tool_control_set_preserve() to TRUE and set an appropriate
dirty_mask, just like all tools which have a permanent on-canvas state
outside of a simple press-drag-release.
The white, gray and dark sliders of GimpHandleBar have a black contour.
This makes the white and gray slider visible even with similar colored
background. On the other hand, the black slider is barely visible on a
dark background (and could even be made totally invisible using the same
color). So let's use a light-gray contour on the dark slider, making now
all sliders working with any background color.
gimp_dialog_config_fill,stroke_options_notify(): ignore notifications
on the fill and stroke option's parent class properties, they are not
serialized and completely irrelevent here.
This reverts commit eab4929a78.
Oups it would seem gtk_accel_map_change_entry() could return FALSE even
when the expected shortcut is correctly set (my guess is that it was
already the same shortcut, so indeed no "change" happened, though it is
not a failure either; yet I haven't checked if that is the actual
reason).
Let's just revert this. It's not always a good thing to be too thorough!
Sorry for this!
These are used for display switching, and even though you could
remap these shortcuts, it would work only until you close an image,
open a new one, or reorder tabs in SWM, in which case your shortcut
would end up forcefully overrided, which is a bad user experience.
If we want to give more flexibility and allow one to map these
shortcuts, we must also make sure the display showing actions won't
override customized shortcuts. In the meantime, it is better to
simply forbid these in our preferences.
... for "windows-display-*" actions.
I should not happen, but let's be thorough and properly handle failure
with a message since this is a runtime issue.
gtk_action_group_remove_action() removes the action from the group while
not actually cleaning any accelerator. This is a problem for transient
actions which have only a meaning within the current session, such as
the display switching actions named with the display ID (unique within
the session only).
Current commit, combined with the previous one (commit c0ee959), fix
"windows-display-*" actions being saved inside menurc.
Some actions are not meant to be saved, in particular the
"windows-display-*" which have only a meaning during a same session
since display IDs are session-dependent. So let display deletion
happen first so that proper cleaning of action is done when writing
menurc.
Revert "app: action search should search accross all available actions."
This reverts commit 53b3673bd8.
Had to revert these two commits, quoting comment 6 of the bug:
Thinking again, that entire change is unfortunately wrong, the only
right UI manager is in fact
gimp_ui_managers_from_name ("<Image>")->data
because it's the global popup <Image> UI manager which is independent
of a display and it always in the right state for the currently
active image, all other UI managers are wrong.
Current defaults are from another time. Acceptable defaults could be
common screen resolutions. 1366x768 is apparently the most common
(according to various stats on the web), but since we target advanced
graphics artists, let's go for 1920x1080, which is the second most
common resolution, also known as Full HD.
For unstable builds, let's have at least one odd number, uncommon ratio
and higher values, encouraging tests with less common numbers and bigger
images. I chose 2001x1984. Feel free to update to any other funky values
following these "unstable" rules.
... with something more suitable.
72 PPI is from a time where people thought this was a common screen
resolution. This is not the case nowadays, and anyway images targetted
for screen display should not bother with PPI resolution at all, only
with actual pixel dimensions.
PPI resolution is more useful for printing. And for this case, 300 is
quite an accepted OK value for most cases. So this is likely a better
default for GIMP.
Add GimpMenuFactory can always be found in a GimpDialogManager, use
gimp_dialog_factory_get_menu_factory() where we have a dialog factory
instead of accessing "global_menu_factory" or redundantly passing a
menu factory around where we already pass around a dialog factory.
<Dockable> has this whole list of actions named similarly to dialogs-*
actions, and we don't want these to take precedence, especially since
they would always create a new dock instead of just showing the existing
one if already present.
Also fix the redundancy check on already added actions.
There is no reasons not to translate the "occurs" text which will be
in the color names in palettes extracted from images. It indicates on
how many pixels a given extracted color was occuring. We should also
translate the full string (not just "occurs") since some language will
have to reorder words, and may even use different bracket characters.
So I also add a translator comment to make sure the translators get
what the %s and %d stand for in this string.
Duplicate accelerators are not supposed to happen. It is not possible
to set them through the GUI in particular. Nevertheless
gtk_accel_map_load() would apparently let duplicates pass, which could
happen after editing the menurc directly, or using the development
version (no action name migration happens there), or simply after a
potential bug. This is then very annoying because you may see several
actions displaying the same shortcut but only one actually work. And
trying to re-set through GUI the shortcut to the one action you wish to
run does not fix the duplicate issue (you have to laboriously find which
other action use the same accelerator and delete it first).
Better be safe than sorry and make a quick check at startup, then delete
the accelerator on one of the duplicates (you can't guess which one was
actually wanted, but at least you will facilitate manual reset through
the GUI).
Redundant accelerators were:
- <Primary><Shift>y on dialogs-mypaint-brushes and edit-strong-redo.
Since the <Primary>z vs <Primary>y has quite a strong history for
undo/redo actions, and dialogs-mypaint-brushes is quite new, let's
unmap the latest.
- <shift>l on tools-seamless-clone and tools-unified-transform.
Since the Seamless clone tool is still in the playground and we
don't even know if it will make it out quite soon, let's give
priority to the Unified Transform tool.
Limit selection shrinking to MIN (sel_width, sel_height) / 2, larger
values make no sense.
Limit selection bordering to the same value and growing to
MAX (image_width, image_height).
Introduce virtual function GimpViewable::is_name_editable() and class
member "gboolean name_editable" for the default value. Default to
FALSE and only return TRUE if the name can actually be edited by the
user.
When attemting an edit, check the new API and beep instead of starting
the edit.
Don't rely on the exact modifier being pressed or released. Instead,
check if only the right modifier is pressed after *each* modifier
change, and switch to color picking if it is; disable color picking
otherwise. This greatly reduces the risk of missing the user's wish to
pick colors because of other modifiers being pressed and released in
whatever order.
Probably fixes bug #734743.
We handle multi-selection by letting GtkTreeView handle button press
when the widget is in GTK_SELECTION_MULTIPLE mode. Change that code to
only do that when one of the participating modifiers (shift and
control on Linux and Windows, shift and cmd on macOS) is pressed.
This makes sure that the same thing is not randomly handled by two
different pieces of code, and probably fixes bug #738440, tho I can't
be sure.
When calculating an overlap between two ranges, interpolate the hue
adjustment from config->hue[primary_range] and
config->hue[secondary_range] BEFORE mapping it to the input value.
This fixes odd edge cases where only one of the ranges crosses the
red/magenta wraparound, or if adjustments to different channels yield
more than 180 degree difference from each other.
In the "New Image" and "Convert Precision" dialogs. The "Gamma/Linear"
switches get adjusted automatically to the new defaults, but can be
changed manually.
Don't offer dithering options when converting to 16 bit, it doesn't
make much sense to dither for anything but 8 bit. Thanks to Elle for
testing that this assumption is indeed true.
Use a properly commented #define instead of just a hardcoded "8 bits"
to make clear that this is a pure GUI "restriction".
Disable the convert precision dialog's dithering controls when
converting to higher bit depths o to anything > 16 bit.
Make sure the disabled dithering widgets always says "None", which
implies duplicating the bit depth checking logic in both the dialog
and its callback, in order to protect the values in GimpDialogConfig
from being overwritten by NONE.
The new properties are "virtual", they share their storage with the
"precision" property and are not serialized, they are meant for GUI
property widgets.
...instead of transforming it
Add gimp_matrix3_will_explode() which determines if a transform
matrix will blow up something in a rectangle to infinity, and use
the function so set both the GIMP and GEGL code paths to clip the
transform to the input size.
This got lost when dropping the file-uri plug-in and switching to
interal download using GIO. The file-uri plug-in would just download
whatever remote thing and open it locally, using local magic matching.
We now do the same internally and try the magic matching again on the
downloaded file.
Don't migrate any paths from an older gimprc. This unfortunately kills
all manually added paths, but makes sure all paths default to the
files of the new GIMP version, could be improved by parsing the path
and replacing only the right elements.
Add color management to GimpDrawableFilter and GimpFilterTool, GEGL
ops applied to drawables can be applied in color managed space
now. Sadly, this is very slow, so disabled by default.
I'm sure the profile guessing based on the operation's format doesn't
always work, but this general bug counts as fixed now.
Fix cursor rotation jump when tablet pen is tilted horizontally.
This changes to the correct values for the special case of tilt_x == 0.0.
Reviewer (Jehan)'s note: computing the convergence of the tilt function
in the `else` block, when tilt_x approaches 0, tilt value indeed
converges to 0.25 with tilt_y > 0 and 0.75 (or -0.25 which is the same)
with tilt_y < 0.
Initialization was failing when a paint buffer could not be returned for
a stroke (which was bound to happen in tiling). Instead it must just
ignore the coordinates which won't result in painting, and continue to
the next ones.
gimp_drawable_equalize(): is mask_only is FALSE, suspend the selection
around gimp_drawable_apply_operation() so the operation affects the
entire drawable.
The code was still checking for "plug-in-recent-*". Also, rename the
actions to "filters-recent-*" instead of "filter-recent-*" for
consistency with the other filters actions.
so the threshold can now be based on the GimpHistogramChannel enum.
Add a channel menu to the threshold dialog and a channel argument to
the PDB procedure (which is new in 2.10).
If I hadn't forgotten what the "RGB" channel is supposed to do I would
have implemented the RGB mode in GimpOperationThreshold correctly.
Right now I'm just guessing. Anyone?
They used to be 0..255, inherited from the old gimp_histogram() and
gimp_threshold() procedures. This commit deprecates these old
procedures and changes the ranges in the new gimp_drawable_histogram()
and gimp_drawable_threshold() to double with a 0.0..1.0 range.
Add property "color-tag" of type enum GimpColorTag to GimpItem so all
layers, channels and paths can be tagged with a color.
For interoperability, use the color list from Krita which is a
superset of Photoshop's colors.
Features a "Color Tag" submenu in the layers, channels and paths
menus, a row of color radio buttons in the properties dialogs,
undo and PDB API.
As a side effect, some common code is now factores out into
items-actions.[ch] and items-commands.[ch] which adds visible, linked
and lock actions for layers and channels.
Introduce item-options-dialog.[ch] which abstracts this away and use
it from the layer, channel, vectors options dialogs. This is all
pretty ugly but better than duplicating that code three times. The
vector-options-dialog is now completely pointless but I kept it anyway
for now, let's see what unique path options we come up with.
Convert GimpRGB to CMYK using a color transform to the configured CMYK
profile instead of the naive gimp_rgb_to_cmyk().
Add gimp_color_frame_set_color_config() and call it on all color
frames in the GUI (color picker tool, cursor info, sample point view).
Keep a GimpColorTransform around that does the conversion.
Also color manages the frame's color area now (visible in the sample
point view), which was forgotten earlier. Addresses bug #467930.
Fix the check that keeps events on overlay widgets from entering the
tool event mechanism, they have no business there.
gimp_overlay_child_realize(): set the embedding widget's event mask on
all overlay children, so their windows will be used as event window,
so their events become distinguishable from events on the parent (the
canvas).
gimp_display_shell_canvas_tool_events(): fix the check for events on
overlays, and skip them for real this time.
Call gimp_context_tool_preset_changed() on the global user context,
not on the tool preset list's or tool preset editor's local
context. Fixes restoring of presets in MWM. Tracked down by Jose
Americo Gobbo.
Have "Save" and "Restore" buttons in both the tool preset list/grid
and the tool preset editor. The save button stores the active tool's
options in the preset, if possible.
This fixes restoring of brush properties (size, spacing angle etc.)
from presets, which was utterly broken before. The fix consists of
two parts:
- In tool_manager_preset_changed(), always copy the brush properties
again after setting the preview on the tool options, in order to
override brush properites that get copied from a linked brush when
that brush gets set on the tool options.
But no amount of copying stuff again and again would help without:
- In gimp_context_set_by_type(), don't use g_object_set() to set the
object (brush, pattern etc.). Instead, build a GValue and call
gimp_context_set_property(). This may seem odd, but avoids a
g_object_freeze_notify()/thaw_notify() around the g_object_set(),
which was causing "notify" to be emitted at the very end, after
everything this context change has triggered. GimpContext is an
essential core object and there is an expectation of a reasonable
order of signal emissions and callbacks being called. The "notify"
at the end was keeping any callbacks of the context's "foo-changed"
signals to override anything an earlier callback had done, if a
"notify" callback was overriding that overriding again.
This was probably the reason for a lot of odd behavior observed over
the years. In fact, I have been searching for this for at least 5
years.
...are not submitted to respective Tool Options sliders
Treat brush angle and aspect ratio like all other paint options values
that can be linked to brush defaults and take their default values
from the brush. They were special casing their defaults to constants,
and GimpBrushGenerated was adding the passed dynamic radius and aspect
values to its own. This was totally incomprehensible.
Now GimpBrushGenerated's transform_size() and transform_mask()
implementations just translate between these APIs value ranges and the
brush's own value range and only use the passed values (not the
brush's native values), which makes the editor <-> tool options
interaction and the painted brush shape predictable.
Also connect the active brush's property notifications to the paint
options properties, so the paint options follow a brush edit live if
the respective "linked" toggles are checked.
And some cleanup.
Add a GimpFillType argument to GimpItem::resize() and fill type
widgets to the canvas and layer resize dialogs. Fill the new parts of
the drawable according to fill type in gimp_drawable_resize(). Make
sure places that need the old behavior get GIMP_FILL_TRANSPARENT
passed by hardcoding it in the GimpItem::resize() implemetations of
channel, mask, selection etc.
We didn't convert patterns to the target drawable's profile when using
gimp_drawable_fill().
Introduce gimp_drawable_fill_buffer() as single filling utility
function that does things right and use it from gimp_drawable_fill()
and gimp_fill_options_create_buffer().
Use a GimpSpinScale in channel-options-dialog.c and clean up the
dialog layout. Affects the "Quick Mask Attributes", "New Channel" and
"Channel Attributes" dialogs.
Add new setting GimpGuiConfig:devices-share-tool. When TRUE, we never
copy any properties between the user context and the GimpDeviceInfo's
context, so no tool or anything changes.
We do however still keep track of the active device so the setting can
be enabled/disabled at any time. Also hide GimpDeviceStatus' tool,
brush etc. indicators in "shared" mode.
Otherwise the quit dialog is still in front yet it has no focus and
one doesn't see this immediately.
Hitting ctrl-d to exit and ignore any subsequent files for instance
duplicates the current active image instead.
making its external API "complete". Remove the redundant
"new_base_type" and "new_precision" from the internal (vfunc) API (the
Babl format has the same information).
Michael Natterer