WIP: Eraser implementation #7
No reviewers
Labels
No Milestone
No Assignees
2 Participants
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: enrico/stiletto#7
Loading…
Reference in New Issue
No description provided.
Delete Branch "eraserhead"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
On this branch there is a naive implementation of an eraser for erasing parts of the stroke.
I think that at this stage the important thing to get right is the architecture of the various tools that can be used to interact with the canvas: I tried and made a small first step in this direction, but the result seems unsatisfactory.
Important thing to do: Use a better User Interface that makes it clear which drawing tool is active
This is clearly an important architectural piece, some work is needed, but we're heading in the right direction
@ -40,0 +51,4 @@|| rect.contains(cubic.p1)|| rect.contains(cubic.p2),}}I'm not sure about this code: if a line intersects a Rect, but the line start and end are outside of the rect, will this return true?
@ -43,0 +74,4 @@CanvasElement::Freehand{path, thickness: _} => {// Remove segments intersecting the eraserlet new_segments = (*path).kurbo_path.segments().filter(|path| ! segment_intersects_rect(path, eraser_rect));path.kurbo_path = druid::kurbo::BezPath::from_path_segments(new_segments);I think we should split the various parts in more Canvas::Freehand parts. This way, when we implement selection etc, we can identify paths with a single connected stroke
@ -43,0 +81,4 @@}}pub fn push_back(&mut self, element: CanvasElement) {Maybe "add_element"?
@ -24,0 +24,4 @@// Tools that can be used to interact with the canvas#[derive(Clone, Data)]enum CanvasTool {Pen { current_element: Option<CanvasElement> },I'm not sure that current_element should be associated with the Pen; a Pen should have thickness and color informations only
When does
the current path being drawnmake sense?I felt a little uncomfortable keeping this in CanvasData, because there is no current path being drawn when we erase. Probably with the state machine we can achieve a cleaner vision, though.
It still fits the CanvasData, because it is a piece of data associated to the Canvas (indeed, the currently drawn item). When there is no currently drawn item, is set to None; for the time being, current_element != None is the result of is_drawing()
@ -25,3 +41,2 @@struct CanvasData {current_element: Option<CanvasElement>,//elements: Vector<CanvasElement>,current_tool: CanvasTool,Nice
@ -113,0 +183,4 @@}_ => {// we just changed the canvas tool, there is no need to repaintreturn;I feel like we should use a state machine to identify the state the app or the canvas is in; maybe this would simplify this logic, or at least make it more explicit
@ -144,3 +216,3 @@ctx.fill(rect, &Color::WHITE);for element in data.elements.get().iter() {for element in data.elements.get().elements.iter() {lol the name choices are unfortunate
I think this is fine for now
Small brain dump:
2 has been taken care of
In the algorithms that implement strokes erasing, I create a new im::Vector each time, so it's a little bit expensive, it should be fixed.
Also, we must take care of the matter of finding a way to determine (cheaply) whether two Canvas versions are actually different or not: For now I'm using a version_id that gets incremented each time an actual edit (i.e. moving the eraser without touching any stroke is not an actual edit) is performed.
After thinking a bit more about the statefulness of tools, I think we should implement the two following tools as a test:
After more experimentation, I think we should give even more effort to this feature.
In the final application the user would have a palette of costumizable tools, e.g.: one black pen, one red pen, etc. So some tools would be fixed (like the eraser), while others would be dynamically created.
This means that our Widget data contains something along the line of
Vec<CanvasTool>.Step 1:
From your project repository, check out a new branch and test the changes.Step 2:
Merge the changes and update on Gitea.