Previously we only had `Point::end_point_for_square_aspect_ratio`,
which was convenient for PixelPaint but assumed the aspect ratio
was always fixed at 1. This patch replaces it with a new mthod that
takes in an arbitrary aspect ratio and computes the end point based
off that.
There's some explicit casting going on in `Point.cpp` to ensure that
the types line up, since we're templating Point based on `T`.`
The previous implementation of automatic scrolling in LayerListWidget
relied on mousemove events to perform the scrolling, which didn't
produce the expected behavior. Instead use the new auto scroll timer.
Without this check we would do an unnecessary partial second round
trip because of the call chain:
LayerListWidget::set_selected_layer() ->
LayerListWidget::on_layer_select() ->
ImageEditor::set_active_layer() ->
ImageEditor::on_active_layer_change() ->
LayerListWidget::set_selected_layer()
This just provides some nice visual feedback when you are in the
middle of selecting a color. An eyedropper might not be the ideal
choice here, but among the cursors we already have it is the
best one.
This just allows us to ask the image editor to update the tool's
current cursor. This is useful in cases where a tool may want to
change it's cursor for some operation, and wants to invalidate the
active cursor cached in the ImageEditor.
Now we add a little marker to show the current sample position of
the CloneTool. The current implementation for updating the cursor
location is really dumb since it just updates the whole editor,
but that's a yak on the stack to fix.
There's still a lot to be desired in terms of functionality and
usability, but this is a start. When using the clone tool, you
can press Alt to sample a location, and then the brush will clone
the color from there.
The problem was a bit more complex than originally anticipated,
and the root of the problem is that the "coordinates" of a pixel
are actually the top left of the pixel, and when we're really
zoomed in, the difference in editor coordinates of the top-left
and the center of the pixel is significant.
So, we need to offset the "start" point when we are painting on
the editor to account for this, based on the current scale. This
patch adds a `editor_stroke_position` in `Tool` which can be used
to compute what point (in editor coords) we should use for a given
pixel and it's corresponding stroke thickness.
Note that this doesn't really work well with the ellipse, since that
is drawn with a different mechanism. Using this new method with the
`EllipseTool` seems to give the same (or slightly worse) results, so
I have not changed anything there for now.
Previously, Any potential ImageClients would not have received an
update about the layer bitmap having been modified. This is similar
to what the other shape tools do upon completion.
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.
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.
