You could load in a DXF and render the entire thing as trackers. In the end, it's nothing different than what's being done to render the document objects in the Scenegraph. However, I think it becomes more difficult to manage that well without using a "task" as a context to mange their creation / destruction... Hard to say without a concrete use case.carlopav wrote: ↑Wed Nov 27, 2019 12:01 am Thx Joel, this I did get it. I mean, could we have a document object that stores geometry like a whole dxf, but represent it through pivy trackers constantly? Or just represent it as a compound but turn it into pivy trackers when we need to edit it? And how difficult do you envision to use draft tools on it? And draft snap?
It's not to stalk you, I'm really curious to understand how do you envision it
As far as using draft tools on trackers, pivy-trackers could be used *by* the draft tools, I suppose... and maybe you could use an existing draft tool on a tracker object, but I didn't really design it with that sort of thing in mind - the tracker object doesn't have a document object API for that level of compatibilty. I suppose a shim / wrapper class could be added, though...? Again, without a concrete use case to really look at, it's hard to say.
Really, I think in the end, you'd be talking about rebasing the Draft tools to use trackers whenever geometry is modified, then update the document geometry when the operation is complete.
So, I really think I'd view pivy_trackers more as an editing tool that's generated on-demand and not constantly. Thus, the current workflow for trackers is:
1. Select existing document object(s)
2. Click / execute a command to run a task which modifies / edits the objects
3. Initialize the task by converting the document objects to pivy trackers or creating a framework of trackers to represent the editing operations
4. Perform the editing task operations using tracker objects
5. Complete task and use the final state of the trackers to update the original document objects (or abort, destroying the trackers)
Let's say we wanted to create an adhoc rotation tool that lets the user rotate all selected lines about the center of the selection by clicking and dragging the middle mouse button (no task panel is needed). The command-task paradigm is simple: The command is a middle mousebutton click and drag when multiple 2D objects are selected. The task is the rotation of those objects.
In this case, the selected elements could be converted into a custom tracker built on pivy_trackers. This single tracker would handle their rotation for the duration of the MMB click / drag operation. It may be advantageous to hide the original document objects during the rotation. Once the user completes the rotation, the transformation would be applied to the original document geometry. Then the geometry is turned back on, reflecting the permanent change. Finally, the trackers used for the rotation operation are destroyed.
I don't know if that makes it any clearer, or if what I'm describing is useful here. It seems, though, that this is really the only way to address performance issues with document objects without rewriting things in C++.
I think would be an interesting discussion if/how to integrate pivy trackers in draft since a major reorganization of its code could be on the horizon.
