pcb

Crosshair Rework

Registered by Chad Parker on 2017-11-05

The crosshair is the pair of orthogonal lines used to indicate the coordinates of the next action. It serves a number of purposes related to this primary function, e.g. the position of the crosshair is restricted to grid points, snapping to objects (pins, pads, ends of lines, etc.), and objects can be attached to it for moving or copying.

Presently, the code governing the crosshair is convoluted with many other functions in pcb. This blueprint seeks to coalesce the crosshair code into one location (crosshair.[c,h]), discuss how the crosshair should behave and interact with other elements of pcb, and ultimately revise the crosshair code to be more modular and flexible.

Blueprint information

Status:
Started
Approver:
Bert Timmerman
Priority:
Undefined
Drafter:
Chad Parker
Direction:
Approved
Assignee:
Chad Parker
Definition:
Approved
Series goal:
Accepted for trunk
Implementation:
Started
Milestone target:
milestone icon future-feature-release
Started by
Bert Timmerman on 2017-11-27

Related branches

Sprints

Whiteboard

There's a branch in the git repo home/cparker/crosshair_rework that is the first cut at doing some of these things. This branch wasn't particularly well planned out and is a hack. It was useful for sorting out how the crosshair works, how snapping works, and where all of the code is, but it's not ready for prime time.

Should snapping get its own blueprint?

Functions served by the crosshair:
* in the GUIs, indicate where the next click should take effect
** snapping is an important part of this. Often this is to grid points, but it can also be to pins or pads, the end points of other traces. Snapping could also be useful in scripts, so, it shouldn't be exclusively a function of the crosshair.
** the limits of the crosshair change when certain things happen in order to ensure consistency. For example, when a part is being moved, the limits of the crosshair are set so that part cannot be placed outside of the workspace (the "board").
* in the batch HID, remember the location of the last action. For example, scripts might execute a relative move of the crosshair in order to execute an action at a location relative to the previous action.
** If pcb had a better scripting language, then this might not need to be the case. Presently, there are no variables, conditionals, etc. in pcb scripting. Since changing this is a major thing, for the moment, the crosshair needs to retain this function.

Some goals for the revising the crosshair code include:
* define an interface for interacting with the crosshair
** a direct interface that code can use to manipulate it
** an action based interface that can be scripted, which could also allow gui hid tests to be scripted
* make the code modular
** This allows HIDs that want to use the crosshair to do so while others don't have to
** This allows plugins to replace the crosshair, or part of the crosshair functionality
* enhance the crosshair's ability to specify locations
** additional snapping targets
** horizontal, vertical, diagonal movement restrictions
* extract the snapping code to its own class
** The crosshair might not be the only thing that could benefit from snapping. For example, I remember something Peter C was saying about contours that didn't close exactly due to rounding errors
** it could allow the snapping functionality to be replaced or augmented by plugins
** it could allow crosshair plugins to also make use of the snapping functionality.
* Let the crosshair draw itself

Lessons from the first implementation:
** "Priority" **
This field was intended to be used to order the snaps in a particular way. It would allow snaps to be inserted into the list before or after other snaps. I'm not sure that this is really necessary. Instead of the SnapList structure that was implemented, it might be better to use a regular GList, since this is a more standard structure.

The priority could have been used perhaps to compute some sort of "weight" when choosing between multiple objects to snap to. So, you would create a list of all possible objects and their distances from the click, then say, multiply by the priority and see which gets the highest score.

Crosshair Actions:
We need a set of crosshair actions that can allow other parts of the program, or scripts, to interact with the crosshair. Some candidate actions:
* move crosshair
* pick up object
* put down object

(?)

Work Items

Work items:
Collect crosshair code into crosshair.[c,h]: TODO
Extract and modularize the snapping code: TODO

This blueprint contains Public information 
Everyone can see this information.