Re: [Kicad-developers] Patch set: Display Origin Transforms rebase
Hi Reece- I've had a chance to test this a bit. It works really nicely. Thanks for the good idea here. I only noticed one spot where it wasn't transformed so far: the Measurement tool. When used, it displays a sign with the distance, which doesn't match the increasing/decreasing convention. The second part is mostly a question. Where do I set this in Eeschema and page layout? The setting is in the panel under pcbnew, so I would assume it is a per-application process. However, there is no other application that has that panel for setting. I don't have a strong opinion on whether this should be a KiCad-wide preference or not. I can't imagine someone wanting to set it one way in Eeschema and another in pcbnew. If that was your intention, the panel should be at the top level rather than under pcbnew. If it wasn't, can you give some more insight into why it would be good to split between the applications? Lastly, and this is a bit fundamental, I have reservations about passing this parameter around when it is not needed. This is more of a C-style convention. Where functions inherit the frame with the preference, that should be used by a Get() method rather than passing down in a parameter chain. In some cases (UNIT_HELPER), this should either be incorporated into UNIT_HELPER or written as a class that inherits UNIT_HELPER. The class then gets the current setting (as Unit helper does with the units) and applies it in one place only. The problem with the current solution is that it becomes very difficult to maintain as the parameter count increases. Overall, this is an excellent piece of work. I look forward to using it and flipping my perspective around. :) Best- Seth On 2019-05-25 09:08, Reece R. Pollack wrote: The Zip file attachment contains the complete set of patches implementing Display Origin Transforms, now squashed and rebased for your merging pleasure! They should apply cleanly atop this commit from JP Charras: b8e2054 Activate context menu in LIB_VIEW_FRAME canvas. Folks, please resist the urge to commit another 110 patches before Wayne has a chance to merge these onto master. :-) -Reece ___ 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
Hi, Am 24/05/2019 um 13:32 schrieb Wayne Stambaugh: Just as an FYI in case it wasn't obvious, Seth's proposal uses library IDs to define the symbol and footprint. Yes, so would mine, on any level that is more detailed than "footprint". The main problem I see with atomic libraries is that "fully defined" is not fully defined. Is it - symbol+footprint - symbol+footprint+3d - symbol+footprint+order no - symbol+footprint+3d+order no or any of these, and a SPICE model attached? That's why my proposal is to define a hierarchy based on a "non-atomic" workflow, starting with generic components and refining until you have an order number attached to the part as well, because that is still useful even if you prefer to define everything at once: you just use the "fully defined" parts then and filter out the generic and partially defined ones during selection. Workflow for part creation would be 1. define the symbol: - draw one, *or* - select an existing one, *or* - go with "generic box with pin definitions" During this step, pin numbers are optional, but you can already enter them if you want. 2. attach a SPICE model, or skip this step 3. define the package - draw one, *or* - select an existing one The pin mappings from step one are then transferred to this layer. 4. optionally, attach a 3D model 5. optionally, attach a manufacturer part number 6. optionally, attach a distributor part number Each of these steps generates a new symbol internally, and if you are in "atomic library" mode, hides the previous one in the selection dialog. This becomes useful already when you define your second diode: even if you defined a 0603 1N4001 part complete with DK order number first, you have a standalone diode symbol now that you can reuse, and if you do, swapping out parts in the schematic becomes easier: - we can add a "exchange part with ->" context menu with other diodes that use the same symbol - any other diode will be properly connected without adjusting any wires, because the pins are in the same place, and anode and cathode have the same pin names. If you don't like atomic libraries, or you're just doing a quick drawing that should never go into production, you can use "incomplete" definitions in the schematic as well, by deactivating the "atomic library" filter. The idea is to make the "atomic libraries [y/n]" decision a pure UI thing, so a single library can work for either workflow, and both camps can contribute to the shipped kicad library. This means that in order for the atomic libraries as proposed to be portable, the symbol, footprint, and 3D model would have to be available on the host machine. Otherwise, any missing symbol, footprint, and/or 3D model would break the library. The hierarchical model could degrade somewhat gracefully here, by storing references to all layers: the schematic would say symbol: generic:diode value_symbol: diode:1N4001 (inherits generic:diode, adds SPICE) footprint: diode:1N4001_0603 (inherits diode:1N4001, adds FP/3D) mfgno: 12345 (inherits diode:1N4001_0603, adds part number) orderno: 67890 (inherits 12345, adds order number) each of these fields would be a library reference, and import would just initially go with the most specific one it can find locally: 1. does the local library have a symbol "67890"? 2. does the local library have a symbol "12345"? 3. does the local library have a symbol "diode:1N4001_0603"? etc., so if you are missing the manufacturer and distributor levels, you at least get the symbol, SPICE, footprint and 3D model, and if you derived your own manufacturer and distributor levels from the generic ones, a "refine part selection" context menu could immediately provide them for you. - US vs EU vs GOST symbols, can we somehow make them use the same pin positions and different graphics, so these become interchangeable? This technically isn't atomic but could be supported with the new file format. True, that's why I put them under "random thoughts". It'd be nice if we could somehow teach KiCad that different graphical symbols can mean the same thing. - multi-unit components, can we somehow make them inherit the generic symbol multiple times and thus allow unit mapping without changing the schematic (i.e. gate swapping)? I'm not sure what you mean here. Doesn't changing a symbol gate change the schematic? The symbol will have to be a complete symbol not just one of the sub-units. I don't see how it's possible to associate a footprint to a single gate of component. Sorry, that was unclear, it should have been "without having to adjust wires in the schematic". Swapping a part with one that uses the exact same graphical symbol can be done without risking connectivity, so it becomes possible to quickly exchange unit A for unit B, or switch from a two-unit to a four-unit package, and we could even offer that from within
Re: [Kicad-developers] Release Checklist
Great idea! I have a lightweight test procedure for macOS packaging of major releases here, under Test Procedure: https://github.com/KiCad/kicad-mac-builder/blob/master/README.md On Sat, May 25, 2019 at 11:27 AM Seth Hillbrand wrote: > > Hi Devs- > > I've committed a proposed checklist format to my branch[1] on launchpad. > This is the outline of a proposed checklist for KiCad releases that we > can use to verify consistent (i.e. fewer regressions) behavior before > tagging new versions. This currently documents just the main window. > If people like the idea, I'll work on expanding the list to cover the > full suite. > > The proposed release workflow would then look like: > 1) Wayne tags an RC and copies the current template into a new file > called release_checklist_v#.#RC# > 2) Everyone begins testing the items on the list, marking them as > working or reporting/fixing bugs >a. All tests happen against the tag. If a test fails, it can be > marked **fixed** after a fix is committed > 3) Once all tests are marked either **complete** or **fixed**, and no > new issues arise, we start again with a fresh RC > 4) Once an RC has all tests marked **complete** instead of **fixed**, we > are ready for release. > > Let me know if people have suggestions for how this process might be > improved/modified. > > Best- > Seth > > > [1] > https://git.launchpad.net/~sethh/kicad/commit/?id=8c2d0b6957d4b1da47741947850a959602564ba4=3=0=1 > > ___ > 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
[Kicad-developers] Release Checklist
Hi Devs- I've committed a proposed checklist format to my branch[1] on launchpad. This is the outline of a proposed checklist for KiCad releases that we can use to verify consistent (i.e. fewer regressions) behavior before tagging new versions. This currently documents just the main window. If people like the idea, I'll work on expanding the list to cover the full suite. The proposed release workflow would then look like: 1) Wayne tags an RC and copies the current template into a new file called release_checklist_v#.#RC# 2) Everyone begins testing the items on the list, marking them as working or reporting/fixing bugs a. All tests happen against the tag. If a test fails, it can be marked **fixed** after a fix is committed 3) Once all tests are marked either **complete** or **fixed**, and no new issues arise, we start again with a fresh RC 4) Once an RC has all tests marked **complete** instead of **fixed**, we are ready for release. Let me know if people have suggestions for how this process might be improved/modified. Best- Seth [1] https://git.launchpad.net/~sethh/kicad/commit/?id=8c2d0b6957d4b1da47741947850a959602564ba4=3=0=1 ___ 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] Patch set: Display Origin Transforms rebase
The Zip file attachment contains the complete set of patches implementing Display Origin Transforms, now squashed and rebased for your merging pleasure! They should apply cleanly atop this commit from JP Charras: b8e2054 Activate context menu in LIB_VIEW_FRAME canvas. Folks, please resist the urge to commit another 110 patches before Wayne has a chance to merge these onto master. :-) -Reece <> ___ 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's way of drawing filled zones
Le 19/05/2019 à 21:28, jp charras a écrit : > Le 18/05/2019 à 14:13, Tomasz Wlostowski a écrit : >> On 13/05/2019 12:58, jp charras wrote: >>> If we are talking about V6.0 version, we should add zone property field >>> in the file format like (outline_thickness 0.0) to avoid serious issues >>> (generating broken boards for fabrication). >>> >> >> Hi JP, >> >> Are you going to work on this (commit code)? >> Hi Tom, Are you working on that? If not, now Seth committed the last code about zones, I can finalize my work on zone filled areas without thickness outlines. (This is not a lot of changes) Thanks. -- 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
