other ways to draw an arc

[Ineiev]

Currently PCB user can draw arcs at limited angles (usually 90 degree step), though there is no such internal limit for arcs angles.

Here I shall put patches to extend user possibilities.

The first patch proposes the next cycle:

1)point at the center,
2)the first point of arc,
3)the second point of arc;
4)return to 2) until ESC

It would be better to return to 3) to be able to continue the arc, but the round-off errors change the radius, so I couldn't make this work clearly.

[Ineiev (ineiev)]

Improved, rebased against current CVS.

Now the patched tool is expected to work like this:
1.point at the center,
2.the first point of arc
  (up to 270 degrees; sets the arc direction),
3.the second point of arc (the direction is the same as at the end
  of 2.; when the new arc overlaps the arc drawn in step 2., a full
  circle is created);
4.return to 3. until ESC (`F3' moves the starting point
  to end of the latest arc and returns to 3.)

During 3. and 4. Shift-click moves the center of the arc
to the pointer.

Switching from/to Line tool draws chained segments.

[Bert Timmerman (bert-timmerman)]

Reworked the patch w.r.t. the new internal coordinate system.

Kind regards,

Bert Timmerman.

[KaiMartin (kmk-familieknaak)]

This highly desirable improvement of the UI has been in the pipe for four and a half years now. I'd really like to use it in regular pcb. Is there any specific reason, why it has not been applied to git-head?
---<)kaimartin(>---

[Bert Timmerman (bert-timmerman)]

Hi Kai-Martin,

I stumbled upon it the other day, and looking into it I saw the bit-rot due to the internal coords stuff changes some time ago.

As you are favouring this different approach to drawing arcs, could you please put this new patch to the (thorough) test as I merely recompiled and played with arcs and lines a bit.

Kind regards,

Bert Timmerman.

[KaiMartin (kmk-familieknaak)]

Hi Bert.
I just installed it on my local working copy of pcb.
First impression: Yes, this is definitely a major improvement over the traditional quarter circle approach. I will put it to use for real projects and see, if there are rough edges.

---<)kaimartin(>---

[KaiMartin (kmk-familieknaak)]

My first layout with arcs drawn with the arc patch just arrived from the fab. I needed to make the PCB fit in a tight place. It was a pleasure use the new UI. There were no hick-ups or artefacts. Recommended for push to the main tree.

---<)kaimartin(>---

[Peter Clifton (pcjc2)]

As a style nit to this patch, we don't usually have things like this:

+Copyright (C) 2008 Ineiev (modified arctool documentation)
                                                      ^____(A DESCRIPTION)
in the header

Copyright notice, by all means, but git is our tool of choice for tracking who changed or contributed what.

Personally, I attribute almost all my changes to gEDA and PCB under the generic catch-all copyright header:

* Copyright (C) 2009-2012 PCB Contributors (see ChangeLog for details)

And I much prefer this, as it avoids marking individual programmers' territory in the source files we are trying to encourage contribution in.

[Peter Clifton (pcjc2)]

I've rebased the patch against current HID API changes.

(No doubt this will change and clash again soon, as I'm still working on the core rendering APIs)

[Peter Clifton (pcjc2)]

My initial reaction to this patch is that having tested it, the behaviour isn't quite right yet, but certainly feels like it represents a huge step in the right direction.

My major gripe is that several times I've switched between line-drawing and arc drawing, only to find I could not draw an arc because I'd not hovered correctly over where the arc's center should lie. If you start arc-drawing from the existing line end-point, the UI is basically stuck drawing a zero radius arc, which is not helpful).

As a further comment - if we want, it should be possible to make the code support an arc greater than 270 degrees. The jumping behaviour with this patch isn't exactly intuitive.

I wonder how the behaviour might feel if we changed the operation order to:

    1. Start point on arc (could be copied from previous line or arc if we just drew one)
    2. Center point of arc (possibly render a faded complete circle to show the curvature this will produce clearly)
    3. End-point dragged to correct angle

This would (I think) be closer to the existing behaviour when creating a run of line-arc-line to produce a rounded profile.

[KaiMartin (kmk-familieknaak)]

I'dsay, no single behaviour would be quite right. In some situations the arc has to touch specific points. Sometimes, the center is known in advance. Sometimes you know for sure that the arc will be multiples of 90°. Most of the 2D vector graphics applications I know, allow for different modes for arcs and circles. E.g: center, radius, angle / two points on diameter and the center / three points on the diameter / center and two tangent lines.
A perfect solution certainly would allow for more than one way to draw an arc. However, it is now four and a half years since the initial patch by Ineiev. It was a significant improvement from day one. Do we really have to cope with cumbersome 90° arcs until the perfect arc tool patch emerges?

---<)kaimartin(>---

[Peter Clifton (pcjc2)]

Let me get my backlog of GL stuff sorted, and I'll try and have a play with the semantics a little.

I don't want to see the current patch committed as is, but I've pushed it into my local patch stack - so I'll ensure it does't bit-rot anymore.

[dn3s (6-d)]

This would greatly improve my workflow, which currently involves drawing arcs, switching over to vim, editing the arc, switching back, dragging it into position, etc. all to fillet a 45 degree corner. Speaking of which, a "fillet" tool would be cool. I'll create a separate feature request.