[Kicad-developers] Footprint display origin development

[Reece R. Pollack]

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 
post-6.0 release prior to the 7.0 release?


I plan to create the new FP editor preferences panel from a copy of the 
existing Pcbnew panel. I see a fair number of minor changes in the 
Pcbnew origin preferences panel support code on the master branch after 
the 6.0 tag. If there's a chance of this feature being added to a 6.x 
release I'd rather develop based on the 6.0 code base rather than 
chasing master, then port to 6.99 later.



Question 2: Does anyone see value in supporting a display origin other 
than the "Coordinate origin point (anchor) of the footprint"?


Pcbnew supports display origins of page, aux, and grid. Grid origin was 
my first experiment with Pcbnew years ago, but I found the aux origin 
more useful. I debated dropping the grid origin option from Pcbnew when 
I submitted patches for 6.0, but it was trivial to support so I left it in.


Since the footprint editor uses the Pcbnew transformation code already 
in place, grid origin support in the FP editor merely requires allowing 
the user to select it in the preferences. The FP editor doesn't support 
an aux origin, so dropping grid origin means there won't be an "Display 
origin" selection option at all, only axis directions.


Thoughts on this?


Happy New Year!
-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] Warning about potentially malicious software

[Reece R. Pollack]

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 domain name (kicad-pcb.org
) was recently sold.  This happened without
notification to the KiCad Project or members of the KiCad
Development Team. This sale was unexpected and may pose a risk to
KiCad users. The new owners may simply post advertisements or
(worst-case scenario) they may host malicious versions of the
KiCad software for download.

# How did this happen?

The domain name was originally registered in 2012 by the then
project lead Dick Hollenbeck. As KiCad did not have a formal
entity at the time, he registered it in his own name through his
company SoftPLC. When the KiCad Project formally became registered
under the Linux Foundation, we attempted to secure the rights to
the original domain name from Dick without success.

In the meantime, Digikey Corporation purchased the kicad.org
 domain name from squatters and donated it to
the KiCad Project.  This is now our current domain name.

# What is the KiCad Project doing now to protect its users?

We are removing all links to the old domain name in the software
for version 5.1.11 as well as 6.0. We are also contacting various
sites that host content related to KiCad to update their links.

# What can I do?

Please do not contact Dick about this. He cannot undo the damage
at this point.

If you host KiCad videos on YouTube or content on a blog that has
links to kicad-pcb.org , please update them
to kicad.org  as soon as possible. This will
decrease the visibility of the old domain-name and limit the
damage. You can also contact tech sites that post reviews of KiCad
or otherwise have links to the old site and ask them to update
their links.

When installing KiCad, please always verify the installation
signature. Starting with KiCad version 5.99, all installs are
signed by KiCad Services Corporation.

# What is KiCad doing to prevent this in the future?

The current kicad.org  domain name is not under
control of a single person. We have built in safeguards to our
transfer process. Additionally, all KiCad trademarks are
registered to the Linux Foundation for the sole purpose of
advancing open-source EDA software.

We regret that this was done to the KiCad project and its users.

-- 
KiCad Services Corporation Logo

Seth Hillbrand
*Lead Developer*
+1-530-302-5483‬
Long Beach, CA
www.kipro-pcb.com  i...@kipro-pcb.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



___
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] IBIS / SPICE simulation

[Reece R. Pollack]

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 until you mentioned it.

-Reece

On 8/30/21 12:34 PM, Fabien Corona wrote:

Hello everyone,

I am working on an IBIS parser for kicad integration.
IBIS is a standard format to I/O buffers, that allows for "fast" and 
accurate signal integrity simulations.
While parsing the IBIS format is not so hard, well... I have data to 
simulate, but no simulator...


I was wondering if anybody in this mailing list had knowledge about 
IBIS and / or SPICE simulation ?
From the info I gathered, it is quite "easy" to convert to convert to 
a SPICE model, but maybe there are better ways to do.

( If we could avoid a whole simulator from scratch, that would be nice )


Basically, an IBIS file is :
- R L C parameters,
- voltage vs current tables
- voltage vs time tables

Regards,

Fabien Corona


___
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] ngspice library version

[Reece R. Pollack]

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 "libngspice.so.0" to the actual image file "libngspice.so.0.0.1"?


What does ldd show on the failing systems (not your system)? The string 
to the right of the "=>" is the name of the file that satisfies the 
requirement /on that system/ and is determined by ldd at the time ldd is 
run. If this shows "not found", then there is a libngspice configuration 
problem on that system.


My guess is that the symlinks are installed as part of the development 
package for libngspice and not as part of the base package that provides 
the library itself. This is a common packaging error.


-Reece

On 8/23/21 11:06 AM, Steven A. Falco wrote:
I've done a bit of digging.  According to ldd, the desired version is 
appropriate, just specifying the first digit of the version info:


libngspice.so.0 => /lib64/libngspice.so.0 (0x7f70913de000)

However, according to eeschema_kiface.dir/build.make we have 
-DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" as shown in this excerpt:


cd /builddir/build/BUILD/kicad-5.1.10/x86_64-redhat-linux-gnu/eeschema 
&& /usr/bin/g++ $(CXX_DEFINES) 
-DNGSPICE_DLL_FILE=\"libngspice.so.0.0.1\" $(CXX_INCLUDES) 
$(CXX_FLAGS) -MD -MT 
eeschema/CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -MF 
CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o.d -o 
CMakeFiles/eeschema_kiface.dir/sim/ngspice.cpp.o -c 
/builddir/build/BUILD/kicad-5.1.10/eeschema/sim/ngspice.cpp


Since eeschema/sim/ngspice.cpp explicitly uses the NGSPICE_DLL_FILE 
variable to load the DLL, that is apparently why the more general ldd 
version is not used.


eeschema/sim/ngspice.cpp:    m_dll.Load( NGSPICE_DLL_FILE );

So it seems the fix would be to truncate NGSPICE_DLL_FILE to remove 
the MAJOR.MINOR component and just have 
-DNGSPICE_DLL_FILE=\"libngspice.so.0\"


Steve

On 8/23/21 10:29 AM, Steven A. Falco wrote:
I just got a bug report for the official Fedora version of KiCAD 
stating that ngspice was not found.  An attempt to perform a 
simulation results in KiCAD crashing.


The Fedora KiCAD package specifies libngspice.so.0.0.0, but the 
library has now bumped to libngspice.so.0.0.1.  I would have expected 
that to be fine, because the new library should be compatible.  But 
apparently, the loader is looking for an exact match, and refuses to 
use the newer library.


For now, I'm rebuilding the official package to match the new ngspice 
library, but I'm wondering if there is a way to improve this 
situation, such that KiCAD links with libngspice.0 rather than 
insisting on an exact match of the minor number.


 Steve



___
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] ngspice library version

[Reece R. Pollack]

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, use this incantation:

   objdump -p //path/to/library/ |grep SONAME

I run Kubuntu rather than Fedora, so I don't know the SONAME of Fedora's 
libngspice. On Kubuntu 20.04, I get this:


   $ objdump -p /usr/lib/x86_64-linux-gnu/libngspice.so.0.0.0 |grep SONAME
  SONAME   libngspice.so.0

On the build system, I have these files:

   libngspice.so -> libngspice.so.0.0.0
   libngspice.so.0 -> libngspice.so.0.0.0
   libngspice.so.0.0.0

The application developer typically links against libngspice.so rather 
than libngspice.so.0.0.0 to avoid having to know which library version 
is installed. At build time the linker will pick up the SONAME embedded 
in this .so file.


At runtime the loader will use the SONAME to find the library. You can 
use "ldd" to see what libraries the built application is linked against. 
The part to the left of the "=>" is the SONAME, and the part to the 
right is the name of the file that will be used on /this/ system.


Here's a link to the Debian policy on shared libraries for a detailed 
explanation of how this works:

https://www.debian.org/doc/debian-policy/ch-sharedlibs.html


On 8/23/21 10:29 AM, Steven A. Falco wrote:
I just got a bug report for the official Fedora version of KiCAD 
stating that ngspice was not found.  An attempt to perform a 
simulation results in KiCAD crashing.


The Fedora KiCAD package specifies libngspice.so.0.0.0, but the 
library has now bumped to libngspice.so.0.0.1.  I would have expected 
that to be fine, because the new library should be compatible.  But 
apparently, the loader is looking for an exact match, and refuses to 
use the newer library.


For now, I'm rebuilding the official package to match the new ngspice 
library, but I'm wondering if there is a way to improve this 
situation, such that KiCAD links with libngspice.0 rather than 
insisting on an exact match of the minor number.


Steve

___
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] Origin Transforms for the Footprint Editor

[Reece R. Pollack]

Wayne,

No worries on timing. We'll queue it up for 6.99 after the 6.0 release.

-Reece

On 12/31/20 2:47 PM, Wayne Stambaugh wrote:

Hi Reece,

We are officially in feature freeze so this is going to have to wait
until V7.  I would rather not add another exception to the freeze list
as we 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 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 quickly? It looks like all that's lacking is the preference settings.

3) I'm thinking the preference settings dialog panel will give the
choice of measuring from the "Anchor" or the "Grid" origins, as the
concept of an "Aux" origin doesn't make sense here. Does it even make
sense to offer a choice of display origins here?

-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



___
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] Origin Transforms for the Footprint Editor

[Reece R. Pollack]

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 quickly? It looks like all that's lacking is the preference settings.


3) I'm thinking the preference settings dialog panel will give the 
choice of measuring from the "Anchor" or the "Grid" origins, as the 
concept of an "Aux" origin doesn't make sense here. Does it even make 
sense to offer a choice of display origins here?


-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] Display origin transforms for DRC reports?

[Reece R. Pollack]

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 user-selected origin.


I propose that if it is desired to move the user origin and in/mm 
selection from the user display options to the project be deferred to a 
separate patch set so this can be discussed independently.


Does this sound right to everyone?

-Reece

On 7/10/20 4:56 PM, Ian McInerney wrote:
I view the package of information need as the arguments to the 
function. If information isn't needed, then it shouldn't be passed in. 
Creating a new wrapper type that just holds the EDA_UNITS and the 
ORIGIN_TRANSFORMS object seems like an extra level of abstraction that 
is not needed. The point of my original question about the IU is that 
if the transform operates on the IU, then these two items are probably 
not needed together anywhere else. Adding a struct solely to hold 
these two datatypes will add code/understanding overhead to the 
functions and its callsite, specifically:
* Having to create the actual struct and populate it's fields before 
calling the function
* In the function the struct has to be unpacked/continually referenced 
(so the variable names become longer)
* It hides the fact that we are passing these two items (one of which 
is already an opaque type) inside another opaque type when someone 
just views the prototype for the function


To me, it seems like there is not enough here to justify the creation 
of a new layer of abstraction to pass these two items into this 
function. If these two datatypes are needed in other places at the 
same time, then I could see the justification.


-Ian




___
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] Display origin transforms for DRC reports?

[Reece R. Pollack]

The units selection and the origin transforms are both available through 
the EDA_DRAW_FRAME. I haven't looked at every call in detail (there are 
a combined 118 calls and function declarations), but it appears that 
when the caller has access to an EDA_DRAW_FRAME then the call is some 
variant of:


 GetSelectMenuText( m_editFrame->GetUserUnits() );

Where there isn't access to an EDA_DRAW_FRAME, it's coded as:

 GetSelectMenuText( EDA_UNITS::MILLIMETRES );

It seems to me that if we're going to change the parameters to this 
function, we should pass a pointer to an EDA_DRAW_FRAME as a single 
parameter. If this parameter is nullptr, then we assume 
EDA_UNITS::MILLIMETRES and null transforms, otherwise we use the getter 
functions in EDA_DRAW_FRAME to get the correct object or data.


I'd need to see more than a few nodding heads before I made either of 
these changes.


-Reece

On 7/10/20 3:00 PM, Jeff Young wrote:

I agree on both points: units and transform should be saved in the project 
file, and they should be passed to GetSelectMenuText as parameters.

Cheers,
Jeff.



On 10 Jul 2020, at 19:35, Jon Evans  wrote:

OK, I see.

I have mostly stayed out of this conversation before so I will
probably step back, but I would suggest that I think that display
units and origin choice should be a project-level setting, not
system-level.

Probably it makes sense to change GetSelectMenuText so that it has
this context available somehow (whether by passing 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 board file. Of course, the Page origin location doesn't
need to be stored; it's always (0,0).

My initial thought last year was to store the user's choice of display
origin in the board file, but after some discussion we reached consensus
that the choice of display origin was more like millimeters/inches and
thus should be a user option rather than a board property. In the
proposed implementation, the user's preference for which origin is used
for display is stored in the PCB_DISPLAY_OPTIONS class and saved in the
pcbnew.json file. I think a case could be made that this should be saved
per-project, but no one has made a good argument for that.


The primary user of the display origin transforms is the UNIT_BINDER
class. This class has a pointer to the EDA_DRAW_FRAME object.  Since
UNIT_BINDER is common, I added a virtual function
"GetOriginTransforms()" to the EDA_DRAW_FRAME class. This function
returns a reference to an ORIGIN_TRANSFORMS class. The base
implementation of the ORIGIN_TRANSFORMS class contains functions that
return their coordinate arguments unchanged. This way none of the KiCad
applications see a change in behavior unless they override the
GetOriginTransforms() function.

In the case of Pcbnew, the EDA_DRAW_FRAME parameter is actually a
pointer to a PCB_BASE_FRAME object. In this class, the
GetOriginTransforms() function is overridden and returns a reference to
a PCB_ORIGIN_TRANSFORMS object. This object's functions know how to
access the BOARD_DESIGN_SETTINGS and PCB_DISPLAY_OPTIONS objects through
the PCB_BASE_FRAME object and perform the needed transformations.

This works for everything that can find the EDA_DRAW_FRAME object, like
UNIT_BINDER. The GetMsgPanelInfo functions take an EDA_DRAW_FRAME
pointer as a parameter, so this isn't a problem. However, the
GetSelectMenuText() functions take only an EDA_UNITS parameter. Thus my
problem.

-Reece

On 7/10/20 1:25 PM, Jon Evans wrote:

Shouldn't the origin be stored in the design data (BOARD / SCHEMATIC)
rather than the base frame?

It seems like all data about objects, including their coordinates in
the coordinate space defined by the user, should be available just by
parsing a board or 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 display
origin transforms so the displayed coordinate matches what the user sees
on the status line and elsewhere. However, there does not appear to be a
path from these functions to the EDA_BASE_FRAME class where these
transforms are currently available.

Might someone more familiar with the data structures and calling
sequences could suggest how this can best be accomplished?

Seth, I'd appreciate it if you could bring your knowledge and expertise
to bear.

-Reece

On 7/10/20 6:35 AM, Jeff Young wrote:

No, the DRC re-write won’t affect GetSelectMenuText().  It originated for 
describing items in the Clarify Selection menu, but it’s now used whenever we 
want to describe an item to the user.

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

[Reece R. Pollack]

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 board file. Of course, the Page origin location doesn't 
need to be stored; it's always (0,0).


My initial thought last year was to store the user's choice of display 
origin in the board file, but after some discussion we reached consensus 
that the choice of display origin was more like millimeters/inches and 
thus should be a user option rather than a board property. In the 
proposed implementation, the user's preference for which origin is used 
for display is stored in the PCB_DISPLAY_OPTIONS class and saved in the 
pcbnew.json file. I think a case could be made that this should be saved 
per-project, but no one has made a good argument for that.



The primary user of the display origin transforms is the UNIT_BINDER 
class. This class has a pointer to the EDA_DRAW_FRAME object.  Since 
UNIT_BINDER is common, I added a virtual function 
"GetOriginTransforms()" to the EDA_DRAW_FRAME class. This function 
returns a reference to an ORIGIN_TRANSFORMS class. The base 
implementation of the ORIGIN_TRANSFORMS class contains functions that 
return their coordinate arguments unchanged. This way none of the KiCad 
applications see a change in behavior unless they override the 
GetOriginTransforms() function.


In the case of Pcbnew, the EDA_DRAW_FRAME parameter is actually a 
pointer to a PCB_BASE_FRAME object. In this class, the 
GetOriginTransforms() function is overridden and returns a reference to 
a PCB_ORIGIN_TRANSFORMS object. This object's functions know how to 
access the BOARD_DESIGN_SETTINGS and PCB_DISPLAY_OPTIONS objects through 
the PCB_BASE_FRAME object and perform the needed transformations.


This works for everything that can find the EDA_DRAW_FRAME object, like 
UNIT_BINDER. The GetMsgPanelInfo functions take an EDA_DRAW_FRAME 
pointer as a parameter, so this isn't a problem. However, the 
GetSelectMenuText() functions take only an EDA_UNITS parameter. Thus my 
problem.


-Reece

On 7/10/20 1:25 PM, Jon Evans wrote:

Shouldn't the origin be stored in the design data (BOARD / SCHEMATIC)
rather than the base frame?

It seems like all data about objects, including their coordinates in
the coordinate space defined by the user, should be available just by
parsing a board or 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 display
origin transforms so the displayed coordinate matches what the user sees
on the status line and elsewhere. However, there does not appear to be a
path from these functions to the EDA_BASE_FRAME class where these
transforms are currently available.

Might someone more familiar with the data structures and calling
sequences could suggest how this can best be accomplished?

Seth, I'd appreciate it if you could bring your knowledge and expertise
to bear.

-Reece

On 7/10/20 6:35 AM, Jeff Young wrote:

No, the DRC re-write won’t affect GetSelectMenuText().  It originated for 
describing items in the Clarify Selection menu, but it’s now used whenever we 
want to describe an item to the user.


On 10 Jul 2020, 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 of each flagged item. It appears
that the 5.99 branch no longer displays the coordinates of DRC items.
However, the Cartesian coordinates are still listed in the report file.
Unlike the display in a dialog box, this report is persistent and could
be passed to someone using different display origin settings.

   1. Should these coordinates be reported relative to the page origin, or
  transformed per the user-selected origin and axis directions?
   2. If the coordinates are transformed, should the report include the
  user settings?

-Reece


Reece,

I wouldn't introduce any changes to the current DRC code, we're
designing a new DRC engine for KiCad V6 and many things in DRC interface
will likely change.

IMHO the DRC coordinate transform belongs to the UI, not the DRC itself:
- the DRC engine generates an internal report with coordinates in board
coordinate space
- whatever displays the report to the user (i.e. the DRC dialog)
converts the board coordinates to UI coordinates.

- my 5 cents
Tom



Tom,

I'm not hard to convince, especially when it means doing less work.

This sounds like the RC_ITEM::ShowCoord function will be removed or replaced. 
It's one of the two troublesome function groups.

The other troublesome function group is the GetSelectMenuText 

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

[Reece R. Pollack]

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 display 
origin transforms so the displayed coordinate matches what the user sees 
on the status line and elsewhere. However, there does not appear to be a 
path from these functions to the EDA_BASE_FRAME class where these 
transforms are currently available.


Might someone more familiar with the data structures and calling 
sequences could suggest how this can best be accomplished?


Seth, I'd appreciate it if you could bring your knowledge and expertise 
to bear.


-Reece

On 7/10/20 6:35 AM, Jeff Young wrote:

No, the DRC re-write won’t affect GetSelectMenuText().  It originated for 
describing items in the Clarify Selection menu, but it’s now used whenever we 
want to describe an item to the user.


On 10 Jul 2020, 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 of each flagged item. It appears
that the 5.99 branch no longer displays the coordinates of DRC items.
However, the Cartesian coordinates are still listed in the report file.
Unlike the display in a dialog box, this report is persistent and could
be passed to someone using different display origin settings.

  1. Should these coordinates be reported relative to the page origin, or
 transformed per the user-selected origin and axis directions?
  2. If the coordinates are transformed, should the report include the
 user settings?

-Reece


Reece,

I wouldn't introduce any changes to the current DRC code, we're
designing a new DRC engine for KiCad V6 and many things in DRC interface
will likely change.

IMHO the DRC coordinate transform belongs to the UI, not the DRC itself:
- the DRC engine generates an internal report with coordinates in board
coordinate space
- whatever displays the report to the user (i.e. the DRC dialog)
converts the board coordinates to UI coordinates.

- my 5 cents
Tom



Tom,

I'm not hard to convince, especially when it means doing less work.

This sounds like the RC_ITEM::ShowCoord function will be removed or replaced. 
It's one of the two troublesome function groups.

The other troublesome function group is the GetSelectMenuText function. Last 
year I knew what they did but I've forgotten in the interim. Will this DRC 
rewrite replace these?

-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] Display origin transforms for DRC reports?

[Reece R. Pollack]

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
that the 5.99 branch no longer displays the coordinates of DRC items.
However, the Cartesian coordinates are still listed in the report file.
Unlike the display in a dialog box, this report is persistent and could
be passed to someone using different display origin settings.

  1. Should these coordinates be reported relative to the page origin, or
 transformed per the user-selected origin and axis directions?
  2. If the coordinates are transformed, should the report include the
 user settings?

-Reece


Reece,

I wouldn't introduce any changes to the current DRC code, we're
designing a new DRC engine for KiCad V6 and many things in DRC interface
will likely change.

IMHO the DRC coordinate transform belongs to the UI, not the DRC itself:
- the DRC engine generates an internal report with coordinates in board
coordinate space
- whatever displays the report to the user (i.e. the DRC dialog)
converts the board coordinates to UI coordinates.

- my 5 cents
Tom



Tom,

I'm not hard to convince, especially when it means doing less work.

This sounds like the RC_ITEM::ShowCoord function will be removed or 
replaced. It's one of the two troublesome function groups.


The other troublesome function group is the GetSelectMenuText function. 
Last year I knew what they did but I've forgotten in the interim. Will 
this DRC rewrite replace these?


-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

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

[Reece R. Pollack]

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 Cartesian coordinates are still listed in the report file. 
Unlike the display in a dialog box, this report is persistent and could 
be passed to someone using different display origin settings.


1. Should these coordinates be reported relative to the page origin, or
   transformed per the user-selected origin and axis directions?
2. If the coordinates are transformed, should the report include the
   user settings?

-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] Assumptions about EDA_DRAW_FRAME in pcbnew

[Reece R. Pollack]

Jon,

I'm very familiar with Git, but a total novice with GitLab. Is there a 
cheat-sheet somewhere that describes the process for requesting merges 
and such to KiCad's code base?


-Reece

On 7/6/20 12:24 PM, Jon Evans wrote:

Hi Reece,

Could you open a merge request for this branch?  You can 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 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 overload) the virtual
functions that apply to each.  So pcbnew gets one viable function
signature and eeschema gets the other.  Misusing this gets an error in
compiling, which keeps errors from creeping down to the user.

One aspect of dynamic_cast that is sometimes overlooked is that casts
to the base class are optimized out by the compiler.  I think that
might save your implementation (if I understand your intention correctly)

Best-
Seth


Hi Seth,

I think it'd be great if you'd participate in the discussions of this
feature. As far as I'm concerned, the more input I get the better.

Last year I tried posting patches periodically for people to comment on
as my development progressed but I didn't get a lot of response. This
time I've created a GitLab repo which might make it easier for folk to
see what I'm doing in context:

https://gitlab.com/RRPollack/kicad/-/tree/rrp-5.99-origin-transform

Note that this is a rewrite -- not a port -- of last year's work, though
the user interface is intended to be the same. I've pushed the first
phase of changes, which implement the Pcbnew status line and the dialogs
that use the UNIT_BINDER class. It all compiles cleanly. The parts I've
tested work fine but I have to remember how to get to some of the
dialogs. The code needs some clean-up, especially in the Doxygen
support, and there's some development spew to the console so I can
verify the conversions taking place are appropriate.

Conspicuously missing is the settings panel that allows easy
configuration; I just haven't gotten to it yet. To change to use the Aux
origin and flip the Y axis (my normal configuration) add these lines to
the pcbnew.json "pcb_display" section:

  "origin_invert_x_axis": false,
  "origin_invert_y_axis": true,
  "origin_mode": 1,

Also missing is support for GetMsgPanelInfo, GetSelectMenuText, and DRC
markers. All in good time!

It'd be nice to get some feedback before I get too far down the road.

-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] Assumptions about EDA_DRAW_FRAME in pcbnew

[Reece R. Pollack]

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 overload) the virtual 
functions that apply to each.  So pcbnew gets one viable function 
signature and eeschema gets the other.  Misusing this gets an error in 
compiling, which keeps errors from creeping down to the user.


One aspect of dynamic_cast that is sometimes overlooked is that casts 
to the base class are optimized out by the compiler.  I think that 
might save your implementation (if I understand your intention correctly)


Best-
Seth



Hi Seth,

I think it'd be great if you'd participate in the discussions of this 
feature. As far as I'm concerned, the more input I get the better.


Last year I tried posting patches periodically for people to comment on 
as my development progressed but I didn't get a lot of response. This 
time I've created a GitLab repo which might make it easier for folk to 
see what I'm doing in context:


https://gitlab.com/RRPollack/kicad/-/tree/rrp-5.99-origin-transform

Note that this is a rewrite -- not a port -- of last year's work, though 
the user interface is intended to be the same. I've pushed the first 
phase of changes, which implement the Pcbnew status line and the dialogs 
that use the UNIT_BINDER class. It all compiles cleanly. The parts I've 
tested work fine but I have to remember how to get to some of the 
dialogs. The code needs some clean-up, especially in the Doxygen 
support, and there's some development spew to the console so I can 
verify the conversions taking place are appropriate.


Conspicuously missing is the settings panel that allows easy 
configuration; I just haven't gotten to it yet. To change to use the Aux 
origin and flip the Y axis (my normal configuration) add these lines to 
the pcbnew.json "pcb_display" section:


    "origin_invert_x_axis": false,
    "origin_invert_y_axis": true,
    "origin_mode": 1,

Also missing is support for GetMsgPanelInfo, GetSelectMenuText, and DRC 
markers. All in good time!


It'd be nice to get some feedback before I get too far down the road.

-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] Assumptions about EDA_DRAW_FRAME in pcbnew

[Reece R. Pollack]

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 functions in Pcbnew 
classes are actually pointers to a PCB_BASE_FRAME?


Yes, but it would be considered bad practice.


I would argue that it could easily be defined that code in the pcbnew 
directory is dealing with a PCB_BASE_FRAME rather than an 
EDA_DRAW_FRAME. Common code should not make that assumption, of course, 
and would not use anything beyond the base class.




Specifically:

  * The UNIT_BINDER class constructor
  * The classes implementing the GetMsgPanelInfo function
  * The classes implementing the GetSelectMenuText function

The reason I'm asking is that to implement origin transforms these 
functions need access to the user's display option that chooses the 
display origin. This needs access to a function defined in the 
PCB_BASE_FRAME class. I can make that a common function defined in 
EDU_DRAW_FRAME and overridden in PCB_BASE_FRAME, or the code needs to 
know that parameter is really a pointer to a PCB_BASE_FRAME object.


Ask yourself this: is there anything PCB-specific about a settable 
origin?  Is there any reason a settable origin wouldn’t also be 
useful, say, a schematic?  If the answer is “no”, then you should push 
the origin (along with its getters and setters) down in to EDA_DRAW_FRAME.


My submission last year was intended to allow any or all of the KiCad 
subsystems (eeschema, pcbnew, gerbview, etc.) make use of origin 
transforms. Gerbview could benefit, because if you set the place and 
drill origin to the lower left of you design when you generate Gerbers, 
Gerbview displays the page border below the displayed board. I'd thought 
about how to do this in eeschema, considering an origin at any of the 
four corners or at the aux origin (which is defined in eeschema but is 
not settable). But I did a full implementation on pcbnew because that 
was what I felt really needed it.That  implementation added a parameter 
to the functions I mentioned above, which resulted in the eeschema 
functions also having that parameter even though they didn't use it.


When Wayne sent out his last call for comments before he merged the 
changes, Seth complained that since I didn't implement support in 
eeschema then these changes should not affect any code in the eeschema 
directory. His suggestion was to use function overloading, but that 
would result in having two interfaces visible in the both eeschema and 
pcbnew, one that worked in that context and one that didn't. You 
wouldn't know that the code called the wrong function until you noticed 
broken behavior. I don't consider that an acceptable situation just to 
avoid a trivial parameter list change.


My approach this year is that code in the pcbnew directory knows it's 
dealing with a PCB_BASE_FRAME because it's PCB-specific code in the 
first place. Then it's easy to access the PCB-specific interfaces and 
data. Rather than changing the UNIT_BINDER class I've implemented a 
PCB_UNIT_BINDER class derived from UNIT_BINDER. It knows that it's 
getting a PCB_BASE_FRAME rather than an EDA_DRAW_FRAME, and passes that 
to the base class constructor. It's more tricky with the functions that 
are called indirectly through the EDA_DRAW_FRAME, such as 
GetMsgPanelInfo and GetSelectMenuText. The implementations are specific 
to pcbnew and live in the pcbnew directory.


I can do it with dynamic casts, but I'm an embedded systems guy and I 
hate to waste CPU cycles checking things that are defined to be true. 
And dynamic_cast is slow: my tests of the Icarus Verilog simulator 
appear to show VVP spends about 20% of its CPU cycles just resolving 
dynamic casts.


If this really is PCB-specific, then you can either push just the 
origin getters/setters down into EDA_DRAW_FRAME and override them in 
PCB_BASE_FRAME, or do a dynamic_cast to PCB_BASE_FRAME and if non-null 
call the getters/setters.


I believe there will need to be subsystem-specific implementations of 
portions of the origin transform code, based on what display options we 
offer to the user. However, I think a lot of the interfaces can be 
common. I'm willing to do either a PCB-only version or one that has 
support for pcbnew and latent support for the other subsystems. What I'm 
not willing to do is invest a lot of effort, only for someone to veto it 
at the last minute over a stylistic difference of opinion again. We, 
meaning myself and the core developers collectively, need to come to a 
consensus on how this should be implemented.


-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

[Kicad-developers] Derived class naming questions

[Reece R. Pollack]

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@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Assumptions about EDA_DRAW_FRAME in pcbnew

[Reece R. Pollack]

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 classes implementing the GetMsgPanelInfo function
 * The classes implementing the GetSelectMenuText function

The reason I'm asking is that to implement origin transforms these 
functions need access to the user's display option that chooses the 
display origin. This needs access to a function defined in the 
PCB_BASE_FRAME class. I can make that a common function defined in 
EDU_DRAW_FRAME and overridden in PCB_BASE_FRAME, or the code needs to 
know that parameter is really a pointer to a PCB_BASE_FRAME object.


If the functions defined in PCB-specific classes are defined to be 
getting pointers to PCB_BASE_FRAME classes, I can just change the 
parameter type and avoid the need to play games with dynamic casts.


Thanks!

-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] [PATCH 2/2] Remove questionable useless casts

[Reece R. Pollack]

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 need to restore the 
parenthesis around the numerator expression even if you remove the cast.


I would further argue that in many cases removing the cast is less clear 
than explicitly indicating how you want the expression interpreted, even 
if the expressions were the same.


-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] Strange program version numbering in KiCad

[Reece R. Pollack]

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 numbering scheme but they 
stopped doing that during the 2 series of kernels. It is possible they 
are doing it again. I haven't looked at kernel release numbering in 
quite a few years.


No. That was abandoned years ago, after the release of 2.6, in favor of 
a stream of smaller, incremental steps rather than periodic huge jumps 
that took years to be adopted. The 3.0 release could easily have been 
numbered 2.6.40, being only an incremental change over 2.6.39.


-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] VECTOR2I and VECTOR2D

[Reece R. Pollack]

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-

Codebase cleaning like you suggest can go a long way toward improving 
sustainability and readability.  But done the wrong way, it will have 
the opposite effect as we fight with return types that aren't fully 
matched.


Before we decide to do this type of deep plumbing on the KiCad 
innards, I'd love to see the proposed specification for what's being 
implemented.  Otherwise, this'll be a bike shedding discussion.


I've been in far too many "code reviews" where the focus became the 
naming of variables and not on the algorithm being implemented. So I 
agree with your comment in principle.


That said, the lack of type specificity already makes portions of our 
code hard to maintain. The DIALOG_GRAPHIC_ITEM_PROPERTIES class already 
reuses the m_endX UNIT_BINDER to represent both the X-axis endpoint of 
an object and the radius of a circle. This requires special handling 
when performing display origin transforms because the X-axis endpoint 
requires origin transformation while the circle radius does not. This 
illustrates the risk of treating everything as "just a pair of numbers" 
because it's "easy".


I'm not suggesting rushing into a major change. But replacing a 
descriptive object like wxPoint with a non-descriptive object like 
VECTOR2I isn't an improvement. Especially when its implementation is 
somewhat non-intuitive, as Hauptmech points out.


-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] VECTOR2I and VECTOR2D

[Reece R. Pollack]

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 midpoint, this is not true in the general case for 
arbitrary scalar multipliers. However, calculating the vector distance 
between two points, multiplying the vector by a scalar, then adding the 
resulting vector distance to the first point /does/ work in the general 
case.


This is exactly the sort of bug that can be avoided by not allowing 
arbitrary operations on random vectors.


If finding the midpoint between two points proves to be a common 
operation, and is found to be too costly to implement in the general 
fashion, then a special method for determining the midpoint can be 
provided that calculates it in the optimal fashion.


___
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] VECTOR2I and VECTOR2D

[Reece R. Pollack]

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 almost never true and then almost always easily addressed.


On 6/22/19 3:09 AM, Greg Smith wrote:
In addition, treating points as vectors make a variety of required 
transformations much easier. Wrapping the two numbers in an object 
that disallows common transformations, calculations, and combinations 
seems unnecessary and will result in significantly slower code.



___
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] VECTOR2I and VECTOR2D

[Reece R. Pollack]

Whoops, hit "send" too soon. "Is a simple array" is obviously incorrect. 
My point was the lack of descriptiveness is a problem. The absence of 
differentiation between a location and a distance is a missed 
opportunity. And the abuse of the type as a loosely-related pair 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 and support the desire to decouple from wxWidgets. 
However, looking at the implementation of vector2d.h I was surprised 
to discover that VECTOR2I is a simple array of /int/ like I would find 
in an old Fortran program. It's not even a C structure, let alone a 
well-defined C++ object.


One of the goals of object-oriented programming is to create 
descriptive objects. Programmers can tell what an object represents by 
looking at the name and implementation of the object. Well-crafted 
object help avoid programming errors that could result from performing 
undefined operations or using data from incompatible objects. In 
geometry, if we subtract the 2d location of one point from the 2d 
location of another point the result is a 2d vector describing the 
distance between these points. However, this vector is not a point. In 
OOP this vector should be a different object than a point.


The wxWidgets objects wxPoint and wxRealPoint are descriptively named, 
though poorly implemented. Aside from where code abuses these, they 
clearly represent locations.  Replacing these with non-OOB typedefs 
such as VECTOR2I removes the clarity that a variable is intended to 
represent a location. The name is not descriptive of a location. There 
is no sanity check to prevent performing a nonsensical operation like 
adding two locations. It tells the programmer nothing about whether a 
variable contains a location, a length, or just two loosely-related 
values.


Rather than replacing wxPoint with VECTOR2I, let us consider how we 
can make our code more object-oriented rather than more Fortran-like. 
I believe we should replace wxPoint and wxRealPoint with 
KiCad-specific objects. These objects should be named such that they 
clearly indicate that they of represent locations rather than a simple 
array of integer values. They should be implemented such that 
nonsensical operations are prohibited and sanity checks put in place 
where possible. For example, attempting to add two locations should 
result in a compile-time error. Additional objects should be defined 
to represent the delta between two locations, and the operations of 
adding a delta to a location should result in a location.


Just for discussion, let's assume the replacement for wxPoint is named 
KiPoint. The result of subtracting two KiPoint objects would be 
another object called KiDelta. Adding two KiPoint objects should be 
undefined, and result in a compile-time error, as this is a nonsense 
operation.  Adding a KiPoint and a KiDelta should return a KiPoint. We 
should never abuse a KiPoint to represent anything else, such as using 
the X value as the radius of a circle as is currently done. I suspect 
most of the places where this would be much more than a mechanical 
substitution is a place where the code abuses the type or is a latent bug.


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.


-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

[Kicad-developers] VECTOR2I and VECTOR2D

[Reece R. Pollack]

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 implementation of vector2d.h I was surprised to discover 
that VECTOR2I is a simple array of /int/ like I would find in an old 
Fortran program. It's not even a C structure, let alone a well-defined 
C++ object.


One of the goals of object-oriented programming is to create descriptive 
objects. Programmers can tell what an object represents by looking at 
the name and implementation of the object. Well-crafted object help 
avoid programming errors that could result from performing undefined 
operations or using data from incompatible objects. In geometry, if we 
subtract the 2d location of one point from the 2d location of another 
point the result is a 2d vector describing the distance between these 
points. However, this vector is not a point. In OOP this vector should 
be a different object than a point.


The wxWidgets objects wxPoint and wxRealPoint are descriptively named, 
though poorly implemented. Aside from where code abuses these, they 
clearly represent locations.  Replacing these with non-OOB typedefs such 
as VECTOR2I removes the clarity that a variable is intended to represent 
a location. The name is not descriptive of a location. There is no 
sanity check to prevent performing a nonsensical operation like adding 
two locations. It tells the programmer nothing about whether a variable 
contains a location, a length, or just two loosely-related values.


Rather than replacing wxPoint with VECTOR2I, let us consider how we can 
make our code more object-oriented rather than more Fortran-like. I 
believe we should replace wxPoint and wxRealPoint with KiCad-specific 
objects. These objects should be named such that they clearly indicate 
that they of represent locations rather than a simple array of integer 
values. They should be implemented such that nonsensical operations are 
prohibited and sanity checks put in place where possible. For example, 
attempting to add two locations should result in a compile-time error. 
Additional objects should be defined to represent the delta between two 
locations, and the operations of adding a delta to a location should 
result in a location.


Just for discussion, let's assume the replacement for wxPoint is named 
KiPoint. The result of subtracting two KiPoint objects would be another 
object called KiDelta. Adding two KiPoint objects should be undefined, 
and result in a compile-time error, as this is a nonsense operation.  
Adding a KiPoint and a KiDelta should return a KiPoint. We should never 
abuse a KiPoint to represent anything else, such as using the X value as 
the radius of a circle as is currently done. I suspect most of the 
places where this would be much more than a mechanical substitution is a 
place where the code abuses the type or is a latent bug.


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.


-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] CMake minimum version

[Reece R. Pollack]

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 supported until 2021.
Only Ubuntu 14.04 LTS release support is now end of life (although I
still have a few updates)


Ubuntu provides paid Extended Security Maintenance through 2021. Their 
standard support has lapsed (which was the date I picked when writing 
the support end date on that website).


Ubuntu LTS releases receive "Standard Support" for 5 years. Extended 
Security Maintenance provides security patches for a further 3 years.


https://ubuntu.com/about/release-cycle

The 16.04 "Xenial Xerus" release Standard Support extends until April 2021.

https://wiki.ubuntu.com/Releases

I would propose that we do not officially support the Linuxes past 
their standard support window.  The hardware requirements on Linux are 
not prohibitive for upgrading and cost is not an issue.


That seems reasonable to me. Once a release falls out of the Standard 
Support period, many of the package repository mirrors purge the 
packages from their systems. This makes it very difficult to maintain 
such a system.


-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 gestures

[Reece R. Pollack]

I'll accept keeping the default behavior of the unmodified scroll wheel 
because changing something like this is would be a radical shift in the 
UI. However, I think this behavior should be programmable so users have 
the option to change it easily.


The worst-case scenario is to make all three behaviors different from 
other applications AND reverse the direction of motion a la Apple.


On 6/12/19 11:32 AM, Jon Evans wrote:
Zooming with no modifier seems to be the more popular choice in the 
creative and CAD applications I have come across (and is certainly my 
preference, because I use 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" 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 make left/right consistent with other
applications rather than making all three different from
everything else.

Also bear in mind that Apple has insistently reversed the use of
the mouse wheel compared with every other OS since the mouse wheel
was introduced decades ago. I understand that they insist this is
"natural", but it's only natural for Apple users which comprise a
small subset of the user base.

-Reece

On 6/12/19 10:33 AM, Jeff Young wrote:

I’m putting the kicad gestures into the List HotKeys dialog.
 Problem is, I don’t know what they are.  So far I have:

Highlight Net           ctrl-left-button
Clear Net Highlighting  ctrl-left-button
Pan Up/Down             shift-mouse-wheel
Pan Left/Right          ctrl-mouse-wheel

Others?

Thanks,
Jeff.

___
Mailing list:https://launchpad.net/~kicad-developers
Post to :kicad-developers@lists.launchpad.net  
<mailto: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
<mailto: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] Kicad gestures

[Reece R. Pollack]

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 programmable hotkey so users have the option to 
change the default behavior to be consistent with other applications.


___
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 gestures

[Reece R. Pollack]

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 make left/right consistent with other applications rather than 
making all three different from everything else.


Also bear in mind that Apple has insistently reversed the use of the 
mouse wheel compared with every other OS since the mouse wheel was 
introduced decades ago. I understand that they insist this is "natural", 
but it's only natural for Apple users which comprise a small subset of 
the user base.


-Reece

On 6/12/19 10:33 AM, Jeff Young wrote:
I’m putting the kicad gestures into the List HotKeys dialog.  Problem 
is, I don’t know what they are.  So far I have:


Highlight Net           ctrl-left-button
Clear Net Highlighting  ctrl-left-button
Pan Up/Down             shift-mouse-wheel
Pan Left/Right          ctrl-mouse-wheel

Others?

Thanks,
Jeff.

___
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] Patch set: Display Origin Transforms rebase

[Reece R. Pollack]

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 

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

[Reece R. Pollack]

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 value like a track width 
which shouldn't be altered,  a relative coordinate delta which may 
need a sign flip, or an absolute coordinate which needs both 
translation and sign flip. Nor does it know whether relative or 
absolute coordinate is an X or a Y axis. Thus it must either have a 
parameter identifying the type of data it's handling or a different 
set of methods to transfer that data in or out based on the type. I 
chose a constructor parameter, and I chose to pass an object 
implemented to handle that type of data.




___
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

[Reece R. Pollack]

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

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

[Reece R. Pollack]

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 you" goes to Seth Hillbrand for providing the example PCB file, 
which was very helpful.


The remaining two patch files provide support for the "Move Exactly", 
"Move Item", and "Create Array" dialogs which the first patch set didn't 
address.


I think this covers all of the places where Pcbnew displays coordinates 
and offsets to the user. If anyone sees something that is either not 
adjusted for the user-selected origin, or has the wrong sign, please let 
me know!


-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

[Kicad-developers] Patch set: Display Origin Transforms

[Reece R. Pollack]

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, this adds Pcbnew user preferences that allow the user to 
select the origin from which absolute coordinates are displayed and 
entered. The supported origins are the Page Origin, the Auxiliary 
Origin, and the Grid Origin. If the user preference has not been set the 
default is Page Origin, which looks just like what we have now.


Additionally, two other Pcbnew user preferences are added to allow the 
user to select which way the X and Y axes increase: Left or Right for 
the X axis, and Up or Down for the Y axis. If the user preference has 
not been set the default is X Right and Y Down, which again looks just 
like what we have now.


I added a new panel to the Pcbnew "Preferences" dialog called "Origins & 
Axes" to allow the user to change these options. I did not add any 
toolbar icons as I expect these will be "set and forget" options for 
most users.


These patches do not alter the content of the board file, nor do they 
change the internal representation of coordinates. The user can change 
preferences without causing revision-managed data churn. The only affect 
is how the user sees and enters coordinate values.


My intent has been to implement these transforms only in Pcbnew, but the 
changes to common data structures necessarily affect all KiCad 
applications. Thus support for display origin and axis shifts is latent 
in the Footprint Editor, GerbView, Eeschema, and the Symbol Editor, and 
can be implemented with minimal effort. However, at this point there 
should be no user-visible changes in any of these applications.


Some notes:

1. The new file "origin_transform.cpp" is currently in common/widgets/
   because that's where unit_binder.cpp was located. It might ought to
   be in common/ instead.
2. I believe I've addressed all user-visible Pcbnew displays and dialog
   boxes other than the Move Exactly dialog. If I missed something
   else, let me know.
3. I haven't decided how the "Move Exactly" dialog should work yet; I
   think it needs axis orientation support but not origin translation.
   I'd be happy to get feedback before I code a patch for this.
4. I did not touch the Bezier coordinates because it appears this is
   not fully implemented in Pcbnew and I couldn't figure out how I
   would test such changes.
5. I'm willing to make a pass through the code to unify the name of the
   Auxiliary Origin once there is a consensus on what to call it.
6. Patching the file containing the list of developers to add my name
   felt kinda presumptuous. I'd be happy if these patches constitutes
   cause to do so.
7. Would someone send Jeff Young on holiday for a week or two? I'm
   getting burned out just trying to keep these patches rebased on his
   changes. :-)


-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] A consistent name for the Aux Origin?

[Reece R. Pollack]

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 extremely useful for placing components or 
routing tracks relative to each other. It's a feature I suspect many 
people use and depend on. And no, you don't want to move the base origin 
for this and then hope you move it back to exactly the same spot later.


The "local origin", the one you set with the space-bar, is handy for 
measuring distances without needing to use a measuring tool. The "Move 
Exactly" dialog uses this to good effect to allow rotation about a spot, 
though one might argue that the grid origin could easily be used for this.


I'm just finishing up a set of patches that allows the user the option 
to see all coordinates displayed relative to the Aux Origin or the Grid 
Origin. The only real complexity in this is the need to pass a reference 
to the transformation class down to all the places its needed, just as 
you had to pass the user's units choice to those same places when you 
removed g_UserUnit last year. This keeps all the transformations from 
the internal origin to a display origin and back in one place. With this 
in place, doing things like allowing the user to choose to make the 
Y-axis increase UP rather than DOWN is trivial (which I've already done).


The origin that is utterly useless at present is the page origin 
somewhere near the upper left corner of the paper drawing frame 
surrounding the board layout. If you could lay out a board so the page 
origin was usefully related to the board's dimensions this would be 
okay, but right now you end up with the paper page's "frame" overlaying 
your board. Get rid of the frame and everything else associated with the 
layout being a paper drawing rather than a digital model of the PCB, and 
we don't need the Aux Origin.


-Reece

On 5/18/19 1:17 PM, Jeff Young wrote:

Hi Eeli,

I’d argue that you explained what it was useful for, not why it is 
“needed”.  I can understand offsetting the grid; I can’t say I believe 
it’s important enough to support the code and UI complexity that it 
brings.


Cheers,
Jeff.


On 18 May 2019, at 14:12, Eeli Kaikkonen > wrote:




la 18. toukok. 2019 klo 13.38 Jeff Young (j...@rokeby.ie 
) kirjoitti:


We need fewer origins.

I like the name Coordinates Origin, but why do we then need a
Grid Origin?  And why a setting for the displayed coordinates? 
Shouldn’t that always be the Coordinates Origin?

Cheers,
Jeff.


I think this was already discussed in 
https://bugs.launchpad.net/kicad/+bug/1773638 and I explained why 
distinct Grid Origin is needed.


Eeli Kaikkonen
___
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] Feature Proposal: Schematic Netlist modules for Eeschema/SKIDL hybrid

[Reece R. Pollack]

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 maintains 
it.

-Reece

On 5/3/19 6:38 PM, Russell Oliver wrote:

I have no doubt about the difficulty of plumbing something like this
feature into KiCad. Most things are easier said than done.

A few thoughts in response

1. My initial thought was to skip generating a graphical schematic,
and to simply join in essence two or more netlists while avoiding name
conflicts. It seems convoluted to start with essentially a
connectivity graph, only to create a graphical representation for it
be be evaluated to create a connectivity graph. It begs the questions
then, should/could there be a text based representation of the
connectivity graph created by eeschema with the information needed to
perform ERC?

  No ERC would be performed between the eeshema Netlist and the Skidl
netlist. This would be left as a design task. The only ERC check would
be on the hierarchical pins which would be predefined by the user as
the interface to the SKIDL generated netlist. Users could be warned
that ERC information doesn't exist for some components.

2. Thinking about it further the task of generating a graphical
schematic shouldn't be too difficult using the SKIDL library. I
suspect Dave would be disappointed in me for being addicted to
schematics. A simple grid based layout with plenty of room between
symbols and using straight line between pins to create connections
would be possible. This would easiest once Eeschema has python support
and the new file format.

2. Editing SKIDL scripts as subsheets I envisage would either be
through a user defined text editor, or a basic one implemented into
KiCad. Once the edit has been done, the file would be evaluated
through the python runtime with the Skidl library (or for a more
generic solution a user specified command line, with the output
captured back as a netlist or schematic).

3. Editing of the resulting components through the edit symbol fields
dialog I think would be possible but only as a one way operation once
the generated netlist/schematic has been added. In that sense it would
be up to the user to maintain that information in the script so that
it is generated each time.

Kind Regards
Russell




___
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] Pcbnew display origin transforms for v6

[Reece R. Pollack]

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 PCB_ORIGIN_TRANSFORM_Y_ABS::FromDisplay( int aValue ) 
const
 case ORIGIN_REFERENCE_PAGE:
 // No-op
 break;
-    case ORIGIN_REFERENCE_AUX:
-    origin = m_PcbBaseFrame->GetAuxOrigin().y;
-    break;
-    case ORIGIN_REFERENCE_GRID:
-    origin = m_PcbBaseFrame->GetGridOrigin().y;
-    break;
-    default:
-    wxASSERT(false);
-    break;
+    case ORIGIN_REFERENCE_AUX: origin = m_PcbBaseFrame->GetAuxOrigin().y; 
break;
+    case ORIGIN_REFERENCE_GRID: origin = m_PcbBaseFrame->GetGridOrigin().y; 
break;
+    default: wxASSERT( false ); break;
 }

 // Invert the direction if needed



On 5/6/19 8:11 AM, John Beard wrote:

On 03/05/2019 19:28, Wayne Stambaugh wrote:


I'm guessing John used a later version of clang-format when he wrote the
commit hooks.  John, any ideas how to fix this or do we force devs to
use clang-format > 3.8?


I'm on Arch, so I have quite recent clang-format (8.0.0). This particular 
option has always been in the _clang-format, and seems the config was 
introduced in clang-format 3.9.

I don't really have any great idea to fix this in general. I think the options 
are:

* Tell people to use 3.9 or later (actually I don't know what options we have 
need what versions). Most distros will allow people to install newer toolchains 
(sometimes need to enable the updates/backports repos). I think clang 4 is 
available in Mint 18/Xenial, and 5 and 6 are in Xenial-updates.

* Provide multiple style files, suitable for older clangs. Then the git hook 
can feed the right one to clang-format. In this case, you might find formatting 
differences if people use older clangs.

* Remove any options that don't suit clang 3.8 (our de facto minimum version) 
and deal with the misformattings:

In this case: formatting clang-format <= 3.8 (BreakStringLiteral not available, so 
"default", which is "true"):

    std::string var =
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit, "
    "sed do eiusmod tempor incididunt ut labore et dolore magna "
    "aliqua";

Current _clang-format (BreakStringLiteral=false) with clang-format >= 3.9:

    std::string var =
    "Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod 
tempor incididunt ut labore et dolore magna aliqua";

I suspect this happens little enough that we can deal with it in any case. 
People always need to be aware that you cannot blindly apply the formatter 
anyway. `git add -p` is the way to selectively apply formatting changes.

@Reese, could you give it a go with clang-4 and see if there are any more 
broken options?

@Wayne, any preference for how we deal with it?

Cheers,

John

___
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] eemodern branch

[Reece R. Pollack]

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 pcbnew rather than 
eechema.

This reminds me of the v4->v5 transition, where I had a similar experience. 
Having continued through all of the asserts I no longer get these when restarting 
the v6 apps.


20:22:12: Debug: Adding duplicate image handler for 'PNG file'
20:22:12: Debug: Adding duplicate image handler for 'JPEG file'
20:22:12: Debug: Adding duplicate image handler for 'TIFF file'
20:22:12: Debug: Adding duplicate image handler for 'GIF file'
20:22:12: Debug: Adding duplicate image handler for 'PNM file'
20:22:12: Debug: Adding duplicate image handler for 'PCX file'
20:22:12: Debug: Adding duplicate image handler for 'IFF file'
20:22:12: Debug: Adding duplicate image handler for 'Windows icon file'
20:22:12: Debug: Adding duplicate image handler for 'Windows cursor file'
20:22:12: Debug: Adding duplicate image handler for 'Windows animated cursor 
file'
20:22:12: Debug: Adding duplicate image handler for 'TGA file'
20:22:12: Debug: Adding duplicate image handler for 'XPM file'
20:22:12: Debug: Unrecognized accel key '', accel string ignored.
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for 
Back: pcbnew.InteractiveEdit.remove and pcbnew.InteractiveDrawing.deleteLastPoint
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for X: 
pcbnew.InteractiveRouter.SingleTrack and pcbnew.InteractiveRouter.NewTrack
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for 
Back: pcbnew.InteractiveEdit.remove and pcbnew.InteractiveDrawing.deleteLastPoint
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for X: 
pcbnew.InteractiveRouter.SingleTrack and pcbnew.InteractiveRouter.NewTrack
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for 
Back: pcbnew.InteractiveEdit.remove and pcbnew.InteractiveDrawing.deleteLastPoint
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for X: 
pcbnew.InteractiveRouter.SingleTrack and pcbnew.InteractiveRouter.NewTrack
20:22:20: Debug: Unrecognized accel key '', accel string ignored.
20:22:20: Debug: Unrecognized accel key '', accel string ignored.
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for 
Back: pcbnew.InteractiveEdit.remove and pcbnew.InteractiveDrawing.deleteLastPoint
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for X: 
pcbnew.InteractiveRouter.SingleTrack and pcbnew.InteractiveRouter.NewTrack
20:22:22: Debug: Loading project 
'/home/reece/MyProjects/MCS-4/Recreation/P170-DH/pcb/P170-DH 
Replacement/P170-DH Replacement.pro' settings.
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for 
Back: pcbnew.InteractiveEdit.remove and pcbnew.InteractiveDrawing.deleteLastPoint
/home/reece/MyProjects/KiCad/kicad-v6/common/tool/action_manager.cpp(214): assert 
"Assert failure" failed in UpdateHotKeys(): Duplicate hotkey definitions for X: 
pcbnew.InteractiveRouter.SingleTrack and pcbnew.InteractiveRouter.NewTrack
OpenGL WARNING: Buffer performance warning: Buffer object 2 (bound to 
GL_ARRAY_BUFFER_ARB, usage hint is GL_DYNAMIC_DRAW) is being copied/moved from 
VIDEO memory to DMA CACHED memory.

** (kicad:16791): WARNING **: Invalid borders specified for theme pixmap:
    /usr/share/themes/Breeze/gtk-2.0/../assets/line-h.png,
borders don't fit within the image

(kicad:16791): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'width 
>= -1' failed

(kicad:16791): Gtk-CRITICAL **: IA__gtk_widget_set_size_request: assertion 'width 
>= -1' failed

(kicad:16791): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate 
widget with width -5 and height 19

(kicad:16791): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate 
widget with width -5 and height 19

(kicad:16791): Gtk-WARNING **: gtk_widget_size_allocate(): attempt to allocate 
widget with width -5 and height 19

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

[Reece R. Pollack]

Rene pointed out that my work on display origin transforms is really a fix for 
Bug #1773638, thus the retitling.

I'm making good progress, but I need a bit of guidance before proceeding 
further.

The code I've developed allows the user to select the origin for the display of X and Y 
coordinates, rather than the origin always being the upper left corner of the surrounding 
"page" frame. There is no change to the underlying board file or internal 
coordinate representation. This is purely a change the way coordinates are displayed to 
the user and entered by the user in dialog boxes.

The user gets three configuration options:

 * The absolute display origin: Page (default), Aux, or Grid.
 * The direction of the positive Y-axis: Down (default) or Up.
 * The direction of the positive X-axis: Right (default) or Left.

I've attached patch diffs for review and experimentation. The patches will apply cleanly to the 
current "eemodern" branch (commit 6137921), the 5.1.2 tag with one trivial merge error, 
and probably the "master" branch. It's not ready for merging, though. It lacks a UI for 
configuration, and configuration isn't saved or loaded from the user preferences file. For testing 
the config defaults to Aux origin and Y-axis Up. Obviously these deficiencies will have to be 
addressed before a merge.

Now for my request for guidance:

1. The user configuration options are currently in the PCB_DISPLAY_OPTIONS 
class. I'd like some confirmation that this is the correct place before I code 
the preferences file save and restore.
2. Where should the config UI go? I expect this will be a set-and-forget thing for most 
users. I'm thinking on the Pcbnew Preferences -> Preferences -> Pcbnew -> 
Display Options dialog, if there's room. But this panel seems to be half-shared with 
other apps and is getting kind of full. Perhaps another panel instead of Display Options?
3. The last time I did UI work was when the TRS-80 was hot stuff (I'm a Linux 
kernel guy). Can someone recommend an approach for developing the UI changes, 
and perhaps a pointer to a relevant how-to?
4. The dx/dy (relative coordinate) part of the status line isn't being 
transformed yet because of commit e6a200b. I posted a question regarding that 
earlier today but haven't received any replies yet.
5. Have I missed any dialog boxes that present absolute coordinates 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, 3 May 2019 09:43:11 -0400
Subject: [PATCH 1/2] RRP: Common changes to support Display Origin Transforms

This commit contains the changes to common files to support Display
Origin Transforms. This will allow the user to change the origin
of the displayed coordinates in status lines and dialog boxes to be
relative to a user-selected origin.

The origin may be selected as one of the following:
  * The upper left corner of the surrounding page frame
  * The Auxilliary origin (aka Drill or Manufacturing origin)
  * The Grid origin

The defined transforms are:
  * A null (or identity) transform
  * X-axis origin and sign transform for absolute coordinates
  * Y-axis origin and sign transform for absolute coordinates
  * X-axis sign transform for relative coordinates
  * Y-axis sign transform for relative coordinates

The default transform is the null transform, and is supplied by
the EDA_DRAW_FRAME class. These transforms may be overridden by
derived classes, such as the PCB_BASE_FRAME class.
---
 common/widgets/unit_binder.cpp | 29 -
 include/common.h   | 15 +++
 include/draw_frame.h   | 10 ++
 include/widgets/unit_binder.h  | 15 ++-
 4 files changed, 63 insertions(+), 6 deletions(-)

diff --git a/common/widgets/unit_binder.cpp b/common/widgets/unit_binder.cpp
index 4e7b7ab..e5c7c1f 100644
--- a/common/widgets/unit_binder.cpp
+++ b/common/widgets/unit_binder.cpp
@@ -35,11 +35,14 @@ wxDEFINE_EVENT( DELAY_FOCUS, wxCommandEvent );
 
 UNIT_BINDER::UNIT_BINDER( EDA_DRAW_FRAME* aParent,
   wxStaticText* aLabel, wxWindow* aValue, wxStaticText* aUnitLabel,
-  bool aUseMils, bool allowEval ) :
+  bool aUseMils, bool allowEval, ORIGIN_XFORMS aOriginXform ) :
+m_parent( aParent ),
 m_label( aLabel ),
 m_value( aValue ),
 m_unitLabel( aUnitLabel ),
-m_eval( aParent->GetUserUnits(), aUseMils )
+m_eval( aParent->GetUserUnits(), aUseMils ),
+m_originXform( aOriginXform ),
+m_allowOriginXform( aOriginXform != ORIGIN_XFORM_NONE )
 {
 // Fix the units (to the current units) for the life of the binder
 m_units = aParent->GetUserUnits();
@@ -168,7 +171,11 @@ bool UNIT_BINDER::Validate( i

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

[Reece R. Pollack]

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 coordinates
from integer to floating-point. For example, this calculation:

int dx = GetCrossHairPosition().x - screen->m_O_Curseur.x;

became this:

double dx = (double)GetCrossHairPosition().x - 
(double)screen->m_O_Curseur.x;

There are several other such changes. I don't understand why this
is necessary, and the commit doesn't reference a bug report.  What
circumstances resulted in this commit?

The reason I ask is that bears strongly on the changes I'm working
on to display coordinates relative to a user-selected origin. To
translate coordinates from the internal origin to the user origin I
subtract the user origin coordinates from the internal coordinates.
And, of course, to translate back to the internal origin I add the
user origin coordinates to the displayed coordinates. If this is
likely to overflow then my changes might re-introduce whatever
problem this commit was intended to correct.

The internal representation is in nanometers (1e-9). A signed 32-bit
integer can therefore represent 2^31 (~2.147) meters. Subtracting one
integer coordinate from another could only overflow if the distance
between them is greater than this, which implies one value is positive
and the other is negative. Converting the operands to double before
the subtraction doesn't eliminate the problem, it only extends it to
2^32 or 4.295 meters.

Does KiCad support schematic sheets or PCBs larger than 2 meters? If
so, then we should promote the internal units to "long long" and not
hack around with half-steps like this. If not, then this commit isn't
needed.

-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] Pcbnew display origin transforms for v6

[Reece R. Pollack]

Hi Wayne,

No worries on formatting. As a senior professional software engineer I'm 
used to dealing with formal coding conventions and I'm keeping the web 
page open while I'm writing. I prefer the K style myself, but I'm not 
going to lose sleep over the differences.


I had a bit of trouble getting the clang-format commit checker to work. 
Mint 18 installs clang-format 3.8 by default, which doesn't support the 
'BreakStringLiterals' key. It spits out the following message:


YAML:23:22: error: unknown key 'BreakStringLiterals'
BreakStringLiterals: false
 ^
Error reading /home/reece/MyProjects/KiCad/kicad/_clang-format: Invalid 
argument


With the invocation of clang-format buried under the git extension 
mechanism this error message is invisible to the user. Worse, 
clang-format then blithely ignores the entire style file and reformats 
the file using its default settings (IndentWidth 2, etc.). The notes 
should probably be updated to note the minimum version of clang-format 
required to handle the supplied _clang-format file.


-Reece


On 5/2/19 7:56 AM, Wayne Stambaugh wrote:

Hi Reece,

Just a few comments on top of Jeff's reply since this will be your first
patch submission:

Please follow the coding style policy[1].  It saves a lot of back and
forth.  There is also a git commit hook[2] which you can use to verify
your coding style is correct.  You will have to have clang-format
installed on your system in order to use this feature.

When you are ready to submit your patch(es), use `git format-patch` to
create the patch(es) and post them on the mailing list for comment.

It was great talking with you at KiCon.  Thank you again for your
interest in contributing to KiCad.

Cheers,

Wayne

[1]:
http://docs.kicad-pcb.org/doxygen/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 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 code this for eventual inclusion into the v6 development branch.

My plan is:

  1. Create a new class ORIGIN_TRANSFORM. This class maintains the user's
 configuration and provides functions to perform the transforms
 necessary to convert between the internal coordinate representation
 and the equivalent coordinates relative to the user-selected origin.
  2. Embed two ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS
 class representing the origin transforms for the X and Y axes.
  3. Create a new tab in the pcbnew "Preferences" to allow the user to
 select the origin (Page [default], Aux, or Grid) and direction (Left
 or Right [default], Up or Down [default]) for each axis.
  4. Modify the board file format to save and load the user's
 ORIGIN_TRANSFORM configuration. Saving this in the .kicad_pcb file
 allows everyone editing the board to see coordinates reported
 relative to the same origin.
  5. Modify each of the dialog classes that displays object coordinates
 to use the ORIGIN_TRANSFORM objects to display coordinates relative
 to the user-selected origin. When the dialog is closed object
 coordinates are converted back to internal coordinates.
  6. Modify the PCB_BASE_FRAME class to display the absolute cursor
 position relative to the user-selected origin.

This is structured to allow the UNIT_BINDER class to manage origin
transforms, much like it handles the mm/mil conversions. I would change
the constructor to take a reference to an ORIGIN_TRANSFORM object as an
additional argument; the default value would be a unity-transform whose
conversion functions return the value to be converted unmodified. Those
UNIT_BINDER objects that represent a coordinate value (commonly m_posX
and m_posY) would be constructed with a reference to one of the two
ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS class.

The problem with this strategy is that KiCad reuses UNIT_BINDER objects
for dissimilar purposes. For example,
DIALOG_GRAPHIC_ITEM_PROPERTIES::m_endX can represent the end point of a
graphic line, for which origin transform is needed. But it can also
represent the radius of a circle, for which origin transform is
inappropriate. Thus UNIT_BINDER needs a method similar to the Show()
function to enable or disable the origin transform depending on how it
is being used. This may argue against pushing this functionality into
UNIT_BINDER.

If I don't modify the UNIT_BINDER class I'll probably code the
ORIGIN_TRANSFORM class to handle wxPoint objects rather than individual
coordinates. Thus there would be only one ORIGIN_TRANSFORM object added
to the BOARD_DESIGN_SETTINGS class. The transform in the di

[Kicad-developers] Pcbnew display origin transforms for v6

[Reece R. Pollack]

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 code this for eventual inclusion into the v6 development branch.


My plan is:

1. Create a new class ORIGIN_TRANSFORM. This class maintains the user's
   configuration and provides functions to perform the transforms
   necessary to convert between the internal coordinate representation
   and the equivalent coordinates relative to the user-selected origin.
2. Embed two ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS
   class representing the origin transforms for the X and Y axes.
3. Create a new tab in the pcbnew "Preferences" to allow the user to
   select the origin (Page [default], Aux, or Grid) and direction (Left
   or Right [default], Up or Down [default]) for each axis.
4. Modify the board file format to save and load the user's
   ORIGIN_TRANSFORM configuration. Saving this in the .kicad_pcb file
   allows everyone editing the board to see coordinates reported
   relative to the same origin.
5. Modify each of the dialog classes that displays object coordinates
   to use the ORIGIN_TRANSFORM objects to display coordinates relative
   to the user-selected origin. When the dialog is closed object
   coordinates are converted back to internal coordinates.
6. Modify the PCB_BASE_FRAME class to display the absolute cursor
   position relative to the user-selected origin.

This is structured to allow the UNIT_BINDER class to manage origin 
transforms, much like it handles the mm/mil conversions. I would change 
the constructor to take a reference to an ORIGIN_TRANSFORM object as an 
additional argument; the default value would be a unity-transform whose 
conversion functions return the value to be converted unmodified. Those 
UNIT_BINDER objects that represent a coordinate value (commonly m_posX 
and m_posY) would be constructed with a reference to one of the two 
ORIGIN_TRANSFORM objects in the BOARD_DESIGN_SETTINGS class.


The problem with this strategy is that KiCad reuses UNIT_BINDER objects 
for dissimilar purposes. For example, 
DIALOG_GRAPHIC_ITEM_PROPERTIES::m_endX can represent the end point of a 
graphic line, for which origin transform is needed. But it can also 
represent the radius of a circle, for which origin transform is 
inappropriate. Thus UNIT_BINDER needs a method similar to the Show() 
function to enable or disable the origin transform depending on how it 
is being used. This may argue against pushing this functionality into 
UNIT_BINDER.


If I don't modify the UNIT_BINDER class I'll probably code the 
ORIGIN_TRANSFORM class to handle wxPoint objects rather than individual 
coordinates. Thus there would be only one ORIGIN_TRANSFORM object added 
to the BOARD_DESIGN_SETTINGS class. The transform in the dialog class 
then becomes a single call to transform a coordinate pair rather than 
one each for X and Y.


Thoughts? Comments? Suggestions? Brickbats?

-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] Is errno defined on MSW?

[Reece R. Pollack]

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 same on windows.

You may want to consider looking into fopen_s which Windows and gcc 
using C11 or newer should have. It makes errno threadsafe among other 
safety improvements.


On Mon, Aug 13, 2018 at 5:13 PM Jeff Young > wrote:


While I can’t test it, Microsoft’s doc certainly suggests they
support it equivalently enough for our purposes:

https://msdn.microsoft.com/en-us/library/5814770t.aspx

Cheers,
Jeff.




> On 13 Aug 2018, at 21:30, Jeff Young mailto:j...@rokeby.ie>> wrote:
>
> I’m putting in some more/better error messages to try and catch
a file-save issue some folks are having [1].
>
> Is errno defined on MSW?
>
> Thanks,
> Jeff.
>
> [1] https://bugs.launchpad.net/kicad/+bug/1786512
> ___
> 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



--
Mark


___
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] Error importing the wxPython API!

[Reece R. Pollack]

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 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 possibility of my local changes affecting the tests. In 
hopes of avoiding messing up my normal installation in /usr/local, 
when I built this new tree I specified an installation directory with 
the -DCMAKE_INSTALL_PREFIX= option to Cmake. Since it wasn't 
installing in a system directory I didn't use "sudo" during the 
installation of this test version.


I discovered that when starting KiCad from the KDE menu I found it ran 
the test version rather than the version in /usr/local. That was a 
surprise, but not a disaster. Once the testing was over I wanted to go 
back to my regular version installed in /usr/local, so in the test 
build directory I ran "make uninstall". Yet starting KiCad from the 
KDE menu resulted in a project manager that reported the test build 
version, not my locally-modified build version.


Somewhat confused as to what executable was running, I deleted the 
entire test repo. I then went to my local build repo and re-ran "sudo 
make install" which completed successfully. I then started getting the 
expected version from the project manager window and from eeschema. 
However, pcbnew fails with this error:


    *** Error importing the wxPython API! ***

I haven't changed my system configuration recently, so I ran "sudo 
make uninstall", cleaned the build and recompiled everything from 
scratch, and ran "sudo make install". Again the install ran without 
errors, but I still can't run pcbnew. Here's the output from running 
pcbnew from a terminal window:


$ pcbnew
23:05:31: Debug: Checking template path 
'/usr/local/share/kicad/template' exists

23:05:31: Debug: Adding duplicate image handler for 'PNG file'
23:05:31: Debug: Adding duplicate image handler for 'JPEG file'
23:05:31: Debug: Adding duplicate image handler for 'TIFF file'
23:05:31: Debug: Adding duplicate image handler for 'GIF file'
23:05:31: Debug: Adding duplicate image handler for 'PNM file'
23:05:31: Debug: Adding duplicate image handler for 'PCX file'
23:05:31: Debug: Adding duplicate image handler for 'IFF file'
23:05:31: Debug: Adding duplicate image handler for 'Windows icon file'
23:05:31: Debug: Adding duplicate image handler for 'Windows cursor file'
23:05:31: Debug: Adding duplicate image handler for 'Windows animated 
cursor file'

23:05:31: Debug: Adding duplicate image handler for 'TGA file'
23:05:31: Debug: Adding duplicate image handler for 'XPM file'
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/__init__.py", 
line 49, in 

    from wx._core import *
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py", 
line 16923, in 

    from _gdi import *
ValueError: bad marshal data (unknown type code)
23:06:08: Error: pcbnewInitPythonScripting() failed.
Segmentation fault


Have I done something dumb? Is this worth filing a bug report?

-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

[Kicad-developers] Error importing the wxPython API!

[Reece R. Pollack]

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 
possibility of my local changes affecting the tests. In hopes of 
avoiding messing up my normal installation in /usr/local, when I built 
this new tree I specified an installation directory with the 
-DCMAKE_INSTALL_PREFIX= option to Cmake. Since it wasn't 
installing in a system directory I didn't use "sudo" during the 
installation of this test version.


I discovered that when starting KiCad from the KDE menu I found it ran 
the test version rather than the version in /usr/local. That was a 
surprise, but not a disaster. Once the testing was over I wanted to go 
back to my regular version installed in /usr/local, so in the test build 
directory I ran "make uninstall". Yet starting KiCad from the KDE menu 
resulted in a project manager that reported the test build version, not 
my locally-modified build version.


Somewhat confused as to what executable was running, I deleted the 
entire test repo. I then went to my local build repo and re-ran "sudo 
make install" which completed successfully. I then started getting the 
expected version from the project manager window and from eeschema. 
However, pcbnew fails with this error:


    *** Error importing the wxPython API! ***

I haven't changed my system configuration recently, so I ran "sudo make 
uninstall", cleaned the build and recompiled everything from scratch, 
and ran "sudo make install". Again the install ran without errors, but I 
still can't run pcbnew. Here's the output from running pcbnew from a 
terminal window:


$ pcbnew
23:05:31: Debug: Checking template path 
'/usr/local/share/kicad/template' exists

23:05:31: Debug: Adding duplicate image handler for 'PNG file'
23:05:31: Debug: Adding duplicate image handler for 'JPEG file'
23:05:31: Debug: Adding duplicate image handler for 'TIFF file'
23:05:31: Debug: Adding duplicate image handler for 'GIF file'
23:05:31: Debug: Adding duplicate image handler for 'PNM file'
23:05:31: Debug: Adding duplicate image handler for 'PCX file'
23:05:31: Debug: Adding duplicate image handler for 'IFF file'
23:05:31: Debug: Adding duplicate image handler for 'Windows icon file'
23:05:31: Debug: Adding duplicate image handler for 'Windows cursor file'
23:05:31: Debug: Adding duplicate image handler for 'Windows animated 
cursor file'

23:05:31: Debug: Adding duplicate image handler for 'TGA file'
23:05:31: Debug: Adding duplicate image handler for 'XPM file'
Traceback (most recent call last):
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/__init__.py", 
line 49, in 

    from wx._core import *
  File "/usr/lib/python2.7/dist-packages/wx-3.0-gtk2/wx/_core.py", line 
16923, in 

    from _gdi import *
ValueError: bad marshal data (unknown type code)
23:06:08: Error: pcbnewInitPythonScripting() failed.
Segmentation fault


Have I done something dumb? Is this worth filing a bug report?

-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] More default fields in schematic

[Reece R. Pollack]

That was from a commit I made on 5/24. It looks like I was using a build 
derived from your commit of 5/20:

    3a8a718 A pesky bug, this one is.  (Said in best Yoda impression.)


On 05/29/18 10:12, Jeff Young wrote:

Hi Reece,

Was that generated with a recent build?  Earlier versions of 5.0 
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>> wrote:


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


None of these have any default values that make any sense, so I 
assume they’re all just names with empty values, right?


Yes, all of these are empty by default, though I typically order from 
DigiKey so I could have set that one. I added them as "Default 
Fields" so that all components would have the same fields, and I 
wouldn't have to depend on adding the field names by hand.






The first two give the manufacturer's name and part number; the 
second two give the distributor's name and part number; the third 
is a catch-all for specs that are important for ordering but aren't 
worth cluttering the schematic with.


My biggest issue with the current Default Fields is that I didn't 
start my current project with them, so using the field edit 
spreadsheet-like thingie often results in lots of noise in my 
commits as the empty default fields get added to components.


If it’s adding empty default fields then it’s a bug.  It should only 
add them if they have non-empty values.


Then you have a bug. Here's a small excerpt from a Git diff where a 
lot of components had empty fields added. None of these components 
were added in this revision; I was simply setting part numbers for 
/other/ components using the field editor spreadsheet thingie:


diff --git a/Recreation/P170-DH/pcb/P170-DH 
Replacement/ExternalInterface.sch b/Recreation/P170-DH/pcb/P170-DH 
Replacement/ExternalInterface.sch

index 37482ee..e2aea43 100644
--- a/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch
+++ b/Recreation/P170-DH/pcb/P170-DH Replacement/ExternalInterface.sch
@@ -22,6 +22,11 @@ F 0 "U12" H 3900 2215 50   C CNN
 F 1 "74LVC1T45" H 3900 2124 50   C CNN
 F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 1850 50  0001 C CNN
 F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 1850 
50  0001 C CNN

+F 4 "" H 0   0   50  0001 C CNN "Distr"
+F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
+F 6 "" H 0   0   50  0001 C CNN "Mfgr"
+F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    3900 1850
    1    0    0    -1
 $EndComp
@@ -33,6 +38,11 @@ F 0 "U13" H 3900 3415 50   C CNN
 F 1 "74LVC1T45" H 3900 3324 50   C CNN
 F 2 "Package_TO_SOT_SMD:SOT-23-6" H 3900 3050 50  0001 C CNN
 F 3 "http://www.ti.com/lit/ds/symlink/sn74lvc1t45.pdf; H 3900 3050 
50  0001 C CNN

+F 4 "" H 0   0   50  0001 C CNN "Distr"
+F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
+F 6 "" H 0   0   50  0001 C CNN "Mfgr"
+F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    3900 3050
    1    0    0    -1
 $EndComp
@@ -66,6 +86,11 @@ F 0 "J5" H 7719 1375 50   C CNN
 F 1 "Conn_01x06" H 7719 1466 50   C CNN
 F 2 "Connector_PinHeader_2.54mm:PinHeader_1x06_P2.54mm_Vertical" H 
7800 1900 50  0001 C CNN

 F 3 "~" H 7800 1900 50  0001 C CNN
+F 4 "" H 0   0   50  0001 C CNN "Distr"
+F 5 "" H 0   0   50  0001 C CNN "Distr P/N"
+F 6 "" H 0   0   50  0001 C CNN "Mfgr"
+F 7 "" H 0   0   50  0001 C CNN "Mfgr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    7800 1900
    1    0    0    -1
 $EndComp
@@ -209,6 +234,7 @@ F 4 "CTS" H 3900 7100 50  0001 C CNN "Mfgr"
 F 5 "218-4LPST" H 3900 7100 50  0001 C CNN "Mfgr P/N"
 F 6 "DigiKey" H 3900 7100 50  0001 C CNN "Distr"
 F 7 "CT2184LPST-ND" H 3900 7100 50  0001 C CNN "Distr P/N"
+F 8 "" H 0   0   50  0001 C CNN "Specifications"
    1    3900 7100
    1    0    0    -1
 $EndComp
@@ -321,6 +347,11 @@ F 0 "R127" H 4509 5746 50   L CNN
 F 1 "100K" H 4509 5655 50   L CNN
 F 2 "Resistor_SMD:R_0603_1608Metric" H 4450 5700 50 0001 C CNN
 F 3 "~&quo

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

[Reece R. Pollack]

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; the third is a 
catch-all for specs that are important for ordering but aren't worth 
cluttering the schematic with.


My biggest issue with the current Default Fields is that I didn't start 
my current project with them, so using the field edit spreadsheet-like 
thingie often results in lots of noise in my commits as the empty 
default fields get added to components.


I was originally against adding such defined fields, as I expect it will 
add fields to components that will potentially conflict with those 
created by current users. However, if it doesn't do that, and has the 
support from parts distributors, I guess I could live with it.


On 05/22/18 10:56, Fabrizio Tappero wrote:

Hello,
I'd like to contribute with my 2c.

I completely agree with Kristoffer, there is a need for a "MPN" field 
hard coded exactly as "Value" field is hard coded in Kicad.


As Wayne mentions the current "Preferences - General Options - Default 
Fields" is not a bad option to add a "MPN" field. This is what I do 
and this is what all my PCB colleges at work do.


Above solution will however not help the majority to do the same. I 
would actually bet 2c that nearly nobody uses the Default Fields 
feature (most of the people probably do it component by component). 
And this makes it a not so useful feature.


Kicost is a god-made tool and for sure Dave will soon add MPN as a 
default field in Kicad.


Cheers
Fabrizio





On Tue, May 22, 2018 at 3:41 PM, kristoffer ödmark 
> 
wrote:


My updated patch forgot to add the files before doing the --amend.

So it only updated the commit message. Here is the real file

On Tue, 2018-05-22 at 07:52 -0500, Ben Hest wrote:
> From a Digi-Key KiCad library standpoint, as we're still in beta, I
> would
> gladly change the fields to whatever would be decided.  Uniformity
> for
> plugins use would definitely be an advantage.
>
> -Ben
>
> On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
> kristofferodmar...@gmail.com
> wrote:
>
> > Thanks! This is exactly what i was going for, non-intrusive
> > oppurtunity
> > for uniformity!
> >
> > I tested the bom2csv plugin, It did not include the empty fields.
> >
> > I also tested the bom_csv_sorted_by_ref, it did not include the
> > empty
> > values, but it included some values I had not specified, such as
> > Manufacturer and Vendor even if they were not provided in the
> > schematic.
> >
> > - Kristoffer
> >
> > On Tue, 2018-05-22 at 11:05 +0100, Jeff Young wrote:
> > > I think I like this new patch.  It provides the
/opportunity/ for
> > > uniformity, without getting in the way of those who want to go
> > > their
> > > own way.
> > >
> > > Do the BOM generators automatically output all default fields or
> > > only
> > > those with values?
> > >
> > > > On 22 May 2018, at 09:22, kristoffer ödmark
 > > > @gma
> > > > il.com > wrote:
> > > >
> > > > Please disregard my previous mail, it got mangled badly
> > > > somehow, it
> > > > did
> > > > not look like that in my editor at least.
> > > >
> > > > On Mon, 2018-05-21 at 18:22 -0400, Wayne Stambaugh wrote:
> > > > > Eeschema already supports creating default optional
fields in
> > > > > the
> > > > > configuration settings dialog. Used correctly, these will
> > > > > give
> > > > > you
> > > > > the
> > > > > same optional field names for every project without
having to
> > > > > add
> > > > > them
> > > > > by hand to each symbol and possibly typing in different
field
> > > > > names
> > > > > by
> > > > > accident.
> > > >
> > > > Different users will still type in different field names for
> > > > the
> > > > same
> > > > things though. What you describe works as long as there is
only
> > > > one
> > > > person in the entire projects lifetime, using only one
> > > > computer.
> > > >
> > > > > The proposed patch would intermingle the default fields
> > > > > with
> > > > > existing schematic symbol fields which would break existing
> > > > > BOMs
> > > > > which I
> > > > > don't think users will appreciate.
> > > >
> > > > The proposed patch will only change default settings, existing
> > > > users
> > > > with a config already in place will not be affected. I
realised
> > > > that
> > > > the fields now accept empty values as well, so 

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

[Reece R. Pollack]

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 configurable by the user, with the default 
being the current implementation. Also planned but not implemented is to 
allow the user to choose which way the measurements increase, so that 
the Y axis can be flipped to increase as you move toward the top of the 
screen.


-Reece


On 05/13/18 07:28, Jeff Young wrote:

But that only helps for dragging, not typing in values, right?


On 13 May 2018, at 12:21, jp charras  wrote:

Le 13/05/2018 à 13:03, Jeff Young a écrit :

So there’s no way to change the coordinates origin?  (Even for display/editing 
purposes?)

The space bar reset the *relative* coordinates origin.


On 13 May 2018, at 11:51, jp charras  wrote:

Le 13/05/2018 à 12:48, Jeff Young a écrit :

For instance, if I have a component at (5,4) and I change the grid origin to 
(2,2) then I expect the component location to now be (3,2).  But it’s still 
(5,4).  Is there a reason for this?


Yes: the grid origin has nothing to do with the coordinates origin.

--
Jean-Pierre CHARRAS--

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

[Kicad-developers] A reminder on Git commit comments

[Reece R. Pollack]

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 would write code like this:


   x = x + 1;   /* Add 1 to x */


While the comment is totally correct, it's also totally useless. I can 
/see/ that this line adds 1 to /x/; I don't need a comment to tell me 
that. As a programmer coming along later, what I need to know is /why/ 1 
is being added to /x/.


I'm seeing commit comments of the form "add one to x" in the KiCad 
repos. These comments are useless. For an example, look at this commit 
in the kicad-symbols repo:


   commit 4ada78e26774c841ce8ec33e8b221d04fed1f4c7
   Author: Rene Pöschl 
   Date:   Fri Apr 20 11:14:47 2018 +0200

    Remove Connector_Specialized files.

Great. I can /see/ that these files are being removed. That's obvious 
from looking at the content of the commit. But there is no explanation 
of why these files were deleted. Don't tell me that there was discussion 
about this in email; even if that happened it's irrelevant. No one 
should have to go chasing through an email archive hoping to understand 
why a change was made. That's what the commit log entry is for.


I went back further in the Git logs for commits touching these files 
hoping to find a more illuminating commit comment, but found nothing 
helpful. In fact, I came across an earlier series of commits that are 
even /less/ helpful:


   commit 467170586b106d00c4df185dc1683046e259b74c
   Author: evanshultz 
   Date:   Thu Apr 19 09:42:52 2018 -0700

    Just checking... still no dice

   commit 966a1a40aa36732d9c2404b044a4ef63bd0bb417
   Author: evanshultz 
   Date:   Thu Apr 19 09:36:28 2018 -0700

    Delete Connector_Specialized.lib

   commit aeb4270213da8a063f24163d6fa31e8521f08a83
   Author: evanshultz 
   Date:   Thu Apr 19 09:36:03 2018 -0700

    Delete Connector_Specialized.dcm

The top (latest) commit actually reverts the actions of the previous two 
commits. So now I have the idea that there's some sort of disagreement 
whether these files should be part of the repo or not. But I still have 
no idea why.


In a previous job I was the poor sod (or arrogant bastard, take your 
pick) who had to review commits before they were merged into the master 
branch. I would have rejected commits like these immediately. With Open 
Source development there's often less control over what gets merged and 
what doesn't. But that just means it's all the more important for 
everyone to make an effort to write good commit comments.


From the KiCad source file 
Documentation/development/commit-message-format.md:


   Commit messages should begin with a subject line; try to limit this
   to no more
   than 50-72 characters. The body of the message should be separated
   from the
   subject by a blank line and wrapped at 72 characters. The body of a
   commit
   message should explain what the commit does and why, but do not
   explain *how*
   as the code itself should do that.


___
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] [RFC] Remove bus joining behavior from KiCad after 5.0 release

[Reece R. Pollack]

Thanks, Maciej. Are you going to get me a pony too? :-)

Orson's proposal looks grand, as long as I can add existing nets/buses 
to a new bus, rather than having to define the big bus and its members 
first and then create aliases for the bus members.


On 04/20/18 11:18, Maciej Sumiński wrote:

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/+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 this idea so a bus can contain another bus makes sense. Let's
take an LCD display. In addition to the 4 or 8 data lines, there are
several control lines that should be part of the bus. I want an LCD bus
that contains LCD_E, LCD_RS, and LCD_RW as well as LCD_D[0..7]. And
while I'm fantasizing, I want the bus name to be "LCD"; I do NOT want it
named "LCD_E,LCD_RS,LCD_RW,LCD_D[0..7]" the way it is in Eagle.

-Reece

On 04/15/18 22:39, Seth Hillbrand wrote:

Hi Jon-

The major issue I think we would need to address is migration.  I
don't think that only an ERC warning is sufficient in this case.
Users will rightfully expect that their old schematics will generate
valid netlists when opened in a newer KiCad.

One option here would be to translate the implicit net connections
into explicit ones when bus junctions are encountered.  Unfortunately,
I think that this feature is lightly used, so we might not get much
user feedback until they encounter problems and then the problems will
be very bad

An alternative might be to increase the functionality of the bus
junction. Spitballing here but we might add a "mapping table" dialog
that allowed the user to specify the winning name and mapping order.
That should address your points 2-3 although point 4 might be the
issue.  I think we could have a default mapping that follows the
expected convention but allow users to change it by double-clicking on
the junction and editing the mapping table.  Then previous users could
keep their functionality while still allowing the arbitrary member
arrays you are building.

Thoughts?
-S


2018-04-15 16:40 GMT-07:00 Jon Evans <j...@craftyjon.com
<mailto:j...@craftyjon.com>>:

     Hi all,

     I am proposing to remove some behavior from KiCad as part of my
     bus connections changes.  I know we generally don't remove
     features in new releases without good reason, but I think this is
     an exceptional case.

     The user manual describes a way in which you can connect multiple
     different buses together with junctions.  If you aren't already
     familiar with this behavior, please check out the manual:

http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buses-labels-power-ports



<http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buses-labels-power-ports>



     The section in question is called "Global connections between
     buses" and comes with the following image and describes how these
     bus wires with different labels are connected together:

     Allowing this kind of behavior is problematic for a number of
reasons:

     1. It means that net wires and bus wires behave differently, since
     net wires can't have more than one label.  This is potentially
     confusing for users.

     2. It means that junctions need a lot of special logic in order to
     resolve which "branch" of a bus is called what name (for example,
     what if one of those three branches in the above image didn't have
     a label? What would its nets be called?)

     3. Maybe most importantly, it breaks the label->netlist paradigm,
     since an electrical net will only have one label in the eventual
     netlist, and there is no way to determine which label should "win"

     4. I don't think there's a way to map this behavior onto the new
     bus system I have built that allows arbitrary bus members (instead
     of just a sequential vector) in a way that would make any sense to
     the user.

     My proposed changes in this area are as follows:

     1. Remove this section from the user manual.

     2. In my new connectivity algorithm, treat all connected bus wire
     segments as being part of the same bus (meaning they all will have
     the same "name")

     3. Add an ERC warning about having more than one label attached to
     a bus (the warning would appear in the case of the example picture
     above)

     4. Add a note to the user manual stating that this warning is new
     for 6.0

     The only downside that I can see in this approach is that any
     users who relied on this feature will suddenly get new ERC
   

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

[Reece R. Pollack]

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 this idea so a bus can contain another bus makes sense. Let's 
take an LCD display. In addition to the 4 or 8 data lines, there are 
several control lines that should be part of the bus. I want an LCD bus 
that contains LCD_E, LCD_RS, and LCD_RW as well as LCD_D[0..7]. And 
while I'm fantasizing, I want the bus name to be "LCD"; I do NOT want it 
named "LCD_E,LCD_RS,LCD_RW,LCD_D[0..7]" the way it is in Eagle.


-Reece

On 04/15/18 22:39, Seth Hillbrand wrote:

Hi Jon-

The major issue I think we would need to address is migration.  I 
don't think that only an ERC warning is sufficient in this case.  
Users will rightfully expect that their old schematics will generate 
valid netlists when opened in a newer KiCad.


One option here would be to translate the implicit net connections 
into explicit ones when bus junctions are encountered.  Unfortunately, 
I think that this feature is lightly used, so we might not get much 
user feedback until they encounter problems and then the problems will 
be very bad


An alternative might be to increase the functionality of the bus 
junction. Spitballing here but we might add a "mapping table" dialog 
that allowed the user to specify the winning name and mapping order.  
That should address your points 2-3 although point 4 might be the 
issue.  I think we could have a default mapping that follows the 
expected convention but allow users to change it by double-clicking on 
the junction and editing the mapping table.  Then previous users could 
keep their functionality while still allowing the arbitrary member 
arrays you are building.


Thoughts?
-S


2018-04-15 16:40 GMT-07:00 Jon Evans >:


Hi all,

I am proposing to remove some behavior from KiCad as part of my
bus connections changes.  I know we generally don't remove
features in new releases without good reason, but I think this is
an exceptional case.

The user manual describes a way in which you can connect multiple
different buses together with junctions.  If you aren't already
familiar with this behavior, please check out the manual:

http://docs.kicad-pcb.org/stable/en/eeschema.html#wires-buses-labels-power-ports



The section in question is called "Global connections between
buses" and comes with the following image and describes how these
bus wires with different labels are connected together:

Allowing this kind of behavior is problematic for a number of reasons:

1. It means that net wires and bus wires behave differently, since
net wires can't have more than one label.  This is potentially
confusing for users.

2. It means that junctions need a lot of special logic in order to
resolve which "branch" of a bus is called what name (for example,
what if one of those three branches in the above image didn't have
a label? What would its nets be called?)

3. Maybe most importantly, it breaks the label->netlist paradigm,
since an electrical net will only have one label in the eventual
netlist, and there is no way to determine which label should "win"

4. I don't think there's a way to map this behavior onto the new
bus system I have built that allows arbitrary bus members (instead
of just a sequential vector) in a way that would make any sense to
the user.

My proposed changes in this area are as follows:

1. Remove this section from the user manual.

2. In my new connectivity algorithm, treat all connected bus wire
segments as being part of the same bus (meaning they all will have
the same "name")

3. Add an ERC warning about having more than one label attached to
a bus (the warning would appear in the case of the example picture
above)

4. Add a note to the user manual stating that this warning is new
for 6.0

The only downside that I can see in this approach is that any
users who relied on this feature will suddenly get new ERC
warnings.  But I think that this is an "anti-feature" in that it
creates confusion instead of adding value, so we should nudge
anyone who uses it towards a different approach.

Anyone see any issues with this plan?

Thanks,
-Jon

___
Mailing list: https://launchpad.net/~kicad-developers

Post to     : kicad-developers@lists.launchpad.net

Unsubscribe : https://launchpad.net/~kicad-developers

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

[Reece R. Pollack]

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 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.

well, KiCad isn't installing "some there" and "all over" the various
systems. If you think so you have a impression that is different from
the reality.


The KiCad 4.0.7 Debian Linux package installs files in these
directories:

/etc/profile.d
/usr/bin
/usr/lib/kicad
/usr/lib/python2.7/dist-packages
/usr/share/applications
/usr/share/doc
/usr/share/icons
/usr/share/kicad
/usr/share/menu
/usr/share/mime
/usr/share/mimelnk

That's "spread all over the file system" in contrast to my
preference of having all installed files under one directory.


No, it is not, that i simply the unix/linux way or hatver the correct 
term is. You can just set the cmake install prefix or destdir when 
installing to /opt/kicad-foo and you get the same behaivour as with 
the xilinx tools. But this is not the topic of this thread, we should 
focus on the user config here.


Agreed, it is. I've been working almost exclusively in the Linux 
environment for the last 15 years of my career, including assembling 
distros from scratch. But the name conflicts make maintaining several 
versions concurrently rather difficult unless the application developers 
take care to support it.


Yes, I'm going a bit off the original topic. Maybe we should start a new 
thread. But I see an issue arising in the future where people are going 
to want to install V5 but not give up V4 quite yet. For example, board 
houses that accept KiCad board files may not be ready to make a hard cut 
to V5 until they're sure it's really ready, but they'd like to be able 
to accept V5 board files. Right now that would be difficult without 
compiling from source and installing in a separate directory.


I'd hate to see KiCad miss this chance to embrace multiple installation 
support just because we're thinking only of the testing environment.


-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] [RFC] Able to install KiCad stable and "daily build" in same computer

[Reece R. Pollack]

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 directory hierarchy
rather than being spread all over the filesystem.

well, KiCad isn't installing "some there" and "all over" the various
systems. If you think so you have a impression that is different from
the reality.


The KiCad 4.0.7 Debian Linux package installs files in these directories:

/etc/profile.d
/usr/bin
/usr/lib/kicad
/usr/lib/python2.7/dist-packages
/usr/share/applications
/usr/share/doc
/usr/share/icons
/usr/share/kicad
/usr/share/menu
/usr/share/mime
/usr/share/mimelnk

That's "spread all over the file system" in contrast to my preference of 
having all installed files under one directory.


But as I said, putting everything under one directory hierarchy (for 
example, "/opt/kicad5") would be a significant change in behavior. A 
reasonable alternative is to install using file and directory names 
which include the major version number. Thus


/usr/bin/kicad4
/usr/bin/kicad5

and

/usr/lib/kicad4/plugins/
/usr/lib/kicad5/plugins/

I could even accept keeping the V4 file and directory names as they are 
and merely appending a 5 to the new files and directories.



This is how Xilinx
ISE, Eagle, and many other packages are installed, and it makes it very
easy to keep multiple versions. This would be a major change in
strategy, though.

If all software projects would follow the common rules on the various
platform it would be easier for all. But especially Windows based
software follows often some "own" rules as it's simply possible.


I know many Windows programs install in self-contained directory 
hierarchies now, as the previous behavior of overwriting DLLs in shared 
directories caused major headaches. I do not develop for Windows, 
though, so I'll leave that to those who are more familiar with that 
environment.






Regardless, I agree that file names or paths should include the major
version number. The executable file "kicad" should be renamed "kicad5"
for V5. The directory under /usr/lib and /usr/share should be renamed
from "kicad" to "kicad5". And so on. Under Linux (or at least the
Debian-derived distros) the "update-alternatives" utility can be used to
select which version is run using the "kicad", "pcbnew", and "eeschema"
commands.

updates-alternatives has a different approach as you think. It's not
designated for this solution you think off.

http://williamdemeo.github.io/linux/update-alternatives.html


I'm well aware of the purpose of update-alternatives; I'm quite familiar 
with both its use and its implementation.


Allow me to quote from the first paragraph of the link you provide:

   Here are some notes on |update-alternatives| and some examples
   demonstrating its use. The purpose of the update-alternatives
   utility program is to manage, on a single machine, serveral versions
   of programs that all provide the same functionality.

That is exactly what we're doing here: managing several versions of 
programs that all provide the same functionality. Nothing in either the 
implementation nor the intent of update-alternatives requires that the 
different versions behave identically.


A common case in the life of a developer is to have multiple versions of 
the Gnu C/C++ compiler installed. Perhaps new development is done with 
the GCC-5 compiler so it is the default on a system, but when producing 
an update for older systems the GCC-4.8 version is used. The 
update-alternatives allows the system manager to configure the system so 
the "cc" command invokes the latest-and-greatest, but the older versions 
are accessible by using the full file name.


Here's the path the system follows to find the proper program to run for 
the "cc" command on my system:


   /usr/bin/cc -> /etc/alternatives/cc
   /etc/alternatives/cc -> /usr/bin/gcc
   /usr/bin/gcc -> gcc-5
   /usr/bin/gcc-5

Using update-alternatives properly would require renaming the V4 files 
to include the major version number, as well as naming the V5 file 
properly. Perhaps there could be a 4.0.8 release that does this for 
coexistence.


___
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] [RFC] Able to install KiCad stable and "daily build" in same computer

[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 directory hierarchy 
rather than being spread all over the filesystem. This is how Xilinx 
ISE, Eagle, and many other packages are installed, and it makes it very 
easy to keep multiple versions. This would be a major change in 
strategy, though.


Regardless, I agree that file names or paths should include the major 
version number. The executable file "kicad" should be renamed "kicad5" 
for V5. The directory under /usr/lib and /usr/share should be renamed 
from "kicad" to "kicad5". And so on. Under Linux (or at least the 
Debian-derived distros) the "update-alternatives" utility can be used to 
select which version is run using the "kicad", "pcbnew", and "eeschema" 
commands.


-Reece



On 04/12/18 06:39, Clemens Koller wrote:

I would pretty much vote to use the IMO more common naming scheme for major 
package versions:

kicad (the current one installed from the repository of your choice)
kicad4 (currently: 4.0.7)
kicad5 (currently: 5.0.0-rc2-dev...)
kicad6 (tbd.)

...avoiding the ".v5" i've seen lately.

I believe there is less demand for different minor versions installed next to 
each other, however it would be a nice-to-have.
(So... a user-selectable configuration might help: $ kicad -c projectconfig.cfg)

Regards,

Clemens

On 2018-04-12 09:33, Strontium wrote:

After considering my patch, what about the following proposal:

Just change the hard coded string in common.cpp (at around line 243) from:

cfgpath.AppendDir( wxT( "kicad" ) );

to

cfgpath.AppendDir( wxT( "kicad.v5" ) );

(or some other string)

Thats it.  Then Kicad Version 5 will have a unique configuration
directory that will not conflict with version 4.

If an end user wants to bring their kicad V4 configuration over to v5,
they just copy it themselves.  Otherwise it starts with a brand new
blank configuration.  Alternatively packaging might be able to copy it
over.  But i don't see any real need to do it for the user at that
stage.  Its just a complication.

Then when the development branch is forked, just rename this again to
something like:
cfgpath.AppendDir( wxT( "kicad.v6dev" ) );

(or whatever).

Then an end user can have V4, V5 and a Nightly all on the same machine
and configurations won't conflict.

Anything more exotic can be deferred to V6 development.

Steven




On 08/04/18 13:33, Carsten Schoenert wrote:

Am 07.04.18 um 17:34 schrieb Strontium:

Attached is a patch for discussion only.

Its the minimum change I could come up with to implement a unique
version specific config directory.

Nick mentioned changing XDG_CONFIG_HOME, that will not work on Windows
or Mac.
And on Linux, etc it will change from "~/.config/kicad" to
"~/somethingelse/kicad" which would work, but isn't a very friendly
naming scheme.

Changing XDG_CONFIG_HOME itself wouldn't be correct. XDG_CONFIG_HOME is
pointing to '$HOME/.config' and XDG_DATA_HOME is referencing to
$HOME/.local/share.

I'm sure Windows and Mac have similar variables for the folders that
should contain the logical same content.

The path to the KiCad user config must based on such variables plus the
preferred name for the config folder, so like kicad-5 (for KiCad5) and
kicad-6 (for future version KiCad6) and kicad-nightly (for devel
version). GTK is doing this for a long time.


$ find  ~/.config -type d -name gtk*
/home/carsten/.config/gtk-3.0
/home/carsten/.config/gtk-2.0

If KiCad will introduce some version specific user config and data
folders (which I appreciate to see) it will be needed to configured by
the build environment and not hard-coded in the binaries. The variables
can be overwritten with some additional value given while starting the
applications.

e.g.
take the default folders
$ kicad

override the setting for the default config etc.
$ KICAD_XDG_CONFIG_HOME=/my/special/folder kicad



___
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] Assertion failure in the Symbol Library Editor

[Reece R. Pollack]

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 instructions in the eeschema
documentation section 11.4.1 to transfer the 2N7002 part from the
Transistor_FET library to MyParts, renaming it in the process, but
the procedure doesn't work.
 2. I decided to load the 2N7002 part from the Transistor_FET library,
export the part as a file in /tmp, then import it into MyParts,
but it also copied the 2N7002 and BSS138 parts.
 3. I deleted the imported components.
 4. I attempted to revert the change entirely. I got a warning that
reverting was not undo-able, and I said OK. (Everything I care
about is backed up in a GIT repo on a server.)
 5. Kaboom! Okay, no kaboom. An "assertion failed" dialog box.




___
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] Assertion failure in the Symbol Library Editor

[Reece R. Pollack]

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, renaming it in the process, but the procedure
   doesn't work.
2. I decided to load the 2N7002 part from the Transistor_FET library,
   export the part as a file in /tmp, then import it into MyParts, but
   it also copied the 2N7002 and BSS138 parts.
3. I deleted the imported components.
4. I attempted to revert the change entirely. I got a warning that
   reverting was not undo-able, and I said OK. (Everything I care about
   is backed up in a GIT repo on a server.)
5. Kaboom! Okay, no kaboom. An "assertion failed" dialog box.

Don't freak out trying to find the referenced commit in git. I made a 
minor mod to pcbnew on a private branch, so there's a new commit id. 
Here's the last common commit:


   d1af521 Libedit: Fix a few places where item could be NULL


Application: kicad
Version: (5.0.0-rc2-dev-377-gc5012f9), release build
Libraries:
    wxWidgets 3.0.2
    libcurl/7.47.0 GnuTLS/3.4.10 zlib/1.2.8 libidn/1.32 librtmp/2.3
Platform: Linux 4.13.0-38-generic x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.2 (wchar_t,wx containers,compatible with 2.8) GTK+ 2.24
    Boost: 1.58.0
    Curl: 7.47.0
    Compiler: GCC 5.4.0 with C++ ABI 1009

Build settings:
    USE_WX_GRAPHICS_CONTEXT=OFF
    USE_WX_OVERLAY=OFF
    KICAD_SCRIPTING=ON
    KICAD_SCRIPTING_MODULES=ON
    KICAD_SCRIPTING_WXPYTHON=ON
    KICAD_SCRIPTING_ACTION_MENU=OFF
    BUILD_GITHUB_PLUGIN=ON
    KICAD_USE_OCE=ON
    KICAD_SPICE=ON

ASSERT INFO:

/home/reece/MyProjects/KiCad/src/eeschema/lib_edit_frame.cpp(1026): 
assert "m_my_part != aPart" failed in SetCurPart().


BACKTRACE:
[1] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, 
wxEvent&) const
[2] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)

[3] wxEventHashTable::HandleEvent(wxEvent&, wxEvtHandler*)
[4] wxEvtHandler::TryHereOnly(wxEvent&)
[5] wxEvtHandler::DoTryChain(wxEvent&)
[6] wxEvtHandler::ProcessEvent(wxEvent&)
[7] wxWindowBase::TryAfter(wxEvent&)
[8] wxWindowBase::TryAfter(wxEvent&)
[9] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[10] wxMenuBase::SendEvent(int, int)
[11] g_closure_invoke
[12] g_signal_emit_valist
[13] g_signal_emit
[14] gtk_widget_activate
[15] gtk_menu_shell_activate_item
[16] g_closure_invoke
[17] g_signal_emit_valist
[18] g_signal_emit
[19] gtk_propagate_event
[20] gtk_main_do_event
[21] g_main_context_dispatch
[22] g_main_context_iteration
[23] gtk_main_iteration
[24] wxWindow::DoPopupMenu(wxMenu*, int, int)
[25] wxWindowBase::PopupMenu(wxMenu*, int, int)
[26] wxAppConsoleBase::CallEventHandler(wxEvtHandler*, wxEventFunctor&, 
wxEvent&) const
[27] wxEvtHandler::ProcessEventIfMatchesId(wxEventTableEntryBase const&, 
wxEvtHandler*, wxEvent&)

[28] wxEvtHandler::SearchDynamicEventTable(wxEvent&)
[29] wxEvtHandler::TryHereOnly(wxEvent&)
[30] wxEvtHandler::ProcessEventLocally(wxEvent&)
[31] wxEvtHandler::ProcessEvent(wxEvent&)
[32] wxEvtHandler::SafelyProcessEvent(wxEvent&)
[33] g_closure_invoke
[34] g_signal_emit_valist
[35] g_signal_emit
[36] gtk_propagate_event
[37] gtk_main_do_event
[38] g_main_context_dispatch
[39] g_main_loop_run
[40] gtk_main
[41] wxGUIEventLoop::DoRun()
[42] wxEventLoopBase::Run()
[43] wxAppConsoleBase::MainLoop()
[44] APP_KICAD::OnRun()
[45] wxEntry(int&, wchar_t**)
[46] main
[47] __libc_start_main
[48] _start



___
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] Fixing libcommon

[Reece R. Pollack]

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 and orientation is selected in the Page
Settings. The user should be able to set the origin to a more
convenient location, such as a reference point on a PCB.
2. Allow the user to set the positive X and Y directions from that
reference point. This would allow a user to display Y-axis
coordinates increasing from bottom to top, or decreasing as it is now.

I want to accomplish these goals in a consistent manner across all
editors (Schematic, Footprint, and Layout) without causing major
revision to the internal representations.

Could this be integrated into the work your doing to handle internal
unit conversions?

-Reece

Hi Reece,

What I am planning is not really related to the features you mention.
Currently we have a few files that contain multiple #ifdef
PCBNEW/EESCHEMA/etc. and is compiled many times with different
definitions, which is not the right way to go.

The final goal is to make all files compile only once. To do so, I am
moving the code parts wrapped with ifdefs to corresponding applications.
It is a refactor, without adding any new features.

We had a plan for another refactor that could be more related to your
wishes. I can give you some details, if you are interested.

Regards,
Orson


I'm very interested in anything that would help me avoid duplicating 
effort or complicating planned development.


Thanks!

-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] Fixing libcommon

[Reece R. Pollack]

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 that are compiled multiple times. I
plan to fix them as well, but first I want to send the first patches to
see if we all agree on the proposed solution.

Alternatively, there could be an abstract class to provide conversion
methods. If it is preferred, then we need to decide how to access its
instance (singleton, attach to KiFace, static object?)

Ultimately we can have a real common library for all apps (libkicommon?)
that could be compiled as a shared library. Such approach should reduce
*.kiface files size and linking time.

Any thoughts?


I'm new to the dev list and haven't looked at the issue you're dealing 
with yet. However, I'm looking at an issue that may be related and we 
may want to consider as you make your changes.


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 and orientation is selected in the Page
   Settings. The user should be able to set the origin to a more
   convenient location, such as a reference point on a PCB.
2. Allow the user to set the positive X and Y directions from that
   reference point. This would allow a user to display Y-axis
   coordinates increasing from bottom to top, or decreasing as it is now.

I want to accomplish these goals in a consistent manner across all 
editors (Schematic, Footprint, and Layout) without causing major 
revision to the internal representations.


Could this be integrated into the work your doing to handle internal 
unit conversions?


-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