This is a static helper function for asking the user what they want to
do about unsaved changes. It behaves as a standard Yes/No/Cancel box
with text and buttons tailored to the typical unsaved changes use case.
A bloom filter creates fringes around bright areas in the image
mimicking the behavior of real-world cameras.
It gets its own category "Artistic" in the Filter Gallery since its not
one filter per se but a combination of multiple.
The filter works as follows:
- Get only the light areas (above a threshold) of the image
- Blur that image
- Compose onto the original image
With this BitmapMixer one can draw one Bitmap onto another with
different modes.
For now the only supported mixing methods implemented are Add and
Lightest (which is very naive).
The FastBoxBlurFilter has been living in LibGfx for a while and now
it's accessible in PixelPaint. The parameters for the filter are exposed
via the new Filter Gallery.
1268b39ba introduced template specialization when reading/writing
to/from the bitmap that increased the speed of the filter.
To keep that while supporting more than one BitmapFormat, the
appropriate {get,set}_pixel<>() functions are detemined and stored in
Function<>s.
The wrong conception that done() would stop the program flow right there
lead to the lambda not properly aborting when no filter was selected.
The ExecAborted would be processed and then the nullptr that was
m_selected_filter would be happily dereferenced.
This patch fixes that.
Now, the filters can supply the Filter Gallery with a GUI::Widget such
that the user can interact with the filter. The Filter Gallery in turn
only calls apply() on the filter once it should be run.
This decouples the PixelPaint filters a lot from the ones supported by
LibGfx and paves the way to filters with settings.
For now there still are just the plain LibGfx filters so this change
feels like introducing a lot of boilerplate, but in the future there
will be a lot more to see.
As noted in the prototype comments, this implementation becomes less
accurate as the precision approaches the limit of 100. For example:
(3).toPrecision(100)
Should result in "3." followed by 99 "0"s. However, due to the loss of
accuracy in the floating point computations, we currently result in
"2.9999999...".
There's only two places where we're using the C99 feature of array
designated initalizers. This feature seemingly wasn't included with
C++20 designated initalizers for classes and structs. The only two
places we were using this feature are suitably old and isolated that
it makes sense to just suppress the warning at the usage sites while
discouraging future array designated intializers in new code.
Enable the warning project-wide. It catches when a non-virtual method
creates an overload set with a virtual method. This might cause
surprising overload resolution depending on how the method is invoked.
Before this patch, `which ""` or `type ""` would say that the empty
string is `/usr/local/bin/`.
Convert callers to consistently call is_empty() on the returned string
while we're at it, to support eventually removing the is_null() String
state in the future.
