Re: [Kicad-developers] 404 on docs.kicad-pcb.org/doxygen-python/

I can't see the pictures even on the non-proxied pages. It seems the build job for doxygen isn't uploading them? That's a thing for Nick. On Fri, Apr 5, 2019 at 9:51 PM Andrew Lutsenko wrote: > Thanks. When does it take effect? I'm still seeing 404. > Also some pictures are not visible in the

Re: [Kicad-developers] 404 on docs.kicad-pcb.org/doxygen-python/

Thanks. When does it take effect? I'm still seeing 404. Also some pictures are not visible in the docs url that your commit proxy-passes to, like the object inheritance graph here https://kicad-downloads.s3.cern.ch/doxygen-python/classpcbnew_1_1BOARD__ITEM.html On Fri, Apr 5, 2019 at 6:42 PM Mark

Re: [Kicad-developers] 404 on docs.kicad-pcb.org/doxygen-python/

Fixed https://github.com/KiCad/kicad-doc-website/commit/67d881642f96d587af3a8730dae54901238d5521 On Fri, Apr 5, 2019 at 6:36 PM Andrew Lutsenko wrote: > Hi all, > > I'm not sure if that is docs.kicad-pcb.org/doxygen-python/ the correct > link to python api docs but all google searches point

[Kicad-developers] 404 on docs.kicad-pcb.org/doxygen-python/

Hi all, I'm not sure if that is docs.kicad-pcb.org/doxygen-python/ the correct link to python api docs but all google searches point there and it's referenced here . If they moved somewhere else there should be a 301

Re: [Kicad-developers] Possible error in project loading

Hey Jeff, Oh my! This is embarrassing since git blamed me. That should indeed be ConfigSave(). It looks like a copy and past error on my part. Nice catch. Cheers, Wayne On 4/5/19 3:34 PM, Jeff Young wrote: > Hi Wayne, > > Could you take a look at lines 75:77 in prjconfig.cpp: > > // Save

[Kicad-developers] Possible error in project loading

Hi Wayne, Could you take a look at lines 75:77 in prjconfig.cpp: // Save the project file for the currently loaded project. if( m_active_project ) Prj().ConfigLoad( PgmTop().SysSearch(), GeneralGroupName, s_KicadManagerParams ); If the comment is correct that should be ConfigSave(), not

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

> On Apr 4, 2019, at 5:16 PM, Tomasz Wlostowski > wrote: > > Hi, > > We needed to do some signal/power integrity simulations on one of our > Kicad designs and in order to do that, we needed to convert a Kicad PCB > to Hyperlynx format. Luckily, the format is simple, all text and well >

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

Tom, On 4/5/19 12:41 PM, Wayne Stambaugh wrote: > On 4/5/19 12:24 PM, Tomasz Wlostowski wrote: >> On 05/04/2019 18:04, Wayne Stambaugh wrote: >>> Tom, >>> >>> On 4/4/19 8:16 PM, Tomasz Wlostowski wrote: Hi, We needed to do some signal/power integrity simulations on one of our

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

On 4/5/19 12:24 PM, Tomasz Wlostowski wrote: > On 05/04/2019 18:04, Wayne Stambaugh wrote: >> Tom, >> >> On 4/4/19 8:16 PM, Tomasz Wlostowski wrote: >>> Hi, >>> >>> We needed to do some signal/power integrity simulations on one of our >>> Kicad designs and in order to do that, we needed to convert

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

On 05/04/2019 18:04, Wayne Stambaugh wrote: > Tom, > > On 4/4/19 8:16 PM, Tomasz Wlostowski wrote: >> Hi, >> >> We needed to do some signal/power integrity simulations on one of our >> Kicad designs and in order to do that, we needed to convert a Kicad PCB >> to Hyperlynx format. Luckily, the

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

Tom, On 4/4/19 8:16 PM, Tomasz Wlostowski wrote: > Hi, > > We needed to do some signal/power integrity simulations on one of our > Kicad designs and in order to do that, we needed to convert a Kicad PCB > to Hyperlynx format. Luckily, the format is simple, all text and well > documented in [1],

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

Hi Tom, Ah right. I thought that was a unit test at first because it's under the "unit tests" section of the Cmake. I don't think it's useless to have it, as it provides an easy hook for quick testing. Clicking though the GUI is certainly painful! Since your test is actually a "utility tool"

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

On 05/04/2019 16:48, John Beard wrote: > Hi Tom, > > Can the hyperlink export test not exist in the existing qa_pcbnew > test? The code is all in pcbnew's library, so why not just mirror the > source layout and put your test as > "qa/pcbnew/exporters/test_export_hyperlynx.cpp"? > > Otherwise we

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

Hi Tom, Can the hyperlink export test not exist in the existing qa_pcbnew test? The code is all in pcbnew's library, so why not just mirror the source layout and put your test as "qa/pcbnew/exporters/test_export_hyperlynx.cpp"? Otherwise we will eventually have dozens and dozens of tiny unit

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

Tom, On 4/5/19 10:40 AM, Tomasz Wlostowski wrote: > On 05/04/2019 02:16, Tomasz Wlostowski wrote: >> Hi, >> >> We needed to do some signal/power integrity simulations on one of our >> Kicad designs and in order to do that, we needed to convert a Kicad PCB >> to Hyperlynx format. Luckily, the

Re: [Kicad-developers] [PATCH] [RFC] Exporter for Mentor Hyperlynx

On 05/04/2019 02:16, Tomasz Wlostowski wrote: > Hi, > > We needed to do some signal/power integrity simulations on one of our > Kicad designs and in order to do that, we needed to convert a Kicad PCB > to Hyperlynx format. Luckily, the format is simple, all text and well > documented in [1], so

Re: [Kicad-developers] "auto" policy

This all sounds good to me. I'm the author of that offending line and am happy to update my code accordingly. -Jon On Fri, Apr 5, 2019 at 8:58 AM Wayne Stambaugh wrote: > > On 4/5/19 6:39 AM, Jeff Young wrote: > > Do we have a policy on when to use auto? > > No but we should create one since

Re: [Kicad-developers] Auto zoom-to-fit and the symbol editor

This seems like a perfectly acceptable solution to me. You may also want to add this option to the symbol viewer as well. I'm sure someone will request that as well. On 4/5/19 9:08 AM, John Beard wrote: > Hi Jeff, > > I think the current default is somewhat reasonable. If editing a >

Re: [Kicad-developers] Auto zoom-to-fit and the symbol editor

Hi Jeff, I think the current default is somewhat reasonable. If editing a multi-unit part with substantially similar units, you are probably as likely to want to keep your current zoom as reset it. And zoom reset is a single keypress for when it isn't. As this is likely to be one of those things

Re: [Kicad-developers] "auto" policy

On 4/5/19 6:39 AM, Jeff Young wrote: > Do we have a policy on when to use auto? No but we should create one since I'm seeing it being used fairly often. > > Personally, I like it when it removes repetition.  For instance: > >     auto pin = new SCH_PIN();   I'm fine with this since the type

Re: [Kicad-developers] Merge schedule

Jeff, I can't think of any reason not to clean up the SCH_ and LIB_ Draw() routines unless I'm missing something. It might be useful to merge this to the 5.1 branch once it is proven to be stable. This will help keep merge conflicts to a minimum. Wayne On 4/5/19 6:09 AM, Jeff Young wrote: >

Re: [Kicad-developers] "auto" policy

Hi, I think auto is useful when it avoids repetition of useless things, and doubly so for things where the type is unwieldy, like iterators, and, particularly, lambdas. For example: auto up = std::make_unique( ... ); // or make_shared auto it = aVec.begin(); // or cbegin or returns from

[Kicad-developers] Auto zoom-to-fit and the symbol editor

When picking a new symbol we zoom-to-fit it. However, when picking a different unit of the symbol being edited we don’t. A user has complained about this[1]. However, it’s not clear to me on balance which would be better. If you had a large symbol and were zoomed in on a particular area and

Re: [Kicad-developers] "auto" policy

Le 05/04/2019 à 12:39, Jeff Young a écrit : > Do we have a policy on when to use auto? > > Personally, I like it when it removes repetition.  For instance: > >     auto pin = new SCH_PIN();   > > > And I like it when it removes stupid template things like std::pair<>: > >     for( auto it :

[Kicad-developers] "auto" policy

Do we have a policy on when to use auto? Personally, I like it when it removes repetition. For instance: auto pin = new SCH_PIN(); And I like it when it removes stupid template things like std::pair<>: for( auto it : my_unordered_map ) But I don’t like it in other cases. This

[Kicad-developers] Merge schedule

I’ve got a changelist which cleans up the various SCH_ and LIB_ Draw() routines to remove the interactivity features (since they’re now print-only). Should I merge it now? Cheers, Jeff. https://git.launchpad.net/~jeyjey/kicad/commit/?id=ef6b71b3335080a5e3c4cd98e70d42f2f8f1132f