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.
This is a feature I missed from Photoshop: it sets the scale and
position so that the image fits (it's longest dimension) into
the editor view. There's a 5% border left around the image to
provide context. This is just arbitrary seemed like the right
amount after some trial and error.
Previously EraseTool would only let you have hard lines, similar
to PenTool. After inheriting from BrushTool in previous commits,
making the eraser (optionally) behave like a brush is much easier.
We only need to change how the colors are handled for the hardness,
which is why the `draw_point()` call is a bit more involved. Just
blending the colors doesn't work here since we actually want to
replace the previous color, unlike in BrushTool where we are just
layering the color on top.
This removes all the code to handle events that was essentially
duplicated from BrushTool anyway :^)
I've also renamed "thickness"->"size" to have consistent
terminology.
Most of the logic implemented in PenTool was the same as BrushTool
anyway, with the only difference being how the actual lines were
drawn at the end. We now just override the `draw_line()` and
`draw_point()` methods instead.
We don't strictly need to override `draw_line()` here, but that
would just result in repeated calls to `draw_point()`, which is
wasteful.
Also renamed "thickness"->"size" to have consistent terminology.
The BrushTool is very cool, but it doesn't allow us to re-use any
of the code in other classes. Many of the other tools have duplicated
code for handling mouse events / keeping track of previous location,
etc.
This commit sets up BrushTool so that other tools can inherit from
it and override some virtual functions to allow similar behavior
without re-writing the code to keep track of mouse positions, etc.
In particular, we add public setters/getters for `size` and
`hardness` properties, and make `draw_point()` and `draw_line()`
virtual so that derived classes can override them.
Note: We still pass in `color` as a parameter for `draw_line()` and
`draw_point()` instead of using `color_for()` directly because it
doesn't really make sense to be constantly asking the ImageEditor
for the color when it's not really changing (for instance along all
the points of a line)
Sometimes you want to draw a straight line between 2 points, but
using the nice-looking brush we have instead of the hard line we
would get using the LineTool.
This patch adds the ability to click somewhere with the brush, and
then Shift+click somewhere else to draw a line between the two
points using the brush stroke. Seems like an obvious addition
considering we already have a helper function to draw lines :^)
The BFS implementation for BucketTool's flood-fill had sitations
which could result in infinite loop, causing OOM crashes due to
the queue growing unbounded. The way to fix this is to keep track
of the pixels we have already visited in the flood-fill algorithm
and ignore those if we ever encounter them again.
This also fixes the crashing issue from #9003. We still need a
better way to account for transparency, but that is beyond the scope
of this commit, and this issue still exists without any transparent
pixels.
This will restrict 3DFileViewer's access to the file system.
3DFileViewer loads a texture based on the path of the model loaded, this
will request access to the texture file before loading.
