Comprehensive rewrite of the DDS import routine, in the interest of
easier maintainability and readability. Adds formats.c/h, containing
tables and functions related to reading and parsing uncompressed files.
Importer now supports nearly all non-video uncompressed formats.
Includes a variety of minor-to-moderate fixes made along the way
which could not be pulled out into separate commits due to dependence
on other aspects of the rewrite.
Resolves#10454.
When porting to GimpProcedureConfig, all
light types were set to "Point" when 2 - 6
should have been "None" by default.
This patch fixes the defaults.
1. Recent changes to arg validation reveal bug in call to gimp-drawable-edit-gradient-fill,
supersampling arg must be >0
2. Make easier for testers to invoke by reducing the declared drawable capability
to SF-ONE-OR-MORE-DRAWABLE
Now use gimp-resource-delete
Drive-by fix of bad call to gimp-context-set-pattern.
Fixes other calls to gimp-font-delete, etc. in a test script.
Partly fixes 9867.
Due to a bug in commit de5c805cbb, which
changed the choice widget between line and paint tool to a
GtkStackSwitcher, changing that choice did not work anymore.
The reason being that the stroke method wasn't being updated on clicking
stroke. We fix this by setting the stroke method when OK is clicked.
When creating the dialog we also set the stroke method, to reflect the
last used choice, since that was also missing.
See discussion in !946: https://gitlab.gnome.org/GNOME/gimp/-/merge_requests/946#note_1768869
On Windows/macOS, the pad device is probably not even showing at all
right now, though I can't test. Also it could be eventually implemented
with pad actions support (see Luca Bacci comment in the same MR) using
WM_POINTER API on Windows.
On X11 though, the pad device is shown, except it is kind of pointless.
So I am disabling the frame (making it insensitive) and add a tooltip.
Handle some statefulness in actions taking a double parameter, in order
to make them friendly to GtkPadController and its pad ring/strip
integration.
The GtkPadController emits those actions with a double parameter
expressing the absolute value (e.g. 0-360 for rings, 0-1 for strips),
take care of converting these absolute values to relative changes
that increase/decrease the current GimpDoubleAction value.
Going for relative increments/decrements increases the genericity
of rings when mapped to actions, as going with the given absolute
values would mean means rings could be mainly mapped to angle-like
actions, reducing its usefulness.
We have everything in place to create GtkPadControllers converting
events into actions as configured in settings, and the signaling
to trigger the (re)generation of those as device, window or configuration
changes appear.
Only the last bit attaching those controllers to actually handle
input was missing, now done in this commit.
Since there may be multiple configured tablets and pads, we need to
keep track of per-device controllers to handle the configuration for
those. This mapping is kept in GimpImageWindow as the "main" toplevel
(i.e. the one(s) typically considered "keyboard focus" and receiving pad
events) and ensured to be kept up-to-date through the ::configure-pad
signal.
This API call will snapshot the current configuration of a device
into a GtkPadController, that is created and attached to a toplevel
(this event controller only acts on toplevels).
This controller will handle pad events, trigger actions, and update
compositor feedback (e.g. GNOME Shell pad OSD) as per the actions
mapped in the configuration dialog.
If a pad device configuration gets changed, or reset, we should trigger
the creation of new pad controllers for the existing toplevels.
Add the plumbing so that saving/resetting a device configuration will
result in the same ::configure-pad signal, and trigger it from the
relevant places.
In order to apply the pad configuration so it does something, we
need to create GtkPadController objects on each toplevel for each
configured pad device.
This signal will work as a hint that a new GtkPadController should
be generated for the given device and current configuration. At
the moment, emit it when pad devices are added or removed.
The UI is heavily inspired in the existing one for midi devices
and the such, as the restrictions are somewhat similar. Since there
is not enough information to introspect the device without the help
of libwacom (and the UI should work with tablets unsupported by
it, regardless) the list starts empty, and there exists a "grab
event" button to press pad buttons (or use rings/strips) and
create/focus a list item for the button/mode.
Double clicking on an action (or pressing the "edit" button) spawns
a different dialog with a GimpActionEditor to select an action.
And lastly, actions can be deleted with the "delete" button.
Pads may have different modes (e.g. leds in the tablet) that apply
to all pad features, the list will allow different actions to be
set on the same button in different modes. This basically multiplies
the amount of mappable actions by the number of available modes.
This object holds the mapping of pad device features (buttons/rings/strips)
to actions, given the current mode (e.g. leds in the device), and can be
serialized/deserialized from configuration files.
Fixing:
> Scalar value @inargs[...] better written as $inargs[...] at pdb/lib.pl line 247.
> Scalar value @outargs[...] better written as $outargs[...] at pdb/lib.pl line 386.
This continues the theme definition work from bd398d5c.
A new edge-border-color tag was created
to allow for defined widget edges in both
light and dark themes.
The box-shadow highlights for buttons
and header/menubars was defined to
reduce system theme leaks. Some CSS
attributes were rearranges as well.
Sabri Ünal