[Kicad-developers] Footprint display origin development

Hey folks! I'm starting work on extending display origin transforms to the footprint editor.  It appears this is entirely a matter of adding it to the preferences, as the FP editor shares the rest of the code with Pcbnew. Question 1: What's the likelihood of this feature being added to a

Re: [Kicad-developers] Warning about potentially malicious software

And Kicad.info On 10/19/21 4:44 PM, Nick Østergaard wrote: Wouldn't be appropriate to add the post as this to the blog on kicad.org as well? On Tue, 19 Oct 2021 at 22:30, Seth Hillbrand > wrote: Hi Folks- As you know, the original KiCad

Re: [Kicad-developers] IBIS / SPICE simulation

I started down the path of creating an IBIS-to-Spice converter a couple of years ago. I researched it enough to decide it was feasible, then discovered a commercial product demo that would do enough of what I needed at the time and stopped working on it. I'd just about forgotten about it

Re: [Kicad-developers] ngspice library version

It doesn't matter what file name is used for the .so when linking an application. The SONAME of the library is embedded in the library file itself, and is extracted from the library when the application is linked. Does the Fedora package that provides libngspice create the appropriate symlink

Re: [Kicad-developers] ngspice library version

Typically the way this is handled is that the application is linked against a symlink to the library that references the library's SONAME rather than the full name of the library. In the runtime system, a symlink with this name points at the correct file. To check the SONAME in the library,

Re: [Kicad-developers] Origin Transforms for the Footprint Editor

are deeper into the freeze than I would like to be and still have outstanding features to commit. Cheers, Wayne On 12/30/20 11:53 PM, Reece R. Pollack wrote: I finally have some time to work on adding origin transforms to the footprint editor. I have a couple of questions: 1) Is the Developers

[Kicad-developers] Origin Transforms for the Footprint Editor

I finally have some time to work on adding origin transforms to the footprint editor. I have a couple of questions: 1) Is the Developers mailing list still working? I haven't gotten anything since Dec 26th. 2) Is the v6.0 release past string freeze, or should I push to get this done

Re: [Kicad-developers] Display origin transforms for DRC reports?

It sounds like the consensus approach is to add a second parameter to the GetSelectMenuText() function, which will be a pointer or reference to an ORIGIN_TRANSFORMS object. Those implementations of this function that format coordinates will use this to display the coordinates relative to the

Re: [Kicad-developers] Display origin transforms for DRC reports?

ing in an EDA_DRAW_FRAME or by just passing in the ORIGIN_TRANSFORMS or whatever) -Jon On Fri, Jul 10, 2020 at 2:29 PM Reece R. Pollack wrote: Jon, The alternate origins themselves (Place & Drill / Aux origin, and Grid origin) in Pcbnew are stored in the BOARD_DESIGN_SETTINGS class and saved in the boa

Re: [Kicad-developers] Display origin transforms for DRC reports?

schematic file (which should be independent of the EDA_BASE_FRAME) -Jon On Fri, Jul 10, 2020 at 1:18 PM Reece R. Pollack wrote: Jeff, Thanks for the follow-up. I'm finding some of the GetSelectMenuText() implementations format coordinate addresses for display. That means they need to use

Re: [Kicad-developers] Display origin transforms for DRC reports?

, at 00:51, Reece R. Pollack wrote: On 7/9/20 7:09 PM, Tomasz Wlostowski wrote: On 10/07/2020 00:58, Reece R. Pollack wrote: I'm looking at display origin transformations for DRC reports. With the 5.1.x branch Pcbnew, the DRC report dialog box message texts contained the Cartesian coordinates

Re: [Kicad-developers] Display origin transforms for DRC reports?

On 7/9/20 7:09 PM, Tomasz Wlostowski wrote: On 10/07/2020 00:58, Reece R. Pollack wrote: I'm looking at display origin transformations for DRC reports. With the 5.1.x branch Pcbnew, the DRC report dialog box message texts contained the Cartesian coordinates of each flagged item. It appears

[Kicad-developers] Display origin transforms for DRC reports?

I'm looking at display origin transformations for DRC reports. With the 5.1.x branch Pcbnew, the DRC report dialog box message texts contained the Cartesian coordinates of each flagged item. It appears that the 5.99 branch no longer displays the coordinates of DRC items. However, the

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

mark it as WIP by putting "WIP: " in the beginning of the title. Doing so will allow people to review it more easily (even if it's not done) Thanks, Jon On Mon, Jul 6, 2020 at 12:21 PM Reece R. Pollack wrote: On 7/3/20 9:22 PM, Seth Hillbrand wrote: Hi Reece- I think I ment

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

On 7/3/20 9:22 PM, Seth Hillbrand wrote: Hi Reece- I think I mentioned back then that I'm happy to help with the implementation.  The offer remains if you are interested. It is easy enough to overload with a pure virtual function in the base class.  The derived classes can override (not

Re: [Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

On 7/3/20 5:42 PM, Jeff Young wrote: Hi Reece, On 3 Jul 2020, at 21:32, Reece R. Pollack <mailto:re...@his.com>> wrote: Noting that the PCB_BASE_FRAME class is derived from the EDA_DRAW_FRAME class, is it acceptable to assume that the EDA_DRAW_FRAME pointer parameters passed to

[Kicad-developers] Derived class naming questions

Here's a coding standards question: Let's say I create a PCB-specific class derived from UNIT_BINDER. Should it be called PCB_UNIT_BINDER or UNIT_BINDER_PCB? -Reece ___ Mailing list: https://launchpad.net/~kicad-developers Post to :

[Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

Noting that the PCB_BASE_FRAME class is derived from the EDA_DRAW_FRAME class, is it acceptable to assume that the EDA_DRAW_FRAME pointer parameters passed to functions in Pcbnew classes are actually pointers to a PCB_BASE_FRAME? Specifically: * The UNIT_BINDER class constructor * The

Re: [Kicad-developers] [PATCH 2/2] Remove questionable useless casts

On 9/6/19 6:36 PM, Simon Richter wrote: -const float posYfactor = (float)(windowsPos.y + y * 4.0f) / (float)m_windowSize.y; +const float posYfactor = windowsPos.y + y * 4.0f / (float)m_windowSize.y; These are mathematically different expressions. You

Re: [Kicad-developers] Strange program version numbering in KiCad

On 7/8/19 10:36 PM, Kevin Cozens wrote: On 2019-07-08 5:10 p.m., Dino Ghilardi wrote: think about the linux kernel versioning number scheme: even subversion number means stable release. Odd subversion number means experimental/development branch. The kernel used to follow the odd/even

Re: [Kicad-developers] VECTOR2I and VECTOR2D

On 6/22/19 10:52 AM, Seth Hillbrand wrote: On 2019-06-21 22:54, Reece R. Pollack wrote: Doing this now, before we go too far down the path of replacing wxWidgets types with non-OOB arrays would enhance readability and make the code more robust. Using VECTOR2I is going the wrong way. Hi Reece

Re: [Kicad-developers] VECTOR2I and VECTOR2D

On 6/22/19 3:09 AM, Greg Smith wrote: Adding two points and dividing by two results in a point that is minimally equidistant from both points (I.e. The midpoint of the line formed by the points). While it is true that you can add two point coordinates and multiply by scalar 0.5 to get the

Re: [Kicad-developers] VECTOR2I and VECTOR2D

The evolution from untyped variables to weakly-typed variables to strongly-typed variables to OOP techniques has never been about what is easiest for the programmer nor fastest running. It's about producing correct, reliable, maintainable software. The argument that "it'll be too slow" is

Re: [Kicad-developers] VECTOR2I and VECTOR2D

ir of values should be considered a bug. On 6/21/19 10:54 PM, Reece R. Pollack wrote: A while back, Jeff emailed me a note suggesting that KiCad was trying to decouple from the wxWidgets type wxPoint except where needed in the UI code. He suggested that I should use VECTOR2I instead. I understand an

[Kicad-developers] VECTOR2I and VECTOR2D

A while back, Jeff emailed me a note suggesting that KiCad was trying to decouple from the wxWidgets type wxPoint except where needed in the UI code. He suggested that I should use VECTOR2I instead. I understand and support the desire to decouple from wxWidgets. However, looking at the

Re: [Kicad-developers] CMake minimum version

On 6/14/19 2:27 PM, Seth Hillbrand wrote: On 2019-06-14 14:12, jp charras wrote: Le 14/06/2019 à 19:49, Jon Evans a écrit : +1 Speaking of that page on the website, I think we can remove Ubuntu 16.04 and 17.10 from the table now that they are unsupported. Be careful: Ubuntu 16.04 LTS is

Re: [Kicad-developers] Kicad gestures

middle-drag to pan).  Maybe someone needs to do the legwork to see which actually is the most common re. left-right vs. up-down. -Jon On Wed, Jun 12, 2019 at 11:28 AM Reece R. Pollack <mailto:re...@his.com>> wrote: Most applications I've used provide these "gestures"

Re: [Kicad-developers] Kicad gestures

On 6/12/19 11:29 AM, John Beard wrote: On 12/06/2019 15:33, Jeff Young wrote: I’m putting the kicad gestures into the List HotKeys dialog. Excellent! Pan Up/Down             shift-mouse-wheel Pan Left/Right          ctrl-mouse-wheel Do we need also zoom? Yes, we need zoom as a

Re: [Kicad-developers] Kicad gestures

Most applications I've used provide these "gestures" with the mouse wheel: Pan up/down: no modifier Zoom in/out: Control Pan left/right: Shift With KiCad I am forever zooming when I want to pan up or down. If we're going to retain the current behavior of zooming with no modifier, at least

Re: [Kicad-developers] Patch set: Display Origin Transforms rebase

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

Re: [Kicad-developers] Patch set: Display Origin Transforms rebase

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

[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

[Kicad-developers] Patch set: Display Origin Transforms updates

I've attached a Zip file containing additional patches to be applied on top of the previous set. The first three patch files address Wayne's code review comments. If anyone else had comments I didn't see them. The fourth patch file provides support for Bezier control points. A big "thank

[Kicad-developers] Patch set: Display Origin Transforms

I've attached a Zip file containing 11 patches. These implement the Origin Transforms feature I've been talking about since KiCon. They should apply cleanly to the master branch at this commit (currently HEAD): 9d56102 Prevent unannotated components from driving connectivity In summary,

Re: [Kicad-developers] A consistent name for the Aux Origin?

Once you establish a base coordinate origin, you really don't want that moving. All the mechanical holes, notches, connectors, switches, clearances, and other locations are measured from that origin. Moving during layout risks placing a component in the wrong spot. The movable grid origin is

Re: [Kicad-developers] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

You might want to take a look at how Xilinx ISE and similar products handle this. Their tools take in Verilog or VHDL and can produce a graphical representation of the resulting logic. It's not as readable as a hand-drawn schematic but it exists and enough people find it useful that Xilinx

Re: [Kicad-developers] Pcbnew display origin transforms for v6

John, I've already jumped to clang-format 6.0, which is one of the optional installs for Mint 18. That works, once you get all the symlinks fixed, except it keeps wanting to reformat my switch statements like this, which is contrary to the KiCad coding standards: @@ -148,15 +130,9 @@ int

Re: [Kicad-developers] eemodern branch

I got a bunch of those last night on a build based on the then-current eemodern branch, all or most related to duplicate hotkey definitions. I've pasted the console log from that below. Note that I opened both a schematic AND a board developed using v5, and obviously some of this spew is from

[Kicad-developers] Bug #1773638: The origins of 6.0 (pun intended)

oordinates to the user? There's a list in the commit log. 6. Should this be extended to the footprint editor? Eeschema? Anywhere else? Thanks for the help, folks! -Reece >From 4c9c94a1364397809741590eb952a1f79aac944b Mon Sep 17 00:00:00 2001 From: "Reece R. Pollack" Date: Fri

[Kicad-developers] Question on commit e6a200b "Pcbnew: avoid integer overflow when displaying local coordinates"

I have a question on this commit: commit e6a200b09e9a38baac4bde53b68d3def6d2d350c Author: jean-pierre charras Date: Thu Feb 14 10:55:57 2019 +0100 Pcbnew: avoid integer overflow when displaying local coordinates. Minor cleanup in code. This commit changes the calculations of relative

Re: [Kicad-developers] Pcbnew display origin transforms for v6

/md_Documentation_development_coding-style-policy.html [2]: http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html#tools On 4/30/19 9:50 PM, Reece R. Pollack wrote: Inspired by KiCon (and before the high wears off) I'm moving forward with my project to allow the user

[Kicad-developers] Pcbnew display origin transforms for v6

Inspired by KiCon (and before the high wears off) I'm moving forward with my project to allow the user to specify the coordinate display origin in pcbnew. I have this working as patches to the v5.1.2 branch, but they're hard-coded to use the Aux origin. I'd like some guidance on how best to

Re: [Kicad-developers] Is errno defined on MSW?

In any Posix-compliant implementation, errno has been thread-safe for decades without any need for special versions of fopen or other stdio library functions. Of course, if we're talking about Microsloth, who can tell. On 08/13/18 23:54, Mark Roszko wrote: Yes, errno and fopen behave the

Re: [Kicad-developers] Error importing the wxPython API!

Logging out and back in didn't clear the problem. Nor did deleting the ~/.cache/kicad directory and contents. A full system reboot seems to have fixed it. Not sure why that would do it though. On 06/06/18 23:26, Reece R. Pollack wrote: Hey folks, I've run into an odd problem that I could

[Kicad-developers] Error importing the wxPython API!

Hey folks, I've run into an odd problem that I could use some help fixing. I needed to help test Orson's possible fixes to a critical bug, which we were expecting to result in a Git bisect. I cloned my usual development repo into a new tree and checked out the "master" branch to avoid any

Re: [Kicad-developers] More default fields in schematic

certainly had that bug, but I’m pretty sure it’s been fixed. Cheers, Jeff. On 29 May 2018, at 13:54, Reece R. Pollack <mailto:re...@his.com>> wrote: On 05/29/18 08:27, Jeff Young wrote: Comments inline: On 28 May 2018, at 17:28, Reece R. Pollack <mailto:re...@his.com>> wrot

Re: [Kicad-developers] More default fields in schematic

I believe you owe me 2c. We can discuss 2c in which currency later. :-) I have five custom default fields defined:  - Mfgr  - Mfgr P/N  - Dist  - Dist P/N  - Specifications The first two give the manufacturer's name and part number; the second two give the distributor's name and part number;

Re: [Kicad-developers] Why do component location values not respect the grid origin?

I have some crude patches that changes this to be relative to the manufacturing ("aux") origin. That's the "private branch" all my bug reports refer to. It works in all situations I've tried, but I haven't tried more exotic configurations like polar coordinates. My intent is to have this

[Kicad-developers] A reminder on Git commit comments

I'd like to make an observation on some of the Git commit comments I'm reading. Some of these commit log entries are really unhelpful. When I was at University many, many years ago, students were taught to place comments in their code. Many misunderstood the purpose of comments, though, and

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

: Hi Reece, Have a look at an earlier message regarding bus upgrades [1]. Cheers, Orson 1. https://lists.launchpad.net/kicad-developers/msg32423.html On 04/20/2018 05:15 PM, Reece R. Pollack wrote: Let's not forget the pending wishlist item Bug #1419146 <https://bugs.launchpad.net/kicad/+

Re: [Kicad-developers] [RFC] Remove bus joining behavior from KiCad after 5.0 release

Let's not forget the pending wishlist item Bug #1419146 to support buses of named members. You shouldn't have to remember that I2C_DATA is better known as I2C_0 and I2C_CLOCK is I2C_1. Or was I2C_CLOCK = I2C_0 and I2C_DATA = I2C_1? Extending

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

On 04/12/18 11:38, Nick Østergaard wrote: Den tor. 12. apr. 2018 17.18 skrev Reece R. Pollack <re...@his.com <mailto:re...@his.com>>: On 04/12/18 09:58, Carsten Schoenert wrote: Hi, Am 12.04.2018 um 15:47 schrieb Reece R. Pollack: I'm a relative newbie to KiC

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

On 04/12/18 09:58, Carsten Schoenert wrote: Hi, Am 12.04.2018 um 15:47 schrieb Reece R. Pollack: I'm a relative newbie to KiCad, but I've been a software engineer since the early 1980. I'd prefer to see KiCad installed in a self-contained manner, meaning all installed files end up under one

Re: [Kicad-developers] [RFC] Able to install KiCad stable and "daily build" in same computer

I'm a relative newbie to KiCad, but I've been a software engineer since the early 1980. I'd prefer to see KiCad installed in a self-contained manner, meaning all installed files end up under one directory hierarchy rather than being spread all over the filesystem. This is how Xilinx ISE,

Re: [Kicad-developers] Assertion failure in the Symbol Library Editor

I probably should have filed this as a bug report. I'll go do that On 04/07/18 22:39, Reece R. Pollack wrote: I wanted to create a symbol for the Diodes Inc DMN3300U transistor in my private library name "MyParts". Here's what I did: 1. I attempted to follow the in

[Kicad-developers] Assertion failure in the Symbol Library Editor

I wanted to create a symbol for the Diodes Inc DMN3300U transistor in my private library name "MyParts". Here's what I did: 1. I attempted to follow the instructions in the eeschema documentation section 11.4.1 to transfer the 2N7002 part from the Transistor_FET library to MyParts,

Re: [Kicad-developers] Fixing libcommon

On 03/19/17 16:23, Maciej Suminski wrote: On 03/19/2017 01:03 AM, Reece R. Pollack wrote: [snip] I want to accomplish two goals: 1. Allow the user to set the origin from which the location of all objects is measured. Right now this is the upper left corner of whatever Paper size

Re: [Kicad-developers] Fixing libcommon

On 03/18/17 10:18, Maciej Suminski wrote: In order to remove the hardcoded values from WORKSHEET_VIEWITEM, I started moving code that used to be compiled multiple times to separate units. This is also a basic way to solve the internal units conversion problem. There are still a few more files