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.
Michael Natterer