🌞 GSoC OnCanvas Marker Editing Progress
🔹 Future TODO Tasks - Priority Based
- Marker Rotation
- Add marker buttons (3 for each marker pos.)
- Ctrl+z bug
- Y-axis preference option set - knots not in the right place
🔸 Week 8 (August1 - August 8)
- Implemented marker rotation functionality. Had some obstacles with cases where the rotation angle was not set to auto - but I was able to solve this issue with the help of my mentor. When the orient is set, the original auto rotation angle encoded in the edit_transform needed to be undone before any calculations are made in the shape-editor-knotholders.cpp.
- Moved the editMarkerMode button out of the toolbar and into the Fill & Stroke Dialogue.
- Implemented nonuniform marker scaling.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
- Inkscape Developer Meeting
🔸 Week 8 (July 25 - August 1)
- Fixed the math in the marker scaling functionality. Factors such as strokeScale, displayUnits, viewBox scaling, and viewBox scaled references were obfuscating what was happening on canvas and behind the scenes. Hence, I was blocked on this functionality for some time. However, I was finally able to fix it and have a good understanding of how all the different pieces fit together now!
- One thing I had to account for when scaling a marker object through its viewBox is that the reference point would be scaled as well. However, this behavior might not be intuitive to a user who is editing markers onCanvas, so while scaling the marker through its viewBox, its reference points also had to be adjusted accordingly to get the expected behavior.
- Spent some time working on the marker rotation functionality.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
- Inkscape Developer Meeting
🔸 Week 7 (July 15 - July 25)
- Got the refX/refY marker positioning functionality to work how I want it to. Originally I was accounting for the refX/refY in the get_marker_transform function by multiplying the transform by marker->c2p. I ended up removing it from here and accounted for this attribute in the shape-editor itself and that seemed to do the trick.
- Accounted for parent transform and display units size in the get_marker_transform function that fixed some previous bugs we discovered.
- Made a MarkerKnotHolderWrapper class to validate and initialize any missing marker attribtues before a user tried to start editing one. It will calculate the markerWidth/markerHeight and set the viewBox and refX/refY values to default values and the scale to a default of 1x.
- Split my original PR into two different PRs for marker mode 1 and marker mode 2.
- Ran into some difficulties testing this week because I would have random crashes, segmentation faults, and weird issues with the objects not updating when I edited them through the xml editor. Also had a ton of print error statements. However, fetching the latest code this week seemed to resolve most of these issues (:
- I think I'm 80% done with getting my scaling functionality how I want it to be; it seems to have some bug though after scaling it for the first time - need to investigate what's causing this.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
- Inkscape Developer Meeting
🔸 Week 6 (July 8 - July 15)
- Last week, updating shapes through the ShapeEditor was broken. Spent the majority of this week debugging and making fixes for this in the ShapeEditor which fixed editing for shapes like arcs, rectangles, stars, etc in marker edit mode 2. However, editing "paths" in marker mode 2 will not work since this logic also needs to be added to the PathManipulator/MultipathManipulator first. I originally thought the misplacement of the knotholders had to do with the edit_transform but seemed to actually be related to the displayUpdate logic.
- Worked on marker mode 1 and some related issues like calculating/setting markerWidth/markerHeight/viewBox for markers that don't have those values set - these are necessary for things like scaling.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
- Inkscape Developer Meeting
🔸 Week 5 (July 1 - July 8)
- Worked on getting the marker "orient" property set up in the ShapeEditor. Ran into some hiccups here because the marker orient property was being set in the marker representation but was not being updated on the screen. I didn't run into this problem for other marker properties I'd worked on like markerHeight/markerWidth/refX/etc. It turned out there was missing logic in the marker update logic after the marker-orient was changed. Once I tracked the problem area down - I implemented test code and figured out what I need to do to complete this marker orient logic in the ShapeEditor - this will be a todo next week.
- Made progress on the misplaced KnotHolder issues. I am now able to get the KnotHolders directly on top of the marker shapes. I spent time looking at how the marker positions were being calculated when rendered and used similar logic to calculate the KnotHolder edit_transform. To get this logic to work, I also had to change some of the logic around where edit_transform was being called in the ShapeEditor/Path-Manipulator/MultiPath-Manipulator; however, I had to temporarily break the marker-tool functionality here to get this up and working. I only updated the edit_transforms knot_get functions because I ran out of time this week. Need to fix the edit_transform logic in other places as well to get the marker-tool working as it used to - this is my next high priority for the coming week. I might need to do some regression testing here and make sure I'm not breaking anything else.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
🔸 Week 4 (June 24 - July 1)
- Added some placeholder functionality to toggle between the two marker editing modes (Shift + Z).
- Refactored my code and made it more "object-orienty". I realized some of the functionality I needed in the MarkerTool already existed in Inkscape and it was better to derive this functionality from other classes like the NodeTool rather than try to recreate/re-implement the logic again separately in the markerTool. This ended up solving a lot of the bugs I kept running into while I was testing.
- Set up the MarkerKnotHolder to handle scaling markerWidth/markerHeight - the math here needs to be adjusted.
- Played around with the selection functionality, this displays the dotted lines around the shapes/marker and also allows for the color of the marker to be changed - considering deselecting the marker parent shape and only having the marker items selected in the future, as opposed to now where the marker parent shape and the marker items are all selected.
- Looked at how the bbox was being calculated and set and updated this logic for SPMarker.
- Spent quite a bit of time looking into how to get the knots directly above the marker - I made some progress on this issue by scaling and translating the shape transforms using the parent shape stroke width. However, this logic fails when either the parents or shapes themselves have additional "transform" attributes on them. Need to continue looking into this next week - it is a high priority item.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
🔸 Week 3 (June 17 - June 24)
- Looked at how the Box3dKnotHolder, Rect3dKnotHolders, and other types of KnotHolders were being implemented in the shapeEditor. Decided to implement the "Option 1" Mode logic through the shapeEditor by loading in SPMarkers and creating new MarkerKnotHolders to handle operations like changing the native marker properties such as RefX/RefY/MarkerWidth/MarkerHeight/Orient.
- Implemented the logic to change a marker's refX/refY properties in "Option 1" mode.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
🔸 Week 2 (June 10 - June 17)
- Looked at how the MultiPathManipulator was being used in the node-tool.cpp and implemented the code to load paths into the MultiPathManipulator through the MarkerTool. This now allowed for paths under a marker object to also be editable through the MarkerTool.
- Discussed some options("Option 1" vs "Option 2" shown below) for OnCanvas marker editing functionality with the Inkscape team in the related UX issue: [inkscape/ux#34 (closed)]
- Currently, the ShapeEditor/MultiPathManipulator logic I previously implemented took care of a lot of the "Option 2" logic. However, after discussion with other Inkscape members, the consensus seemed to be that it would be cool to have both marker editing modes with the ability to switch between the two.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
🔸 Week 1 (June 3 - June 10)
- Spent time exploring how the ShapeEditor, MultiPathManipulator, and PathManipulator allowed shapes to be edited in real time after some advice/suggestions from other Inkscape devs. 💛
- Created a marker tool in the lefthand toolbar as a placeholder to enter marker mode (I plan to eventually move this next to the marker drop-downs in the fill & stroke dialogue).
- Looked at how the ShapeEditor was being used in places like the rect-tool.cpp and implemented the code to load shapes into the ShapeEditor through the MarkerTool. This now allowed for shapes such as rectangles, spirals, and ellipses under a marker object to be editable through the MarkerTool. However, shapes like paths were not editable through the markerTool yet because the logic for editing paths/nodes is handled through the MultiPathManipulator.
- Weekly meeting to discuss GSoC progress, todos, blockers, priorities, etc.
- GSoC Mentoring Meetup
🔸 Pre-GSoC
- Went through GTK/Inkscape documentation
- Explored the Inkscape codebase
- Brushed up on my C/C++ knowledge (bit rusty here)
- Met my GSoC mentor 💛
- Started trying out different ways to implement the OnCanvas marker editing. My first approach was to just bring in the marker reference as an actual shape/group into the document for editing and then remove it from the document and update the marker reference once the editing was complete. While this approach would potentially allow the user to do all types of editing on the marker object, real time editing was not possible and it was somewhat of a clunky approach. However, playing around with this idea introduced me to how SPObjects, SPItems, SPShapes, document representations, and selections worked and how they could be used in my project.
- (podarallarachana/inkscape_2@e69ccfa2)