Return FALSE from gimp_display_shell_has_filter() when there are
filters, but they're all disabled, to avoid unnecessary extra
color conversions during rendering.
The labels used in the old display filters ui were more descriptive
than the corresponding property nicks; modify the nicks/blurbs with
similar text.
... Plus random cleanup in clip-warning.
... leading to a crash
Add gimp_data_is_copyable() and gimp_data_is_dulicatable().
Use gimp_data_is_duplicatable() when setting the sensitivity of the
various "foo-duplicate" actions, instead of inspecting the object's
GimpDataClass::duplicate pointer directly, since this is no longer
an indication of whether a GimpData object is duplicatable or not
(since commit 33de4d5530).
When copying a generated brush, copy its "spacing" property, in
addition to the other properties, which hasn't been previously
copied by ::duplicate().
Finish up commit 17583ff04a, which
ported GimpGradient from ::duplicate() to ::copy(), by doing the
same for the rest of the GimpData subclasses that implement
::duplicate().
We still keep GimpData's ::duplicate() virtual function around,
even though it now points to the default implementation (which uses
::copy()) for all subclasses, since ::copy() is stronger than
::duplicate(), and we might want to have certain GimpData types
that are duplicatable, but not copyable.
When we have display filters, break the color profile transform in
two: first, convert from the image profile to sRGB, then apply the
filters, then convert from sRGB to the monitor profile.
When a display filter's configure() function returns NULL, use a
propgui for the filter, instead of not showing a widget at all, to
spare filters the need to manually construct a configuration gui.
When processing display filters, shift the filter buffer to the
top-left corner of the render area, and pass the actual render
area, instead of an area whose top-left coords are (0, 0), to the
display filter. This allows for position-dependent display
filters.
When applying a relative adjustment to a spin scale, don't wrap the
pointer around the corresponding screen edge if the spin scale's
value is already minimal/maximal.
While applying a relative spin scale adjusment (i.e., when dragging
from the lower half of the spin scale), wrap the pointer around the
screen edges (of the current monitor), so that the maximal possible
adjustment amount isn't artifically limited by the screen geometry.
This is especially useful for spin scales in dockables, since
dockables are normally placed near the edge of the screen.
When the mouse is released, move the pointer back to its initial
position (at the beginning of the drag), to allow for subsequent
adjustments.
Unfortunately, moving the pointer programatically isn't supported
on all envrionments (Wayland, Xephyr, ...), and worse yet,
detecting that the pointer failed to move is tricky, so we have to
resort to an ungly hack to maintain the current behavior in this
case. Gah :P
In GimpPickButton, try to pick from the local window under the
cursor, before falling back to picking from the root window, so
that we can at least pick from local windows on Wayland.
Small fix to last commit: make the name entry editable when the
data is renamable, even if it's not otherwise writable (completely
hypothetical for now.)
Make internal data objects non-renamable, even if they're writable,
through gimp_data_is_name_editable(). Currently, the only such
object is the custom gradient.
Prevent changing the name of non-renamable data by making the name
entry of GimpDataEditor non-editable whenever
gimp_viewable_is_name_editable() is FALSE, even if the data is
otherwise editable.
Prevent the vairous PDB -rename() functions from renaming non-
renamable data, by adding a GimpPDBDataAccess flags type,
specifying the desired access mode for the data -- any combination
of READ, WRITE, and RENAME -- and replacing the 'writable'
parameter of the gimp_pdb_get_foo() functions with an 'access'
parameter. Change the various .pdb files to use READ where they'd
used FALSE, and WRITE where they'd used TRUE; use RENAME, isntead
of WRITE, in the -rename() functions.
Keep track of the selected viewable of a GimpContainerEntry, and
update the entry text when the viewable's name changes, if the text
hasn't changed since the viewable was selected.
... interfere with GIMP UI events
Add a GTK+ patch to ignore top-level transparent windows when
looking for the top-level GDK window at a certain pointer location,
in the Win32 GDK backend.
to gimp_base_compat_enums_init() and move its prototype from
gimputils.h to gimpbase-private.h; it's not supposed to be
public API even though it's callable from the outside.
Change gimp_tool_set_active_modifier_state() to honor the new
GimpToolControlSetting. Explicitly set the mode to SEPARATE in
all tools that require modifier keys during a stroke.
And here comes the actual fix: change GimpTransformTool and
GimpToolTransformGrid to use SAME mode, and remove their
active_modifer_key() and hover_modifier() impls, so it makes no
difference whether a modifier is pressed before of after mouse button
press/release.
Add new enum GimpToolActiveModifiers { OFF, SAME, SEPARATE } and
new API gimp_tool_control_set,get_active_modifiers(), the default
value is OFF.
OFF: the tool gets no modifier keys at all during a stroke
SAME: all modifiers are always delivered via GimpTool::modifier_key(),
and no magic is applied whatsoever when a mouse button is pressed or
released.
SEPARATE: this is the "classic" way: modifiers while hovering and
while stroking are delivered separately, and hover modifiers don't
affect stroke modifiers.
(AKA Issue with grain merge layer mode)
Fall back to using the legacy grain-extract/merge modes when the
input image precision is integer, and only use the non-legacy modes
when the precision is floating point. The midpoint intensity value
of the non-legacy modes is 0.5, which isn't representable exactly
using integer precision, causing small deviations between the input
image and the reconstructed image.
Add a framework for saving and restoring internal data objects, in
gimp-internal-data.c. Internal data objects are saved in separate
files under a new "internal-data" subdirectory of the user's gimp
directory. The internal data is saved, restored, and cleared
together with the tool options.
Use this to save and restore the custom gradient. In the future,
we might add similar writable internal data objects that we'd want
to save.
Currently, the error console is highlighted (shown/blinked) only
upon errors; however, warnings, which are not shown on the
statusbar while the error console is open, often also contain
important information.
Allow the user to configure which message types (errors, warnings,
and regular messages) highlight the error console, using a new
"highlight" submenu in the error-console menu. Add corresponding
config options, saved in sessionrc. By default, highlight the
error console unpon both errors and warnings.
gimp_dockable_blink() is used to attract the user's attention to a
specific dockable. Generalize this to arbitrary widgets, by
replacing gimp_dockable_blink[_cancel]() with
gimp_widget_blink[_cancel](), in gimpwidgets-utils.c.
The GTK+ implementation of gtk_drag_higlight(), used by
gimp_highlight_widget(), paints a black box around the widget,
which is not very noticable when using a dark theme. Copy the GTK+
code (which is simple enough) over to gimpwidgets-utils.c, and use
the widget's text color for the box instead.
A malicious XMC file can contain an invalid TOC count, which could lead
to an out of boundary write on 32 bit systems due to integer overflow.
This error occurs during thumbnail creation.
Signed-off-by: Tobias Stoeckmann <tobias@stoeckmann.org>
Piotr Drąg