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.
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.
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.
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)
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.
Showing the position only with an active tool seems a bit confusing,
if you've opened up an image just to find out the coordinates of
a pixel for instance, there shouldn't be a need to have to select
a tool first.
Previously, we were ignoring the scale of the editor in the second
paint step. If you were zoomed in, the size while you were drawing
was not the same as the size of the final shape.
Previously, we were ignoring the scale of the editor in the second
paint step. If you were zoomed in, the size while you were drawing
was not the same as the size of the final shape.
Previously, we were ignoring the scale of the editor in the second
paint step. If you were zoomed in, the size while you were drawing
was not the same as the size of the final shape.
A previous commit I made broke layer dragging since the hole_index
was always being computed with respect to the top of the layer list
widget, however we were now drawing layers from the bottom. When
you didn't have enough layers to fill up the full height, dragging
them around would be weird.
This patch computes the hole index correctly using the same offset
we start drawing from, and fixes the behavior.
In addition to adding the action, this commit also makes the
`did_change_rect()` method take in an optional rect, which
represents the new rect position. By default it is the same as
`rect()`.
When we are cropping an image, we don't want to move the whole
cropped section to the top-left of the original image in the
ImageEditor widget, so this allows us to keep the cropped image's
position fixed.
We can now drag-and-drop files onto PixelPaint to be able to open
them. Each dropped file opens in a separate editor (which is the
default behavior of Photoshop).
Previously, all the UI setup was done in `main.cpp`, with a whole
bunch of lambdas,, and actions etc just being stored in the main
function. This is probably an artifact from back when it was first
created.
Most other applications now have a "MainWidget" class of some sort
which handles setting up all the UI/menubars, etc. More importantly,,
it also lets us handle application-wide events which we were
previously not able to do directly, since the main widget was just
a default GUI::Widget.
This patch moves all the core functionality of the PixelPaint
application into PixelPaint::MainWidget, which is then instantiated
by the main function. There is likely some more refactoring that
would help, but this commit is big enough as it is doing mostly
a direct port.
The fd would get closed when the File went out of scope, so we couldn't
open any file specified by 'pp <path to file>'. We need the fd to be
alive and we solemnly swear to take good care of it and close it
ourselves later.
Every tool that has a slider now registers the primary/secondary
sliders and now uses the same keyboard shortcuts to modify the
primary and secondary properties. `[` and `]` for the primary,
`{` and `}` for the secondary.
There are quite a few tools that might want to change certain values
based on consistent keyboard shortcuts. This commit allows tools to
hook up a "primary" and "secondary" slider with the base `Tool`
class, which can then handle updating those sliders with the common
shortcuts.
Note that any derived classes that want to override the `on_keydown`
function will manually need to call `Tool::on_keydown()`.
This new class will open and parse files (either images directly or .pp
project files) and one can get the parsed Image as well as other
information from it.
This patch removes a bunch of 'try_create_from..." methods from Image in
favor of using the ProjectLoader.
The only json_metadata that is available are Guides for now.
The ImageEditor knows more about the image than Image itself. So to save
a project with all the information known to the program about an image
it's logical that ImageEditor performs that task rather than the Image.
There isn't any additional data added yet, but now there's the
possibility to do so.
