Re: [Kicad-developers] Latest info on copper zones using solid polygons without outline thickness.
Dear all DEV ! I am currently designing pcb using zuken's cr5000 software, I would like to contribute to kicad's development, this is gerber when exported from cr5000, they use line and arc to create copper zones, hopefully this will is a good idea for us Vào Th 2, 10 thg 6, 2019 vào lúc 01:51 jp charras đã viết: > Le 09/06/2019 à 19:56, Tomasz Wlostowski a écrit : > > On 05/06/2019 21:21, jp charras wrote: > > > >> It is on the master branch (just committed). > > > > Hi JP, > > > > I gave it a try with a bunch of designs. Here are my observations: > > - The filled zones look correct on the super-complex board and the > > number of unconnected nets is identical to the old algorithm. > > - There's a serios issue: connectivity algo can generate false positives > > (thinking zones are connected to tracks or other zones) because is still > > assumes all zones have thick outlines (see CN_ZONE::ContainsPoint). Did > > you foresee any means of indicating this in the file format? Should > > Gerber/other exporters be changed accordingly? > > - I would rephrase the board setup zone filling option choice - it's the > > max approximation error that defines the drawing quality, not the fact > > that zones are outlined with rounded segments. My choice for the option > > would be a single option "Use legacy zone filling outline method", off > > by default. > > - @Wayne/Seth I agree with JP that the change to the zone filling > > algorithm is not very intrusive (and I also trust Clipper's > > inflate/erode algorithms - they're used in the current zone filler and > > never failed us so far). > > > > I can fix the connectivity issue. Who's in for Gerber/other exporters > > (if needed?) > > > > Cheers, > > Tom > > First, thanks Tom for your test. > > But are the drawing issues (calculation time and memory overflow) fixed > by this change? > They were the main reason of this change. > > * Unless bugs, plot functions are updated and are compatible with both > zone filling algos. > > * The file format keep trace of the zone filling algo that filled the > zone (of course, because do not know how the zone was filled can create > serious issues): > the flag " (filled_areas_thickness no)" is added in the zone section > when the fill algo is "do not use thick outline". > It also ensure a "old" Pcbnew version cannot create broken Gerber files. > > * The accessor to know the fill algo used to fill the zone is: > bool GetFilledPolysUseThickness() const > that returns false for the new algo. > > * I was not aware of the connectivity issue. Please, fix it. > Thanks. > > * About the zone setup dialog: > For me, the choice is temporary, until we are confident with the new algo. > Usually, when a new option is added, the default choice is: keep the old > behavior. > It avoid many bug reports. > However make the new algo the default could be the best way to test it... > I am not thrilled by messages like "Use legacy ..." because only core > developpers know the difference between "legacy" and "current" or "new" > about algorithms. > In fact, in my mind, the choice should be removed for the stable 6.0 > version: the user has no knowledge to choose the right option. > > -- > Jean-Pierre CHARRAS > > ___ > 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 > -- LÊ VĂN LẬP --- Sđt: 01223992496 Email: levanlap2...@gmail.com ___ 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] PATCH pcbnew half-rotate actions and shortcuts
I could replace diff pair dimensions shortcut with something else if that is fine by devs, Ctrl+Shift+I is available. On Sat, Jun 8, 2019 at 3:49 AM Ian McInerney wrote: > Just a note, the hotkey ctrl+shift+R is already assigned to "Differential > Pair Dimensions" by default so this would introduce a duplicate hotkey > conflict. It probably makes sense for this action to be ctrl+shift+R, but > that means that the other needs to be changed. > > Also, as a side note to the lead devs, is it still necessary to have the > hotkeys say (Modern Toolset only) in the master branch? > > -Ian > > On Sat, Jun 8, 2019 at 8:22 AM Andrew Lutsenko > wrote: > >> Hi all, >> >> I frequently find that I need to rotate a footprint or a few by 45 >> degrees. To do that I either have to edit it's properties (works if it's >> just one but slow) or change pcbnew preferences (very slow). >> I thought I'd add a quick shortcut to rotate selected items by half of >> the configured rotation angle and learn a bit of tool related code in the >> process. Please see attached patch for that. >> >> I suspect the way I handled passing double parameter to the action is not >> ideal but it's impossible to have a pointer to constant literal without >> storing it in a variable (to my knowledge). I'm open to suggestions on how >> to clean up that part, maybe move the constants somewhere? >> >> Regards, >> Andrew >> ___ >> 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] New package for macOS 5.1.2 stable including ngspice-30 ?
Is there a reason that pushing a change like this can't wait until the 5.1.3 release? Wayne had mentioned wanting to try to get it out the door in early July, which wouldn't be that far off. That would also give more uniformity in its roll out across the various platforms, and allow for easier identification of if a user is using the ngsice-30 version when bug reports are filed (since apparently the version information doesn't seem to contain that). Just my 2 cents... -Ian On Sun, Jun 9, 2019 at 10:01 PM Adam Wolf wrote: > How about making 5.1.2-1 or -2 or whatever. I don't like replacing > packages that have been released. > > I just updated the package so nightlies tonight should be from the > upstream ngspice-30-2 tag. If they build, and if someone can commit to > trying it out, I can regenerate 5.1.2-x this week! > > Thanks folks! > > Adam > > On Sun, Jun 9, 2019 at 11:28 AM Carsten Schoenert > wrote: > > > > Hi > > > > Am 09.06.19 um 09:03 schrieb Holger Vogt: > > > Hi Adam, > > > > > > would you mind creating a new package for macOS 5.1.2 stable replacing > > > the outdated libngspice 26 by the recent libngspice version 30? > > > > > > And then use libngspice 30 also for the nightlies? > > > > > > Nick has done this successfully for Windows. All tests have been o.k.. > > > > > > The users may benefit from the ngspice patches since version 26 (see > > > https://bugs.launchpad.net/kicad/+bug/1821520) towards better usage > > > during pcb design. > > > > it should be possible to check the version of the ngspice library while > > the cmake configure run and error out if the version is lower than 30. > > I'm not an CMake expert but some version check should be possible here > too. > > > > -- > > Regards > > Carsten Schoenert > > > > ___ > > 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 > ___ 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] 5.1.3 stable release
To add on to this, the hotkey validation architecture that I have been building up to take care of the many issues surrounding the duplicate/invalid hotkeys (and also the fact that they can exist due to a user's hotkey settings from prior versions) will require new strings since I have error prompts. If this is something that should go in 5.1.3, then string changes will need to be allowed. I hope to have a patch set based on master put together in the next few days for people to test, and if you want to include it in 5.1.3 I can trim down the patch set to work on the 5.1 (I believe that some changes may not cherrypick easily from master to 5.1). -Ian On Sun, Jun 9, 2019 at 3:27 PM Seth Hillbrand wrote: > On 2019-05-22 16:37, Wayne Stambaugh wrote: > > We are getting a decent set of bug fixes in the 5.1 branch so we should > > seriously start thinking about a 5.1.3 stable release by the end of > > June. What I would like to see is push to fix some of the outstanding > > 5.1 bugs[1] and then do a string freeze in the middle of June. If you > > see a bug that is code that you are familiar with, please consider > > fixing it. There will be plenty of time to work on v6. Thanks again > > everyone for your continued efforts. > > Hi Wayne- > > Are we considering string changes for 5.1.3? I had thought our policy > was no string changes for the minor bug fix releases. If we do have > string changes, I'll push a couple additional mods to the 5.1.3 branch > that clarify actions. > > Could we also get a 5.1.4 tag for bugs that are lower priority/harder > implementations? > > -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 > ___ 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] New package for macOS 5.1.2 stable including ngspice-30 ?
How about making 5.1.2-1 or -2 or whatever. I don't like replacing packages that have been released. I just updated the package so nightlies tonight should be from the upstream ngspice-30-2 tag. If they build, and if someone can commit to trying it out, I can regenerate 5.1.2-x this week! Thanks folks! Adam On Sun, Jun 9, 2019 at 11:28 AM Carsten Schoenert wrote: > > Hi > > Am 09.06.19 um 09:03 schrieb Holger Vogt: > > Hi Adam, > > > > would you mind creating a new package for macOS 5.1.2 stable replacing > > the outdated libngspice 26 by the recent libngspice version 30? > > > > And then use libngspice 30 also for the nightlies? > > > > Nick has done this successfully for Windows. All tests have been o.k.. > > > > The users may benefit from the ngspice patches since version 26 (see > > https://bugs.launchpad.net/kicad/+bug/1821520) towards better usage > > during pcb design. > > it should be possible to check the version of the ngspice library while > the cmake configure run and error out if the version is lower than 30. > I'm not an CMake expert but some version check should be possible here too. > > -- > Regards > Carsten Schoenert > > ___ > 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] Latest info on copper zones using solid polygons without outline thickness.
Le 09/06/2019 à 19:56, Tomasz Wlostowski a écrit : > On 05/06/2019 21:21, jp charras wrote: > >> It is on the master branch (just committed). > > Hi JP, > > I gave it a try with a bunch of designs. Here are my observations: > - The filled zones look correct on the super-complex board and the > number of unconnected nets is identical to the old algorithm. > - There's a serios issue: connectivity algo can generate false positives > (thinking zones are connected to tracks or other zones) because is still > assumes all zones have thick outlines (see CN_ZONE::ContainsPoint). Did > you foresee any means of indicating this in the file format? Should > Gerber/other exporters be changed accordingly? > - I would rephrase the board setup zone filling option choice - it's the > max approximation error that defines the drawing quality, not the fact > that zones are outlined with rounded segments. My choice for the option > would be a single option "Use legacy zone filling outline method", off > by default. > - @Wayne/Seth I agree with JP that the change to the zone filling > algorithm is not very intrusive (and I also trust Clipper's > inflate/erode algorithms - they're used in the current zone filler and > never failed us so far). > > I can fix the connectivity issue. Who's in for Gerber/other exporters > (if needed?) > > Cheers, > Tom First, thanks Tom for your test. But are the drawing issues (calculation time and memory overflow) fixed by this change? They were the main reason of this change. * Unless bugs, plot functions are updated and are compatible with both zone filling algos. * The file format keep trace of the zone filling algo that filled the zone (of course, because do not know how the zone was filled can create serious issues): the flag " (filled_areas_thickness no)" is added in the zone section when the fill algo is "do not use thick outline". It also ensure a "old" Pcbnew version cannot create broken Gerber files. * The accessor to know the fill algo used to fill the zone is: bool GetFilledPolysUseThickness() const that returns false for the new algo. * I was not aware of the connectivity issue. Please, fix it. Thanks. * About the zone setup dialog: For me, the choice is temporary, until we are confident with the new algo. Usually, when a new option is added, the default choice is: keep the old behavior. It avoid many bug reports. However make the new algo the default could be the best way to test it... I am not thrilled by messages like "Use legacy ..." because only core developpers know the difference between "legacy" and "current" or "new" about algorithms. In fact, in my mind, the choice should be removed for the stable 6.0 version: the user has no knowledge to choose the right option. -- Jean-Pierre CHARRAS ___ 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] Latest info on copper zones using solid polygons without outline thickness.
On 05/06/2019 21:21, jp charras wrote: > It is on the master branch (just committed). Hi JP, I gave it a try with a bunch of designs. Here are my observations: - The filled zones look correct on the super-complex board and the number of unconnected nets is identical to the old algorithm. - There's a serios issue: connectivity algo can generate false positives (thinking zones are connected to tracks or other zones) because is still assumes all zones have thick outlines (see CN_ZONE::ContainsPoint). Did you foresee any means of indicating this in the file format? Should Gerber/other exporters be changed accordingly? - I would rephrase the board setup zone filling option choice - it's the max approximation error that defines the drawing quality, not the fact that zones are outlined with rounded segments. My choice for the option would be a single option "Use legacy zone filling outline method", off by default. - @Wayne/Seth I agree with JP that the change to the zone filling algorithm is not very intrusive (and I also trust Clipper's inflate/erode algorithms - they're used in the current zone filler and never failed us so far). I can fix the connectivity issue. Who's in for Gerber/other exporters (if needed?) Cheers, 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] New package for macOS 5.1.2 stable including ngspice-30 ?
Hi Am 09.06.19 um 09:03 schrieb Holger Vogt: > Hi Adam, > > would you mind creating a new package for macOS 5.1.2 stable replacing > the outdated libngspice 26 by the recent libngspice version 30? > > And then use libngspice 30 also for the nightlies? > > Nick has done this successfully for Windows. All tests have been o.k.. > > The users may benefit from the ngspice patches since version 26 (see > https://bugs.launchpad.net/kicad/+bug/1821520) towards better usage > during pcb design. it should be possible to check the version of the ngspice library while the cmake configure run and error out if the version is lower than 30. I'm not an CMake expert but some version check should be possible here too. -- Regards Carsten Schoenert ___ 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
[Kicad-developers] MIT License
Hi All- Just a heads up that I ran across one of our included libraries (tinyspline) that is under the MIT license. This is compatible with our AGPL, so I've simply added the license text to a LICENSE.MIT and listed in the readme where to find it. -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] Patch set: Display Origin Transforms rebase
On 2019-06-09 10:29, Reece R. Pollack wrote: Sorry about the delay in responding. I've been traveling. I don't believe overloading the base instance of GetMsgPanelInfo() and GetSelectMenuText() will achieve the desired goal. Overloading functions works great when the _caller_ wants to choose between variants of a function. In this case, though, the call is being made via a pointer to a EDA_ITEM (in EDA_DRAW_FRAME::SetMsgPanel(), currently at common/legacy_gal/eda_draw_frame.cpp:582). The caller has no knowledge of whether the object requires the third parameter or not. Since EDA_DRAW_FRAME is common to all applications, it's an all or none situation. Hi Reece- The calls toe SetMsgPanel() come from the application. You can use a default parameter here (and in UpdateMsgPanel()) to avoid touching the non-pcbnew applications with the patchset. -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] Patch set: Display Origin Transforms rebase
Sorry about the delay in responding. I've been traveling. I don't believe overloading the base instance of GetMsgPanelInfo() and GetSelectMenuText() will achieve the desired goal. Overloading functions works great when the /caller/ wants to choose between variants of a function. In this case, though, the call is being made via a pointer to a EDA_ITEM (in EDA_DRAW_FRAME::SetMsgPanel(), currently at common/legacy_gal/eda_draw_frame.cpp:582). The caller has no knowledge of whether the object requires the third parameter or not. Since EDA_DRAW_FRAME is common to all applications, it's an all or none situation. Realistically, I expect support for origin transforms will eventually be integrated into all of the applications. Pcbnew first, but users are going to expect consistency from Gerbview. The footprint editor would also benefit greatly, and thus cvpcb too. Okay, maybe the PCB Calculator won't support display origin transforms, and it seems the work sheet editor already has a similar concept. That leaves Eeschema and the symbol editor. The Aux Origin is defined in Eeschema but there's no way to set it and I'm not sure that's the best way to handle the situation anyway. Although my previous patch set didn't tweak GetMsgPanelInfo() and GetSelectMenuText() in Eeschema code to perform display origin transforms, that could have be done easily since they already receive a reference to an ORIGIN_TRANSFORMS object, which is currently NullOriginTransforms. Then whatever scheme was developed for Eeschema would only require that flavor of ORIGIN_TRANSFORMS to be passed in and these would work. Only the Eeschema flavor of UNIT_BINDER and the appropriate changes to the dialogs would then be needed. Also consider that much of the DRC marker code is shared between Pcbnew and Eeschema. While Eeschema can simply pass a reference to the NullObjectTransforms object to the common DRC code, this means Eeschema can't be completely isolated from these changes. The alternative is for someone to come up with a scheme by which the editor hierarchy can provide display formatting functions to the structural hierarchy without passing a parameter to these display-oriented functions. I don't think that's likely, though I'm open to suggestions. Perhaps the display formatting could be bundled into a class, rather than being classless, global functions as they are now. The editors could then pass a reference to this formatting class in place of the current EDA_UNITS parameter. The display formatting class could handle display units (mm vs in) and origin transformations internally. This could also help ease future formatting enhancements. However, this sort of change would be far broader in scope than my current patch set, and I was hoping for my entrance to the KiCad development community to be a bit less dramatic. -Reece On 5/26/19 5:57 PM, Wayne Stambaugh wrote: Seth, I'm fine with this approach. I like your idea of deriving a new UNIT_BINDER object so that it doesn't impact the other frames that do not use ORIGIN_TRANSFORMS. Cheers, Wayne On 5/26/19 4:15 PM, Seth Hillbrand wrote: Hi All- If Reece can separate this so that it doesn't affect eeschema, cvpcb, pagelayout_editor, gerbview or libedit, I'm fine with merging as is and refactoring more later. If we merge this as is, it become much more difficult to fix it later. Since these are all GetMsgPanelInfo() calls, the fix is simply to overload the base instance and then any call that doesn't use ORIGIN_TRANSFORMS should not pass it as a parameter. Once this change is implemented, the rebasing should not be nearly so painful, so the extra holds on commits should not be required. -Seth The fix for this is simply overloading On 2019-05-26 15:54, Jon Evans wrote: Hi Reece, Wayne, Seth, Can you clarify the path forward here? Are we going to merge the second patchset and then do follow-ons to take care of the issues Seth raised, or will there be another full patchset coming? I have a backlog of things to cherry-pick from 5.1 to master that I've been holding on to until this is resolved. Thanks, -Jon On Sun, May 26, 2019 at 2:08 PM Reece R. Pollack wrote: So now it occurs to me that what I should have done was create classes derived from UNIT_BINDER that handle the different types of data (X-abs, Y-abs, X-rel, Y-rel) and instantiated those, rather than adding a parameter to the UNIT_BINDER class. However, that would have also required changing UNIT_BINDER to accept and return _double_ values rather than _int_ to avoid the _int_ -> _double_ -> _int_ -> _double_ conversion sequence formatting for display, and _double_ -> _int_ -> _double_ -> _int_ conversions parsing from display. Maybe I'll do that another time. Too many changes too late for this iteration, I think. On 5/26/19 11:01 AM, Reece Pollack wrote: The specific problem with UNIT_BINDER is that it doesn't know what sort of data it's handling. It could be a
Re: [Kicad-developers] 5.1.3 stable release
On 2019-05-22 16:37, Wayne Stambaugh wrote: We are getting a decent set of bug fixes in the 5.1 branch so we should seriously start thinking about a 5.1.3 stable release by the end of June. What I would like to see is push to fix some of the outstanding 5.1 bugs[1] and then do a string freeze in the middle of June. If you see a bug that is code that you are familiar with, please consider fixing it. There will be plenty of time to work on v6. Thanks again everyone for your continued efforts. Hi Wayne- Are we considering string changes for 5.1.3? I had thought our policy was no string changes for the minor bug fix releases. If we do have string changes, I'll push a couple additional mods to the 5.1.3 branch that clarify actions. Could we also get a 5.1.4 tag for bugs that are lower priority/harder implementations? -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
[Kicad-developers] New package for macOS 5.1.2 stable including ngspice-30 ?
Hi Adam, would you mind creating a new package for macOS 5.1.2 stable replacing the outdated libngspice 26 by the recent libngspice version 30? And then use libngspice 30 also for the nightlies? Nick has done this successfully for Windows. All tests have been o.k.. The users may benefit from the ngspice patches since version 26 (see https://bugs.launchpad.net/kicad/+bug/1821520) towards better usage during pcb design. Regards Holger ___ 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
