Previously, we didn't ask the editor to update after drawing a
Rectangle/Line. This meant that if any part of your shape went
outside the bounds of the image, that part would not be cleared out
until the next update of the editor.
When drawing a line/rectangle/ellipse in `Tool::on_second_paint()`,
if `m_thickness * m_editor->scale()` was less than one, it would
get converted to 0 because of truncation. This was causing infinite
loops somewhere in the painter code and causing the application to
freeze.
Fixes#9986.
You could draw a Rectangle/Ellipse from the center by pressing down
the Alt key, but this was missing for lines. This commit adds it in
to keep consistency among the different shapes.
A few of the menu items were missing shortcut characters completely,
so in the interest of keyboard navigation some have been added (even
if they are not ideal).
In a few menus, severals actions had the same menu shortcut, so the
later ones were not accessible through it. These have also been
differentiated.
Previously the code assumed that the active tool had a reference to
the old editor, which is the only way we had to check if it is
active without having a reference to the editor. However, when a
tab in PixelPaint is closed, the editor is destroyed, so the `WeakPtr`
in a tool referencing the old editor is no longer valid.
This made it so that if you closed a tab, the tool would appear to be
selected in the ToolBox, but the editor would not know about it at all.
Since there's only one global toolbox, it makes sense to store the
active tool in here, since we don't really have control over the
deletion of an editor.
Previously applying filters was not calling this method, which was
not correctly triggering the `image_did_modify_bitmap` call for
the `ImageClient`s. This patch makes the filter actions call this
method.
It seems that just opening one of the Window menus triggers a repaint
of the entire editor, which is what was causing filters to update
earlier, since we were only accessing them from the menu. Using
the keyboard shortcut added in a previous commit highlighted this issue.
As pointed out by Andreas, drawing them from the bottom feels odd
since no other list in the UI is bottom-justified. The commit draws
the layers from the top of the list again.
Across the entire audio system, audio now works in 0-1 terms instead of
0-100 as before. Therefore, volume is now a double instead of an int.
The master volume of the AudioServer changes smoothly through a
FadingProperty, preventing clicks. Finally, volume computations are done
with logarithmic scaling, which is more natural for the human ear.
Note that this could be 4-5 different commits, but as they change each
other's code all the time, it makes no sense to split them up.
In a previous commit we read default values from a commit file, this
commit now also writes back any changes to those settings made by
the user. Persistent settings always feel good :^)
Someone may not want to have these things enabled by default on every
startup, but toggle them on manually. So instead of having hard-coded
everything to be enabled by default, we now query LibConfig to find
out what the preference is. These values can still always be changed
from the Menus / with shortcuts.
It's not really ideal querying LibConfig twice, but when initializing
the menu we may not have an active editor, so we need to get the
value for both the menu checkbox as well as the internal property.
This shouldn't be too much of a big deal since LibConfig caches the
values anyway :^)
The MoveTool now lets you pan if you're dragging with a right click.
Previously, right-clicking did not perform any actions at all, so this
isn't removing any old functionality.
Prior to this change, the 'Save' action was saving a file to the startup
path (or just showed a File Picker dialog) if a file has been opened
by the Open action or by drag-n-dropping a file to the program.
Prior this change, when you opened a file using the brand new Open
action and tried to change the Color Role or save it, then it would just
go back to the startup palette.
Because of the way rulers are implemented in the ImageEditor
currently, the `Fit Image To View` action doesn't work correctly
with them enabled. This patch makes them adjust to the effective
viewport area and account for the rulers.
This is a bit of a hack, but the correct way to deal with this would
be to put the rulers in a new widget so they don't interfere with
the actual viewport rect (which is being used all over).
After transitioning to FileSystemAccessServer, some of the methods
in `MainWidget` and `ProjectLoader` for opening files directly with
a filename as opposed to with a file descriptor are unused. This
commit removes them.
Use the newly added API in FileSystemAccessServer to get read-only
access to a file specified on the commandline. We no longer need to
unveil any image / .pp files on the filesystem :^)
Depending on the size / scaling of the UI, someone might want to
change what the threshold is to show the pixel grid. For instance
if you are working on a 50x50 image, and want to see the grid while
still fitting the whole image in the editor.
Since there's no UI for settings in PixelPaint right now, this
commit just uses LibConfig to read the following entry:
("PixelPaint", "PixelGrid", "Threshold")
which is then used when drawing the grid.
This removes the awkward String::replace API which was the only String
API which mutated the String and replaces it with a new immutable
version that returns a new String with the replacements applied. This
also fixes a couple of UAFs that were caused by the use of this API.
As an optimization an equivalent StringView::replace API was also added
to remove an unnecessary String allocations in the format of:
`String { view }.replace(...);`
In many cases we can lean on the name of a menu to reduce verbosity.
"View"->"Visualize/Show/Turn on/etc" is a bit redundant and clutters
the menu. It's a little thing, but it makes the system feel more
tightly integrated if we stick to the same word patterns across apps.
The editor now draws a grid showing the pixels if you are zoomed
in enough. Currently the threshold is a scale of 15 (so if one
pixel side on the image takes up > 15 pixels in the editor)
Previously we unveiled the file specified through the command-line
interface. Now, we just make the request through the
FileSystemAccessServer instead.
Previously we unveiled the file specified through the command-line
interface. Now, we just make the request through the
FileSystemAccessServer instead.
This check was fine earlier when we had access to the full filesystem,
but now that we are moving away from applications having unveiled
access to the filesystem, this check would just get rejected from
the kernel. This is rare / fast enough that performance should not
really matter in any case.
