Re: [Kicad-developers] STEP export
https://gitlab.com/kicad/code/kicad/issues/3695 *Drew Van Zandt* On Thu, Dec 19, 2019 at 10:26 AM Drew Van Zandt wrote: > Y'all, >Who would I talk to about this? I am seeing a bug, but it is so > confusing I am not entirely sure how to report it - I could use help in the > form of questions from someone with more STEP knowledge than I have. I > also can't put sample files on the public wiki, but would be open to > sharing them with an individual with the understanding that they stay > nonpublic. > > It seems like when I update this particular PCB model, some of the update > comes through in the STEP file, and some things don't get changed. One of > the files I have still has a "ghost" PCB outline from the project I copied > it from, before days of modifications. > (5.1.4)-1. > > I will submit it as a bug with as much info as I can. > > > *Drew Van Zandt* > ___ 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] STEP export
Y'all, Who would I talk to about this? I am seeing a bug, but it is so confusing I am not entirely sure how to report it - I could use help in the form of questions from someone with more STEP knowledge than I have. I also can't put sample files on the public wiki, but would be open to sharing them with an individual with the understanding that they stay nonpublic. It seems like when I update this particular PCB model, some of the update comes through in the STEP file, and some things don't get changed. One of the files I have still has a "ghost" PCB outline from the project I copied it from, before days of modifications. (5.1.4)-1. I will submit it as a bug with as much info as I can. *Drew Van Zandt* ___ 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] KiCad joins the Linux Foundation
Adding clicks reduces the chance you'll get a donation. On Fri, Nov 22, 2019, 5:31 PM Wayne Stambaugh wrote: > On 11/22/19 3:23 PM, Nick Østergaard wrote: > > On Fri, 22 Nov 2019 at 18:03, Wayne Stambaugh > wrote: > >> > >> I just pushed a blog post to the KiCad website that KiCad has joined the > >> Linux Foundation so consider this the official announcement. The > >> project did this to give donors a choice of how they want to donate to > >> KiCad and it gives us some more flexibility on how we can spend donation > >> money. This does not in any way change our relationship with CERN and > >> you can continue to donate via CERN if that is your preference. You > >> should be seeing announcements from the Linux Foundation shortly. > >> > >> I need to add a "Donate via Linux Foundation" button to the KiCad > >> website main page. If someone would please point me to the correct > >> place in the website source where I need to do this, I would appreciate > >> it. If you would rather do it yourself, the KiCad LF donation link is > >> https://funding.communitybridge.org/projects/kicad. > >> > >> Who has the account login information for the KiCad Facebook page? I > >> didn't create this so it would be nice if I had edit access so I could > >> post announcements there instead of asking someone else to do it. > >> > > > > I have admin access on it, but I think you got it as well from the > > original creator (Sujith Anandan) of it. I don't really maintain it, > > facebook is not really my thing. > > It's not my thing either but I thought I would add the announcement > there. I don't recall ever getting admin access. I did get the twitter > admin login information. Do you have Sujith's email address so that I > can ping him? > > > > >> I hope joining the Linux Foundation will improve our potential donor > >> visibility so we can continue to grow the KiCad project. Thank you all > >> for your continued support. > >> > >> 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 > > ___ > 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] Fwd: eeschema selection appearance
Ruth, brilliant! This behavior in commercial apps has irritated me for decades. *Drew Van Zandt* On Wed, Nov 20, 2019 at 12:29 PM Ian McInerney wrote: > (Ruth, I think you meant to send this to the entire list). > > -- Forwarded message - > From: Ruth Ivimey-Cook > Date: Wed, Nov 20, 2019 at 5:23 PM > Subject: Re: [Kicad-developers] eeschema selection appearance > To: > > > This looks like an improvement on v5.1, anyway. Thanks! > > A side request if you're looking at the selection code: I would really > appreciate it if selections were included in the history buffer and could > be added-to and subtracted-from incrementally. It would make working with > selections much easier! > > A related thing - if you make a selection and then try to perform an > action on it, and then cancel the action (e.g. because a dialog appeared > warning you of some condition), it is frustrating that the selection is > cancelled. > > Regards > > Ruth > > > On 20/11/2019 14:28, Ian McInerney wrote: > > I'm on the fence about the text highlighting, on the one hand not doing it > does make it so the text is still easily legible when selected, but on the > other it can be nice to show that it is part of the selected symbol. I > think this would definitely be a case where making it a configurable option > would allow people to experiment and see what they prefer. > > -Ian > > On Wed, Nov 20, 2019 at 2:18 PM Seth Hillbrand wrote: > >> On 2019-11-20 05:48, Jonatan Liljedahl wrote: >> > Hi, >> > >> > I'm tweaking the appearance of the new selection, what do you think? >> > Except a change of color, transparency and width, it also skips >> > drawing the fields and pin labels of components. I think it gives a >> > much cleaner look with less clutter. >> >> This will always be a matter of opinion. Right now the color is >> configurable. If you'd like to add additional configurable parameters >> to the selection, you should place them in the Eeschema preferences and >> allow the user to choose them. Then post the patch for review. >> >> Otherwise, we'll end up bike shedding on this which would be nice to >> avoid. >> >> Best- >> Seth >> >> >> Seth Hillbrand >> KiCad Services Corporation >> https://www.kipro-pcb.com >> +1 530 302 5483 | +1 212 603 9372 >> >> ___ >> 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 > ___ 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 lead developer announcement
Congrats Ian! *Drew Van Zandt* On Thu, Nov 7, 2019 at 3:31 PM Sylwester Kocjan wrote: > On 07/11/2019 21:14, Wayne Stambaugh wrote: > > Ian's contributions have > > earned him this privilege and we are grateful for his efforts. > > Congratulations :) > > Cheers, > Sylwester > > ___ > 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] Benchmarking kicad compilation on CPUs released 6 years apart
Let me encourage some of y'all to stick with an older machine, or keep it around for testing... the latest build of KiCAD is noticeably laggy on my machine, which is not terribly fast (but also not that old). It makes some of the bugs I have reported worse, and their fixes have been pushed out to 6.x (for perfectly good reasons). I am a bit manic, though, as Jon can attest; patience is last on my list of accessible virtues. *Drew Van Zandt* On Tue, Oct 29, 2019 at 10:40 AM Simon Richter wrote: > Hi, > > On Mon, Oct 28, 2019 at 10:20:45PM -0700, Andrew Lutsenko wrote: > > > I kinda expected 2x maybe 3x decrease because not all computations scale > > linearly with number of threads. I was pleasantly surprised by almost 6x > > decrease in clean build time and 5x in incremental builds. > > FWIW, we have a number of bottlenecks in the build process: > > - dependency generation of common doesn't start until the version header >is generated, which only happens after bitmaps and gal are complete > - dependency generation of pcbnew_kiface doesn't start until the python >wrapper is generated, which takes ages itself. > - the python wrapper is compiled as one of the last things, and the linker >must wait for that. > > We could probably shave off another two or three minutes of build time if > we could make sure that we always make progress on the critical path. The > dependency generation as a side effect pulls all the sources and headers > into cache, which reduces the effects of I/O latency a bit during > compilation, so parallelizing with more than the number of threads you > actually have is probably counterproductive. > > Numbers with CPU time as percent of real time: > > clean ~15 ~5 tip > E5-2620v4 (32) 7:04.87 5:18.74 5:16.64 3:40.92 > 2243% 1854% 1854% 1330% > T2P9D01 (64)5:16.37 4:14.04 4:10.26 3:20.97 > 3360% 2558% 2570% 1546% > >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 > ___ 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] Atomic Libraries Proposal
The benefit is that once you have verified a triplet works on a board, you can use it again without fear of error. The current system is not ideal for re-use/production engineering. On Thu, May 23, 2019, 4:06 PM Rene Pöschl wrote: > Hi Seth > > What is the benefit compared to having lets say a more powerful aliasing > system that allows bom specific things to be more easily included in the > kicad internal library without introducing something different? > (especially as i assume the new file format will provide a more powerful > option in this regard anyways.) > > On 23/05/19 21:41, Seth Hillbrand wrote: > > Hi All- > > > > After some discussion, we are trying to decide whether implementing a > > basic atomic library support would be useful during v6 or would cause > > more headache than worth while trying to work with the solution. > > > > Background: "Atomic" libraries are ones that have unique names for > > symbol+footprint+properties combinations. These are also referred to as > > "Fully-specified" libraries or sometimes "house libraries". > > > > The paradigm is outlined in a google document[1]. This is meant to > > provide an explicit option for users to create/utilize atomic library > > components without affecting the symbol or footprint formats. It is > > also meant to be zero impact to the current, official KiCad libraries. > > > > The major limitations of the specification are: > > - No editing of the atomic library file within KiCad > > - The atomic library does not contain symbol or footprint data > > > > Folks are welcomed to weigh in on whether this approach presents a > > viable work flow for them. I'm happy to take suggestions on the > > approach, I may ask you offline for some additional details of how you > > use KiCad and/or other tools with libraries at the moment. > > > > Best- > > Seth > > > > > > [1] > > > https://docs.google.com/document/d/1FNPmUAkNVt7r9oz32OznDrqL8RHdGHpO-eiBVEzHCOs/edit?usp=sharing > > > > ___ > > 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] HotKey user model
On this general topic, is there a technical reason that one cannot assign a
shortcut key for "select whole net"?
*Drew Van Zandt*
On Fri, Apr 26, 2019 at 2:13 PM jp charras wrote:
> Le 26/04/2019 à 19:21, Jeff Young a écrit :
> > I’ve been talking to Wayne about the ‘W’ and ‘X’ hotkeys. It appears
> the design goal is to have these be immediate actions (that is, they start
> a wire or a track, rather than just selecting the wire or track tool).
> >
> > Presumably this would then also apply to ‘A’, ‘P’, ‘L’, ‘H’, ‘J’, ‘Q’,
> etc. (None of these perform an immediate action today, right?)
>
> In short: Yes. This is how the hotkeys worked, previously.
> >
> > Do we want there to be some related way to select the tools? That is,
> if ‘Q’ places a no-connect then shift-Q would select the no-connect tool?
> If yes, would these be separately editable, or would they simply follow
> whatever the user changed the main hotkeys to?
> >
> > Or is there some other facility that’s already supposed to work for
> tools?
>
> Why do you want to change the previous behavior? Is it not good?
>
> The reason of the behavior ('W' starts a wire and 'shift W' selects the
> tool) is the fact we cannot (if we use the hotkey as accelerator) know
> if a menu was clicked (in this case the mouse position is irrelevant) or
> if a hotkey was pressed (in this case the mouse position can be used and
> we start a wire immediately).
> Therefore we cannot use the same key as hotkey and accelerator key.
>
> It is extremely hard to fix this issue because the workaround to fix it
> are only workaround (and therefore can stop working after wxWidgets
> changes) and each platform has its own workaround.
>
> For instance, if the 'W' key is used both as accelerator key and hotkey,
> the key event is not generated on Windows (only the menu event), but is
> generated on wxGTK.
> I don't know what happens on OSX.
>
> Hotkey behavior versus accelerator key behavior is always strange.
> And this is not only when using wxWidgets:
> I found issues in many other applications (Using a French keyboard
> instead of a US keyboard often shows these strange behaviors)
>
> Trying to fix this issue is a mined field.
>
> Wayne and me spent a lot of time about that without success.
>
>
> --
> 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
>
___
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] timestamp_t bit width
MSVC 2010 includes it. https://stackoverflow.com/questions/126279/c99-stdint-h-header-and-ms-visual-studio *Drew Van Zandt* On Mon, Mar 25, 2019 at 5:25 PM Wayne Stambaugh wrote: > I don't know if it's still true but msvc didn't include stdint.h so > making this policy would have left msvc users without a solution. This > may no longer be true and I seem to remember that someone was providing > an implementation of stdint.h for msvc. If this is no longer the case, > then it could be added to the coding policy. > > On 3/25/19 3:02 PM, Jon Evans wrote: > > Any reason not to just make a policy moving forward to define anything > > related to file formats using stdint types so that there are no > > architecture variations possible? > > > > On Mon, Mar 25, 2019 at 2:59 PM Jeff Young > <mailto:j...@rokeby.ie>> wrote: > > > > Hi JP, > > > > I’m afraid I just move the decl (and its comment) from another > > file. It appears the author > > was Henner Zeller in 3f57fa5d2443a085c9fa243c615d71dc470a0107. > > > > Commit comment was: > > > > Change time_t in the functions that deal with timestamps to a > new > > typedef timestamp_t (defined as a long). > > that makes sure the c++ side and swigged Python side agree on > the > > type, because time_t create problems in Python scripts. > > > > Cheers, > > Jeff. > > > > > >> On 25 Mar 2019, at 15:51, jp charras >> <mailto:jp.char...@wanadoo.fr>> wrote: > >> > >> Le 25/03/2019 à 16:22, Wayne Stambaugh a écrit : > >>> On 3/24/2019 2:34 PM, Seth Hillbrand wrote: > >>>> Am 2019-03-24 13:23, schrieb Jon Evans: > >>>>> Hi all, > >>>>> > >>>>> Another question from this forum thread: > >>>>> > https://forum.kicad.info/t/before-giving-up-on-kicad-one-last-attempt-erc-misery/15933/67 > >>>>> > >>>>> > >>>>> timestamp_t is defined as "long", with a note that swig can't > >>>>> handle > >>>>> int32_t. > >>>> > >>>> I don't understand this comment. SWIG includes stdint.i which > >>>> explicitly defines the exact integral types. Maybe Jeff can > >>>> shed some > >>>> light here? > >>>> > >>>> > >>>>> This means that timestamp_t will be 32-bit on many platforms, but > >>>>> 64-bit on Linux and MacOS running on 64-bit hardware. Apparently > >>>>> there is at least one bug here involving the Eagle importer > writing > >>>>> out library files with 64-bit timestamps, which 32-bit KiCad > cannot > >>>>> open. > >>>> > >>>> This is a problem in ParseHex(). If it gets a hex value that > >>>> overflows, > >>>> it throws an error, stopping the processing. So this isn't > >>>> specific to > >>>> the Eagle plugin but rather a 32-bit/64-bit issue. We allow > >>>> 64-bit to > >>>> be written to file but only generate a time_t (32-bit) value for > >>>> new, > >>>> internal stamps. > >>>> > >>>> The Eagle processor creates its own "timestamp" by hash which is > >>>> 64 bits > >>>> on a 64 bit machine. > >>> > >>> Do you mean our Eagle plugins are not truncating 64 bit time > >>> stamps in > >>> Eagle files? If so, the problem needs to be fixed here. AFAIK, > >>> KiCad > >>> has always used 32 bit time stamps. > >> > >> The issue is the fact the legacy plugin currently uses a long as > time > >> stamp, but do not truncate if to 32 bits when writing a .sch file. > >> So because Eagle importer generate a long value, the legacy plugin > >> writes 8 hexa chars on 32 bits platform, but can write more than 8 > >> chars > >> on 64 bits platforms > >> > >>> > >>>> > >>>>> Q1: Is there actually a bug here? maybe someone more familiar > >>>>> with the > >>>>> Eagle importer can take a look. > >>>> > >>>> Yes. Definitely
