Re: [Kicad-developers] 6.0 Zone filling differences
This is another excellent test because it does some pretty weird stuff (such as rounded rectangle pads mimicking circular ones so that the thermal spokes are at 90º instead of 45º). Anyway, I’ve pushed bits that make it mostly good now. There are still 4 unconnected thermal sinks where it was taking advantage of a bug which no longer exists (thermal spokes connecting to each other rather than to the zone). Cheers, Jeff. PS: the “fully” rounded rectangle pads exposed two older bugs: (a) the old thermal relief algorithm wasn’t taking the radius into account, and (b) the low-res/high-res optimisation needs to go to high-res for rounded rectangles with large radii (I chose above 40% as the cutoff). > On 24 Jun 2019, at 16:59, Seth Hillbrand wrote: > > On 2019-06-23 18:00, Jeff Young wrote: >> I’ve pushed bits to address Seth’s case. His case also had slightly >> different performance issues, so there are some more improvements >> there too. > > Thanks Jeff! That board works much better with the new code now. > > I'm attaching another corner case. This is the BeagleBone Blue project in > KiCad format. There are no DRC errors or unconnected nets in 5.1.2+. > > Best- > Seth ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Zones 45 degree
It will also need a bit of a tweak. If the zone boundary covers an odd number of grid points the center point will be inter-grid. Dragging it needs to leave it there, not snap to one or the other grid points to either side. > On 24 Jun 2019, at 14:07, Tomasz Wlostowski wrote: > > On 24/06/2019 15:05, Wayne Stambaugh wrote: > >> The geometric constraint solver will be the solution for v6 but this >> still leaves us with the issue of what to do for the 5.1 branch. > > Hi Wayne, > > I didn't notice it's for v5.1.x branch. In this case, Seth solution is > perfectly OK. > > Tom > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Zones 45 degree
On 24/06/2019 15:05, Wayne Stambaugh wrote: > The geometric constraint solver will be the solution for v6 but this > still leaves us with the issue of what to do for the 5.1 branch. Hi Wayne, I didn't notice it's for v5.1.x branch. In this case, Seth solution is perfectly OK. Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Zones 45 degree
Tom, On 6/24/19 5:57 AM, Tomasz Wlostowski wrote: > On 24/06/2019 11:50, Simon Richter wrote: >> Hi, >> >> On Mon, Jun 24, 2019 at 12:43:47AM -0400, Seth Hillbrand wrote: >> >>> 1) a double-joint in the final connection >> >> Hm, that might be an interesting creation mode: draw the outline as if it >> were a trace. >> >> I'm not entirely convinced that there are many use cases for that though. > > Hi, > > This is coming in the geometric constraint solver work package... > > Tom The geometric constraint solver will be the solution for v6 but this still leaves us with the issue of what to do for the 5.1 branch. I believe that this bug has indeed been around since this was implemented. I guess the question is what to do about it? Since the constraint solver hasn't been merged into the master branch, I'm guessing that fixing this in the master branch should be fairly easily cherry-picked into the 5.1 branch. I like Seth's "disabling end-point dragging in the outline - only center-point dragging and with the Alternate constraint fixed on" proposal as a fix. It been a while but I'm pretty sure the intent of the 45 degree zone setting was to always maintain the constraint not just when the zone was created. Cheers, Wayne ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Immediate mode actions
Jeff, I just finished testing this and it looks good. It wasn't an exhaustive test so if I find any issues I will file a bug report. Go ahead and push the board and footprint editor changes. Thanks, Wayne On 6/23/19 6:35 PM, Jeff Young wrote: > There haven’t been any additional comments on this. Is everyone happy with > it? Should I push the changes to Pcbnew? > > Cheers, > Jeff. > > >> On 19 Jun 2019, at 18:36, Jeff Young wrote: >> >> New bits are in…. >> >>> On 19 Jun 2019, at 18:04, Wayne Stambaugh wrote: >>> >>> For new features like bus unfolding, we have some leeway to decide how >>> we want to handle things. I think in the case of bus unfolding, >>> selecting the wire tool makes sense. Whether or not drawing a wire >>> should immediately happen after unfolding a bus is debatable. I'm open >>> to ideas on this. >>> >>> On 6/19/19 10:27 AM, Jeff Young wrote: I take the question back. It will be *far* easier to implement it like “start wire”, so unless anyone objects I’ll go that way. Cheers, Jeff. > On 19 Jun 2019, at 15:18, Jeff Young wrote: > > What about “unfold bus”? Leaves you in the wire tool (like “start > wire”), or in the previous tool (like “move”)? > >> On 19 Jun 2019, at 15:08, Jeff Young wrote: >> >> Ahh, I misunderstood your earlier comments. When you said they should >> act the same I thought you meant both like the old immediate action >> behaviour, not both like the old toolbar behaviour. >> >>> On 19 Jun 2019, at 13:46, Wayne Stambaugh wrote: >>> >>> The immediate actions are back to the same behavior as the initial >>> commit (one shot) and using the toolbar or menu to select a tool now >>> stacks tools so each escape to exit the current tool brings up the >>> previous tool until you finally end up back at the selection tool. I >>> think users are going to expect exiting a tool to always end up back at >>> the selection tool not the previously selected tool. Here is a synopsis >>> of the behavior I think we should aim for: >>> >>> Immediate actions: >>> >>> 1. The appropriate tool should be enabled and begin drawing at the >>> current cursor location (works). >>> 2. When the tool is busy drawing, the escape key should cancel the >>> current edit and the selected tool should remain enabled. Immediate >>> actions like move, rotate, mirror, etc. should be blocked until the tool >>> is idle but I'm open to suggestion on this. I can see the utility in >>> canceling the edit and performing the requested action. >>> 3. When the tool is idle, the escape key should exit the tool and return >>> to the selection tool. Immediate actions like move, rotate, mirror, >>> etc. should perform the expected operation and return to the selected >>> tool. >>> >>> Using the toolbar and menu to select a tool should behave the same as >>> above except that no drawing begins at the current cursor position >>> because the cursor position is meaningless while it's over a toolbar >>> button or menu entry. >>> >>> I hope I am explaining this well enough. >>> >>> On 6/18/19 5:35 PM, Jeff Young wrote: OK, next attempt is in. ;) > On 18 Jun 2019, at 21:07, Wayne Stambaugh > wrote: > > Better but now the second (third, fourth, fifth, ...) escape key does > not exit after the first escape key cancels the immediate action. > Using > the toolbar or menu to select the tool does work correctly. One other > new oddity is that selecting a second tool using the toolbar or menu > will result in the previous tool being selected rather than the > selection tool after escape is pressed when the tool is idle. I think > you may have gone too far the other way. > > On 6/18/19 3:52 PM, Jeff Young wrote: >> Hi Wayne, >> >> I checked in some new code. Give it a go when you get a chance. >> >> Cheers, >> Jeff. >> >> >>> On 18 Jun 2019, at 13:01, Wayne Stambaugh >>> wrote: >>> >>> Wire, bus, graphic line, and sheet but only when enabled with an >>> immediate hotkey. When I enable the tool via a toolbar button or >>> selecting a menu entry, then the behavior is the same as the legacy >>> tool >>> framework. It really should not matter how a tool is enabled, only >>> the >>> initial behavior. >>> >>> On 6/18/2019 7:53 AM, Jeff Young wrote: Hi Wayne, I wrote the whole PushTool/PopTool stuff exactly for that case. Which action in particular is going back to the SelectionTool? (Note that some are “supposed” to. If you click on a tool in the
Re: [Kicad-developers] Zones 45 degree
On 24/06/2019 11:50, Simon Richter wrote: > Hi, > > On Mon, Jun 24, 2019 at 12:43:47AM -0400, Seth Hillbrand wrote: > >> 1) a double-joint in the final connection > > Hm, that might be an interesting creation mode: draw the outline as if it > were a trace. > > I'm not entirely convinced that there are many use cases for that though. Hi, This is coming in the geometric constraint solver work package... Tom ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Zones 45 degree
Hi, On Mon, Jun 24, 2019 at 12:43:47AM -0400, Seth Hillbrand wrote: > 1) a double-joint in the final connection Hm, that might be an interesting creation mode: draw the outline as if it were a trace. I'm not entirely convinced that there are many use cases for that though. Simon ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Zones 45 degree
I think the final segment issue has always been a bug. There’s a bunch of constraint code in the POINT_EDITOR, so I think it’s *meant* to work while editing a zone. (The code includes both single-point constraints and two-point constraints, but I haven’t ever dug into it to see what they do.) Cheers, Jeff. > On 24 Jun 2019, at 05:43, Seth Hillbrand wrote: > > Hi All- > > This bug report [1] notes that the "Constrain zone to 90/45" option only > works during zone creation. The option also doesn't constrain the final > angle. > > I note that this option is stored in the file format, so it seems the > intention was for it to be persistent. Anyone have some more background on > this option? Did it work in the legacy canvas? > > I'm thinking that fixing the bug requires two things: > > 1) a double-joint in the final connection > 2) disabling end-point dragging in the outline - only center-point dragging > and with the Alternate constraint fixed on. > > What do folks think? > > -Seth > > [1] https://bugs.launchpad.net/kicad/+bug/1833673 > > ___ > Mailing list: https://launchpad.net/~kicad-developers > Post to : kicad-developers@lists.launchpad.net > Unsubscribe : https://launchpad.net/~kicad-developers > More help : https://help.launchpad.net/ListHelp ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
