I have a suggestion that would solve most issues of aligning objects (potentially in both Schematic Editor, PCB Editor, Symbol Editor and Footprint Editor).
It can be implemented with an intuitive user interface and a common GUI, and suffers none of the problems that a separate “ALIGN OBJECTS” functions can have.
It is the ability to drag one or more horisontal Snap-Lines down from the top margin, or vertical snap lines in from the left margin.
These snap-lines are ALWAYS “magnetic”, so (specific parts of) objects can be aligned along a clearly visible horizontal or vertical axis.
A Snap-Line can be dragged/moved.
The Snap-Line context menu has these entries/actions:
Delete
Properties… (P)
Snap Lines provide a great benefit over just relying on the grid because:
It can be placed independent of the current grid
It provides easier accurate/visual alignment than a grid
Snap Lines has been part of the LibreOffice/OpenOffice Draw (vector drawing with SVG support) program for many years.
Selected screenshots from LibreOffice Draw (v 7.6.1.2, MacOS).
Initial view (no visual grid).
Notice top and left ruler showing mm from coordinate system origin.
Adding Vertical and Horisontal Snap Lines
The Snap Lines are created by dragging from the horizontal or vertical ruler.
A Snap line can be deleted by dragging it back into one of the rulers.
I have sometimes thought about something similar. However, this shows how good ideas often get you only halfway through until you find even a better one. Why add lines manually when you already have many “guides” in the design and could use them automatically? I’m still an advocate for Open Source, but some things Microsoft has done better.
I don’t have Powerpoint at hand, but it has an ingenious system for aligning are resizing items. It’s difficult to describe, but allows things which you just can’t do quickly and easily with manual guides. Basically it guesses what you might do based on existing items and the page. It creates and destroys guide lines automatically when you get near certain coordinates, for example, halfway the page, edges, corners etc. Also other item’s center lines and edges. It snaps to those lines your current item’s edges and center lines while you move or resize.
The situation with PCB may be similar: you don’t necessarily have fixed horizontal or vertical coordinate for example for a group of resistors. You can position the first one pretty freely. Then you just want the others to follow the same X or Y line. Why should you create a line manually while you could have the existing resistor’s position to work as X or Y line?
The difference between a powerpoint slide and a layout is that the layout can often be more complex and have much more small items. Automatic guess can become cumbersome. Maybe some kind of heuristic, grid mode which uses guidelines but suppresses the normal grid, and customizable settings would be needed.
There have been some posts on gitlab about adding rulers to KiCad’s editors, but I think it was rejected because of “not enough interest”, but I am not sure. It was a few years ago. The feature you are describing is also very similar to configurable tab stops
Snap-lines look like a simple, yet good idea that would IMO indeed fit the bill here, while being much simpler to implement than a general “alignment” feature. Thanks for your detailed proposal.
Snap lines would be really a great help for aligning/placing components e.g.
But they need to be “configurable”. See attached example taken from Affinity Designer
Guide lines (snap lines) would be independent from grid and they would be created and deleted in WYSIWYG principle one at a time. No, custom grids would be very inconvenient for this – unless custom grid creation and editing would be re-implemented in WYSIWYG, in which case these visible snap lines would be just a custom grid, and custom grids could be edited in the GUI view without a dialog. Maybe not a bad idea after all?
The grid origin should also be kept for each grid. One idea of snap lines is that you can have guide lines for the board which can persist even through the design cycle. This would be broken if changing the grid origin would change the guide line grid.
Creating new lines could happen from item context menu, too: when the ‘+’ cursor is snapped to some item’s snapping point or to an existing grid point, you could use context menu → Create guide line → Vertical / Horizontal / Vert.+Horiz.
Oh, and there’s still one difference between guide lines of other programs and grids of KiCad. In KiCad the cursor always snaps to grid points. In for example office suites it (or the item) snaps to lines. The current implementation of custom grids doesn’t allow for example using a horizontal grid line as snapping line for a row of items – you are forced to create a vertical grid line for each item and they are forced to all have same distance. Then you can use that grid only for those items which fit to that horizontal distance.
I don’t wish to seem rude, but I don’t think you do understand. Or rather, I suspect you’ve never used them. My favourite vector drawing tool, Visio, uses snap-lines, and they are a perfect complement to the grid. I use snap-lines extensively.
One shortcoming of using the grid to align objects is that if you are zoomed in on an object and cannot see the object you want to align it to, then knowing which grid points to use is much harder. Also, when you are zoomed right out, the grid points can appear so close together it’s difficult to distinguish them. The great thing about snap-lines is that they persist across all zoom levels. Note that snap-lines themselves snap to the grid unless you turn that off, so your diagram still lines up with the grid.
The ability to quickly drag a snap-line onto the grid, use it and then delete it, is a great feature. Even though you can’t see the point, the fact that many (most, I think) technical drawing programs provide snap-lines shows that they are considered useful.
I really dislike this kind of “feature request” thread . . . i’t does talk about what the requirement is but how to address the requirement (Snap Lines). It ties the hands of the developers into implementing something as described even if they have a better solution.
I suspect that if they can’t easily implement what is described it will be given low priority . . . whereas if they can come up with an easy to implement solution that meets the requirement they are more likely to get it coded.
Usually critical alignments on my PCBs are all to do with the edge cuts. There are a number of Positioning tools available in the RH Select menu which I find very suitable along with frequently changing grids.
The only other real use I find for something “similar” to a snap line is for creating a “keep out/in” area which usually has something to do with some sort of mechanical constraint I have with a PCB. In that case I’ll draw a line or area using an otherwise unused layer. I would not want it to snap.
Actually I agree with you when it comes to the PCB - I’m not sure it would be all that useful, although the OP may well have a good case for them. However, the OP talked about adding the feature to the schematic, footprint and symbol editors, and those are where I totally agree with him.
I don’t think we can really call it a “requirement” - that suggests something you can’t do without. In my opinion snap-lines are a major “nice-to-have”; they are in that class of features that make your life easier, more pleasant and more productive. The fact that so many vector diagramming tools offer them suggests that they are widely accepted as being of value.
Every feature request has requirements . . . i.e. what problem the feature request is meant to solve. It shouldn’t specify how to solve it, that is up to the developer, that is their role.
The Symbol Editor: It is almost mandatory to use the 50 or 100 mil grid (with snap) for pin placement. Also, using the “Insert” key automatically lines up added pins. A few graphics finish the majority of symbols. In the extreme cases, eg. the user creates their own transistor or switch symbol, a snap-line is of little use as the graphics need to be drawn to the pre-positioned pins which accept snapping.
The Footprint Editor: Much the same as the symbol editor, except the initial pad placing grid needs to be set to the distance between pad centres. Duplicate rows of pads, change grids to locate other pad rows.
Change grids again and use dx/dy to centre graphics.
The Schematic Editor: Again, I cannot see a purpose for a Snap-line. The schematic editor is all about joining pins to wires to produce nets in a relatively human readable form, so, if you place all the symbols in as straight a line as the pin placement allows, there will probably be quite a jungle of wires to try to decipher.
This is a feature request for specific new functionality in the user interface. It isn’t anything that needs “solving”. It’s like asking your ice cream vendor to put chocolate sprinkles on top: it’s not a problem as is, and it doesn’t need solving, it’s just a nice-to-have that improves the product.
The idea that every request has to start with a problem is a bit daft - it’s totally reasonable (and often very helpful) to suggest enhancements. In fact virtually every change request I’ve submitted to other software projects has been for an improvement rather than to fix a problem. There is always room for improvement.
