DIY Layout Creator - software for easy drawing PCB, vero and perfboard layouts

[Perrow]

You didn't understand me or GGBB?

[GGBB]

I'm not sure I understand, align what against what? You mean, I select few components, click align and each one of them realigns itself to the closest grid point?

Maybe align was a poor choice of words.  What I mean is, I can easily arrange my pads using a metric grid with snapping on, and then group them.  Then I can easily switch back to an imperial grid and snap the group of pads to the imperial grid.  But it appears to snap to one of the pads in the group, not to the group as a whole (all the pads move of course, it's just the snapping point I'm talking about).  I would like to be able to snap the group to the grid at the very center (in this case the center pad of the nine).  I have tried to get it to use the center pad by changing the order in which I select the pads before grouping, but that doesn't seem to work.  It also doesn't seem to be consistent about which pad it uses to snap with.  This makes it impossible to do quality layouts with on-board hardware like switches and jacks since the pin layouts of those is almost always something odd.

Perrow's idea of a pad group sounds really good too, but the problem is not being able to make a group of pads with the correct alignment.  The problem is in how it is snapped to the grid.  If certain items like a pad group had another property to control what the anchor point is for grid snapping, that would be great.  But a simple change to how groups are snapped like I describe would help a great deal.  Even a feature like "set position" that also works on groups of items would be great (need to choose anchor point as well).

I'll mention another thing at the moment because it's related - the minimum grid spacing is too large.

And regarding Perrow's idea - settings for horizontal and vertical pin spacing would be useful for certain components as well as a "pad group" - things like switches.  I like to use DIYLC for diagrams as much as I do for PCB layouts.

And while I'm at it - The Potentimeter component needs to be able to set the spacing of the lugs from the center of the pot body.  As it is right now, the lugs are too close to the body for a typical 16mm pot.

[snarblinge]

This is a suggestion from a program user not creator, but if this software is written in java, and ggbb has written a script that rotates things, couldn't that script be sent to Bancika to be added in at some stage, I love this software and it is a labour of love for Bancika and it seems we get quite a few heavy handed suggestions here for something we all get for pretty much nothing.

[bancika]

Script probably deals with XML directly. In DIYLC XML is only used as storage, all operations are done on objects that are (de)serialized from XML tags. I don't mind implementing rotation. I remember having various problems in older version with some corner cases. If we hash out how it's supposed to work, implementing should be easy. I think the first thing to determine is - center point around which we rotate. Also, some components have their own orientation. If I, for example select an IC with or without adjacent components, should rotating affects IC's orientation? That can get very complicate because I'd need to realign any traces leading to IC pins.
Cheers

[GGBB]

Script probably deals with XML directly. In DIYLC XML is only used as storage, all operations are done on objects that are (de)serialized from XML tags. I don't mind implementing rotation. I remember having various problems in older version with some corner cases. If we hash out how it's supposed to work, implementing should be easy. I think the first thing to determine is - center point around which we rotate. Also, some components have their own orientation. If I, for example select an IC with or without adjacent components, should rotating affects IC's orientation? That can get very complicate because I'd need to realign any traces leading to IC pins.
Cheers

It's not a script - it is actual Java code that manipulates the DOM objects.  But yes, I load the XML file and then work from there - I am not inside DIYLC.

Rotation design patterns typically rotate around the center point.  Rotating objects along with connections can make things messy.  I would recommend either a simple approach whereby only one object can be rotated at a time, or an approach whereby selected objects are rotated and all outside connections are severed, and after rotation the selected objects are floating in paste mode so that the user can click to drop the rotated objects wherever they want (or cancel with escape).  Extra bonus points for automatically rotating any pads and traces that belong exclusively to rotated objects (not outside connections) without them having to be selected - in this way the user only has to select components and doesn't have to selects pads and traces.

[bancika]

center point is definitely the right choice, but it's often not on the grid. Also, do I calculate center point of the polygonal formed by all control points of the selected component(s) or center point of the union of shape(s) that represent selected components. It's not the same. Should I snap the center point to grid before rotating? Should I snap control points after rotation if they end up outside the grid? A lot of minor issues that make it difficult to do perfectly

[Perrow]

I say rotate around the grid point closest to the center of the bounding rectangle of all selected objects (i.e. calculate center and the drop any decimals). Anything not on the grid remains off grid. No sticky points considered, rotation is such a major operation that no one can hope to keep any meaningful connections after rotating a subset of components and traces.

[bancika]

and let's figure out how moving a group of component works. How it works now is that it picks a component (pretty much random), moves and snaps to grid if snap is ON and then moves all the other components in the group for the same distance as the first one is moved. That's a problem because you can have two components, one snapped, the other not snapped. If you move them together it may happen that the snapped one will not be snapped anymore and the second one will. Confusing

[GGBB]

It's always the details that get in the way of good ideas!

I agree with Perrow - use the point closest to the center - but that point should be one that is already on the grid in cases where some points are not.  It will be reasonable to assume that most of the points will be on-grid already, so rotating around the one that is closest to center and on-grid will give the best experience.  And I would use the control points not the polygonal shapes since the use case will almost certainly be concerned with the control points not the shapes.  But I think it is important that we let the user "anchor" the objects after rotation in the same way that they have to anchor a pasted object.  This is because it is actually unlikely that the center is where they really want the rotation to occur - it is more likely to be an outside edge or corner.  But it is clumsy to ask the user what point to use - far simpler to simply let them do the drop/anchor wherever they desire - and I think a far better user experience.  They key is that the point used for rotation needs to be the same as the point used to snap, and of course this point should both begin and end on-grid.

and let's figure out how moving a group of component works. How it works now is that it picks a component (pretty much random), moves and snaps to grid if snap is ON and then moves all the other components in the group for the same distance as the first one is moved.

That "random" choice needs to change - at least for rotation.

[bancika]

it's a 7 year old post, we crossed that bridge long time ago. You can place component at any angle now and show it with or without anti-aliasing 

[Perrow]

What I meant was to rotate around the grid point closest to the center as a "virtual anchor point". Determine what point to use as reference then rotate everything around that point. Consider rotating two components that are far apart, you'd want to use some point close to the geometrical center rather than the control point closest to the center.

If I remember correctly in 3D Studio, you select what you want to rotate, select 'rotate', click to select center of rotation and finally click and drag to actually rotate the object. It's a powerful but cumbersome (and non intuitive) way to do it.

For moving components I would expect the component I actually use (click and drag) to move my selection to control the snapping to the grid. If I want to move a bunch of components that are off the grid I can add an "on grid" component to the selection and use that to drag the selection to the new location with everything else retaining their off-gridishness.

[bancika]

yeah, I think moving is good now....it behaves differently when one or more components are selected. For one component, moving a off-grid component using snap-to-grid will snap it to the closest point. However, moving multiple components at the same time will maintain their off-gridishness. I don't know if we need to allow for one component to maintain it's off-gridishness...

as for rotation, my biggest concern at the moment is marrying rotation with component's own orientation (which is sort of a rotation on itself). It would be stupid to leave ICs, transistors and similar components just rotated around the point without changing their own orientation, and I'm not sure if changing the orientation will be feasible. My biggest concern is keeping whatever is selected looking the same, but rotated for 90 degrees...but I can try

[Perrow]

Needless to say, rotating multiple components will really need to rotate each individual component (IC, transistors, etc). I haven't looked at your code but I hope you have a uniform representation of rotation for all types of components (single control point components that is), so all types can be rotated using the same code. Perhaps the "orientation" in the options dialog can be hidden when rotation works.

Might I suggest CTRL+arrowkeys (left and right) as a shortcut for rotation?

[bancika]

shortcut is the least of my worries Yes, all components that are rotatable have orientation property of the same type, so I can just extract them and move to the next or previous value. That's the easy part. The hard could be maintaining links with other components that are (or not) selected

[Perrow]

I can't see maintaining links as desired (perhaps because I seldom use sticky points), rotating stuff will modify the layout so much that I can't see how maintained connections are interesting.

[bancika]

I'll give it a shot

[GGBB]

as for rotation, my biggest concern at the moment is marrying rotation with component's own orientation (which is sort of a rotation on itself). It would be stupid to leave ICs, transistors and similar components just rotated around the point without changing their own orientation, and I'm not sure if changing the orientation will be feasible. My biggest concern is keeping whatever is selected looking the same, but rotated for 90 degrees...but I can try

My code does this with out any issues.  Where there is an orientation property, I adjust this as well as the control points.  For the actual rotation itself, I think the easiest way to do it is to calculate the outside corners of the rectangle defined by the set of control points and rotate based on that.  That approach would work for a single component as well as multiple.

[bancika]

okey dokey

[bancika]

check out the new version https://code.google.com/p/diy-layout-creator/downloads

Cheers

[Perrow]

Hours before I can give it a go, anticipation's gonna kill me