During constrained motion, round the slider value before clamping
it, so that the slider limits are always enforced. Additionally,
snap the slider to 1/12-ths of the line length, rather than
1/24-ths.
Make sure that sliders can never have negative-zero values, which
can result in a -inf base for spiral.
Shift-click should actually toggle only within a given group. The new
capability of toggling only a sub-item, brought by commit 970e9ac is
still feasible in 2 steps: first toggling the parent (item group), then
the desired child.
It brings now a third possibility with exclusive toggle among many
children items, without touching other groups and top-level items.
... so that when the base and balance sliders overlap, the base
slider is the one that's picked, since the balance slider is
constrained by the base, but not the other way around.
Otherwise people will install older versions and won't understand why
the plug-ins won't work. It's just a little annoying that these version
strings have to be hardcoded this way. We could add macros in a header,
but that would be only half a solution. Ideally we'd rather have some
discovery logics at some point.
Hopefully it works, since that's untested (I have no MacOS access). This
is mostly code from file-darktable.c, made generic and factorized into
file-raw-utils.[ch]. At least it still builds and work fine on Linux.
I used the CFBundleIdentifier from `tools/osx/Info.plist.in` in
RawTherapee code. I didn't add a Win32 registry key base though, since I
couldn't find any relevant data for this in RawTherapee code.
When loading tiles from an XCF, reject tiles whose on-disk size is
greater than 1.5 times the size of an uncompressed tile -- a limit
that is already present for the last tile in the buffer. This
should allow for the possibility of negative compression, while
restricting placing a realistic limit.
Currently, no limit is placed on the on-disk tile data size. When
loading RLE- and zlib-compressed tiles, a buffer large enough to
hold the entire on-disk tile data, up to 2GB, is allocated on the
stack, and the data is read into it. If the file is smaller than
the reported tile data size, the area of the buffer past the end
of the file is not touched. This allows a malicious XCF to write
up to 2GB of arbitrary data, at an arbitrary offset, up to 2GB,
below the stack.
Note that a similar issue had existed for earlier versions of GIMP
(see commit d7a9e6079d), however,
since prior to 2.9 the tile data buffer was allocated on the heap,
the potential risk is far smaller.
...with known plugins
Add new plug-in file-raw-placeholder.c that registers itself for
loading all RAW formats from file-raw/file-formats.h, but does nothing
except returning an error message pointing to darktable and
RawTherapee.
When no real RAW loader is installed, this plug-in is selected
automatically as RAW loader, otherwise the first installed RAW loader
is used. Selecting another in prefs still works as before.
Pawan Chitrakar