Re: [Kicad-developers] Auto-generated backup files: are they useful?

[hauptmech]

While I agree that it is not KiCad's job to do archival backups or 
version control, I do think that KiCad should preserve the integrity of 
users data through a crash. Even better if the work between the last 
save and the crash is also preserved and recovered on restart.


I have had to use the backup files to recover data in the past. I have 
no idea if that recovery was related to something that is now no longer 
a possible issue.



-Hauptmech


On 6/30/2020 7:23 AM, Jon Evans wrote:

Currently, KiCad automatically creates backups of schematic and PCB
files when you save a file.

The logic for these backups is basically: if a file already exists
with the same name as what we are saving, copy that file to a new file
and give it the "-bak" suffix on the file extension.

These backups are stored next to the original file in the current
KiCad codebase.  This understandably creates clutter that some people
don't like (myself included) so in the project-settings branch that is
about ready to be merged, I changed this behavior to place all these
backups in a special backups folder for the project.

This proved to have some complications around the handling of files
outside the project path (which it's possible to have with
hierarchical schematic sheets) so I need to do something else.

After some thought, I am pretty convinced that the right thing to do
is just *remove this backup feature entirely*.  Here's why:

1) It's not a very good backup:  It just stores the state from the
last time you hit "save".  If you hit save again, your backup is blown
up.  So, it's really like a "undo" function, but on disk, and with
only one level of undo.

2) Recently I changed how we save schematic and board files to fix
some unrelated issues people were seeing with cloud backup services.
Before this change, if KiCad crashed or had some other serious error
while saving a file, the file would be lost (because we used to delete
the old file and then write a new one in its place).  After this
change, we write the new file to a temporary location, and only if
that write succeeds do we copy it on top of the old file.  I think
this vulnerability to generating corrupt files if we crash was one of
the reasons for this backup file system, and that reason is now gone.

3) Because it's not a very good backup, I worry that the fact that
"bak" files exist might cause some users to have a false sense of
security and not use a true backup system (like a version control
system, or some other mechanism that actually backs up files
periodically).  I want to remove this false sense of security so that
it is more clear that users should back up their files in some way if
they care about the work.

In other words, I don't think this feature actually gives enough value
to make it worth the clutter in the project folder and/or the
development effort to make it work well with less clutter.

So, I'd like to hear from others on this: anyone disagree?

Thanks,
Jon

___
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] Pcbnew file format

[hauptmech]

Not requiring DR/DRC is appreciated.

Netclasses don't work with my designs on a fundamental level and if 
there were not a way I could ignore them, I would not be able to use 
KiCAD. Likewise the new interactive router which spends most of its time 
in Highlight Collisions mode with Allow DRC Violations. I use it 
normally when I can, but that's not very often.


The knowledge of the kicad developers of leading edge and specialist 
board design has consistently been limited and if you bake in that 
limited knowledge into DR/DRC with no fallback, you will shoot some 
users in the foot.


It doesn't need to be the old system but it does need to be free of 
assumptions about what is acceptable data for the manufacturer and what 
is acceptable practice for the designer.



On 5/07/2019 11:45 AM, Jeff Young wrote:

Hi Seth,

I was thinking about a similar issue which is that we probably can’t require 
users to move to the new DR system (as it will be considerably more technical). 
 So perhaps using the old system as defaults which can be overridden by the new 
makes sense.

Cheers,
Jeff.



On 4 Jul 2019, at 22:40, Seth Hillbrand  wrote:

Hi Jeff-

Ideally, I'd like to find an option that doesn't need to move twice during v6.  
Toward that goal, what if we moved edge_clearance to the defaults section?  
Until we implement the design rules and/or polygon-specific clearance, it 
simply controls everything.  Once we integrate the new features, they are 
allowed to override the default.

Thoughts?
-Seth

On 2019-07-04 12:07, Jeff Young wrote:

Looking through our current set of board setup properties, only
solder_mask_min_width would join edge_clearance in a design_rules
section.
Most of the other properties are either most-recently-used values
(zone_clearance, via_size, etc.) or true DRC values (uvias_allowed,
trace_min, etc.).
The outlier is max_error, which is mostly a performance vs beauty
trade-off, but _does_ affect the generated board.
So,
1) leave solder_mask_min_width and edge_clearance in setup for now
2) create a design_rules section for solder_mask_min_width and
edge_clearance
3) leave edge_clearance in the project file for now
I think I’d vote for (1) simply because I don’t know how (2) will
play with Jon’s stuff.  But the only one I don’t like is (3).
Cheers,
Jeff.

On 4 Jul 2019, at 15:42, Seth Hillbrand  wrote:
On 2019-07-04 09:24, Jeff Young wrote:
Since this is DRC, can we keep it in its current place until the DRC
manager goes in
Well, there’s DRC and there’s DR.  The other options really
control
only what is *checked*, whereas this one controls stuff *on* the
board.  Granted a lot of Jon’s rules will also fit into the DR
camp,
but I feel a little more reticent to move this one out.
Thoughts?
Jeff.

That's a valid point.  Ideally, I'd like to see this in a
"DesignRules" section.  Different manufacturers will have different
requirements here, so the DRC/DFM import would need to modify this
value.  The check also needs to allow separate values for internal vs.
external layers.
If we want to separate the generation from the checking, we might want
to put this setting in the zone parameters.  In which case, we might
use a global default setting that is used for new zones.
-Seth


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

[hauptmech]

Hi Tom,

On 23/06/2019 4:10 AM, Tomasz Wlostowski wrote:

On 22/06/2019 17:41, Reece R. Pollack wrote:

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.

I've never experienced a bug caused by mixing points/vectors together,
at least in the math code. For passing coordinates/measurements from/to
the GUI it might make sense to create custom types. Moreover, most if
not all geometry libraries I've known used the same class for points and
vectors. Single class for both is IMHO Occam's razor approach. As Seth
already remarked, I would like to hear a solid argument for splitting
point/vector classes, otherwise it looks like bikeshedding to me.


While it's cool that you have such a strong grasp of geometry operations 
and how they map to linear algebra, not everyone is at your level. 
Potential contributors to Kicad will have all sorts of backgrounds and 
be in the process of learning about geometry and or linear algebra. The 
math vector + geometric point VECTOR2 class technically works, but 
creates friction because to use it confidently one needs to read the 
class code and know a bit about how geometry operations are mapped to 
vector operations.


Splitting the classes into Vector, Point, and Delta (Spatial Vector), 
and restricting the behavior of each to match their math and geometry 
counterparts, will make it much easier for others to learn and come 
onboard.


Meanwhile, since you don't use spatial vectors erroneously, you won't 
see any new compiler errors, but people who are still learning about 
geometry will get useful feedback.


-Hauptmech



Tom

PS1. I'm surprised no one yet noticed the VECTOR2<> class has public x/y
  members, which is an unforgivable violation of the tenets of classical
OO design :-)

PS2. There are some more serious OOD violations in KiCad codebase. Would
anybody here volunteer to refactor the diamond in EDA_TEXT derivatives,
DRAWSEGMENT/EDGE_MODULE classes or global variables in eeschema?

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

[hauptmech]

Isn't Reece's original post the spec? In summary, the name VECTOR is 
confusing and the type structure could be expanded on to offer more 
compile time checks. He proposes a KiPoint and KiDelta, and describes 
their behavior clearly enough for anyone that does geometry 
calculations. What's missing from the spec?




On 23/06/2019 2: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.


-S

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

[hauptmech]

After reading through vector2d.h and matrix3x3.h, I agree with Reece 
more or less. There is ambiguity in the word vector, between math 
vectors, spatial vectors, and c++ vectors. Context implies that VECTOR2 
refers math vectors, but then MATRIX3x3 * VECTOR2 is allowed which 
violates expectations.  POINT2 and SE2 or HOMOGENEOUS2  would set 
expectations better.


If you are working with homogeneous coordinates and want to operate at 
the math vector & matrix level of abstraction (often my preference) then 
using a VECTOR3 would be clearer than hacking a VECTOR2.



-Hauptmech

On 22/06/2019 9:28 PM, Tomasz Wlostowski wrote:

On 22/06/2019 09:09, Greg Smith wrote:


I think the biggest point I am making is that, mathematically, a point
is identical to a vector from 0,0.


Hi Greg & Reece,

This is precisely the reason why we don't have separate point and vector
classes.

Tom

___
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

[hauptmech]

On 29/04/2019 12:52 AM, Jeff Young wrote:

3) Cut/copy/paste is now text-based over the system clipboard.  (This means you 
can also copy/paste between schematics, or even between your schematic and a 
text editor.)


I can't tell you how nice this sounds after opening schematics in a text 
editor to 'copy and paste' for so long. Looking forward to using it.



___
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] Feedback on 5.1

[hauptmech]

On 14/03/2019 8:16 AM, Ruth Ivimey-Cook wrote:



  3. Common: I am still frustrated that the key combinations for 
similar
 tasks are not the same. For example, to place a wire in schema, 
it's

 shift-W while in pcb it's shift-X.

We have so many accelerator and hot keys assigned that it's getting
difficult to make changes but we can take a look at this one. It
probably makes sense to unify these even though they are referred to as
different operations in the schematic (wire) and board (route) editors.


I have similar issues with the duplicate action, which is sometimes 
'c', 'd', command-'d' and sometimes unavailable as a keystroke but 
present in the context menu.


My point about named shortcut/keymaps was aimed at making a unifying 
change easier; give the current keymap(s) a name - "Keycad 5" for 
example - and then make a new named "Kicad 6" keymap with the best 
bits of current but simplified and extended as appropriate. A simple 
keyap editor (would be surprised if that's not available open source 
somewhere) could then be used to adapt the shipped keymaps to the 
user's desire.


Thus someone who is used to the current setup doesn't have to change 
but can if they wish extend it as they desire. Someone coming in 
fresh, or ready to change, can try the new map and experiment. 



Except for the occasional mess-up by new developers adding new features, 
the shortcuts are customizable and the keymap file is easy to edit with 
a text editor if you don't like the interface provided in kicad.


My keymap for instance is unified and high frequency commands are all 
under my left hand so I don't have to look at the keyboard or remove my 
mouse hand to trigger actions. It allows me to work faster, but since 
there is no mnemonic (eg 'w' for wire) it requires effort to memorize 
and most casual users would not be happy with it.


If you work out a kicad unified keymap that works for you, I would 
encourage you to publish it on the kicad.info site. Usually for every 
issue voiced by a user, there are a bevy of users silently suffering.


I don't see why the developers would not include a unified keymap with 
the distribution that one could load using the keymap import.


___
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] V6 merge update

[hauptmech]

Many of the professional CAD packages do this and it makes collaboration 
with people that need to run an older version more difficult.



On 23/02/2019 10:48 AM, Simon Richter wrote:

Hi Seth,

On 22.02.19 18:11, Seth Hillbrand wrote:


It should be easier for new features as they don't need the wrap the
parsing in versioning checks; especially for semantic changes.  It may
be more effort when changing underlying structures that are shared
between parsers.

Would it make sense to have a separate "update" process, so the parser
in the loader will never have to deal with legacy files?

When the user opens a file with a lower version number, we branch into
an update wizard that handles updating the file, rewrites it as the new
version and then restarts the load process.

This way we could also keep the schematic element rescue outside of the
loader code.

Simon


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] V6 merge update

[hauptmech]

I have a patch for treating track clearance the same as track width. The 
user can already specify a track width that is an exception to the 
netclass width, and now do the same for clearance. ( 
https://youtu.be/05vfAvYwDio )


It's bitrotted for a year so I'd want an Ok before putting in the work 
to bring it up to date.


Thomasz raised a concern at the time on a related, smaller, patch:



- we are planning to overhaul the clearance/design rules system in V6.
Storing the clearance *DIRECTLY* for each track segment/via will
conflict with any more sophisticated design rule management system.


Noting that clearance is only stored on segments that are exceptions to 
the netclass (or whatever  DRM might be added); I disagree with this. 
Happy to discuss it if the concern remains.


I believe the patch functionality and UI changes would not overlap any 
design rules management system as it's focused on manual control of 
clearance only. Some (maybe all, I don't recall exactly) of the UI 
elements are only present when manual clearances are being used in the 
design so there is little impact on users that don't use it.


-Hauptmech




On 22/02/2019 9:21 AM, Wayne Stambaugh wrote:

Since we are nearing the 5.1.0 release, I want to get an idea of what
major merges are ready to go once 5.1 is branched.  I know Jon's netlist
code is ready to merge and I'm pretty sure that should be the first big
merge.  Does anyone else have any major changes they want to merge as
soon as v6 starts?  I would like to get an idea of what changes to
expect so we can avoid any serious merge chaos.  Please let me know what
you have in the queue so I can get an idea of how we should proceed with
the merges.

TIA,

Wayne

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] CERN Donation link?

[hauptmech]

Work packages going out to developers that would otherwise be working on 
something else during the work day are a good thing. That's good to hear.


The V6 donations page https://givetokicad.web.cern.ch/ could use an 
update. It's hard to tell whether the money is earmarked for V6 but not 
spent, went into V6 work that got shoehorned into V5, or got spent on V5 
as the pragmatic way to move things forward (though maybe not what 
donees were donating for).


The current impression (We collected and spent (600 hours completed) 
your money on V6 promises even though it's clear that we are still 
fighting fires on V5.0) is probably not going to be great for the next 
campaign.


On 26/11/2018 8:41 AM, Wayne Stambaugh wrote:

I cannot speak for CERN but I believe donations actually have quite a
bit of impact.  There are currently several v6 work packages that have
been drafted and developers have bid on the work.  This means the
developers will get paid to implement these features as part of the v6
development cycle which will help keep developers engaged.  Some of
these projects are fairly complex so asking skilled developers to do
this for free is asking a lot.  This would not be possible without
donations.

I've also seen a significant uptick in developer interest in KiCad over
the last two years which has significant accelerated KiCad development.
  I have no doubt that the possibility of getting paid increases the
interest in working on KiCad.

Would these features get developed any way?  Most likely but I am
confident that this would take much longer with an all volunteer
development team.  If you look at the most successful open source
project, almost without fail they have at least one paid full time
developer.

Cheers,

Wayne

On 11/24/2018 4:46 PM, hauptmech wrote:

Can anyone at CERN speak about what impact, if any, donations actually
have on their KiCAD work? The language around the donations page is
slippery AF and the last time I checked, intending to donate, I walked
away because I had no confidence that KiCAD would be affected.


On 25/11/2018 5:19 AM, Seth Hillbrand wrote:

Hi All-

Periodically, I meet people who are interested in supporting KiCad
financially.  Companies, I always redirect to Wayne and private
individuals I typically recommend donating through CERN. Currently, I
can't find a viable link on CERN's website for donating to KiCad.

https://givetokicad.web.cern.ch is not accepting donations and
https://giving.web.cern.ch/civicrm/contribute/transact?reset=1=12
doesn't have an option for KiCad.

Where should people be looking to make individual donations?

-S

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] CERN Donation link?

[hauptmech]

Can anyone at CERN speak about what impact, if any, donations actually 
have on their KiCAD work? The language around the donations page is 
slippery AF and the last time I checked, intending to donate, I walked 
away because I had no confidence that KiCAD would be affected.



On 25/11/2018 5:19 AM, Seth Hillbrand wrote:

Hi All-

Periodically, I meet people who are interested in supporting KiCad 
financially.  Companies, I always redirect to Wayne and private 
individuals I typically recommend donating through CERN. Currently, I 
can't find a viable link on CERN's website for donating to KiCad.


https://givetokicad.web.cern.ch is not accepting donations and 
https://giving.web.cern.ch/civicrm/contribute/transact?reset=1=12 
doesn't have an option for KiCad.


Where should people be looking to make individual donations?

-S

___
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] Add preferences dialog hotkey

[hauptmech]

I don't think my last post communicated what I wanted so I'll try again.

Michael chose ctrl+',' as the hotkey because it matches the Mac Human 
Interface Guidelines.

https://developer.apple.com/design/human-interface-guidelines/macos/user-interaction/keyboard/

On the Mac platform, starting with any other hotkey will cause problems 
with users.


It appears that the other platforms don't really specify a 
preferences/options/settings hotkey, and we need to work a bit harder to 
choose a hotkey but so far 100% of the people that care enough about 
this to suggest one have suggested something other than ctrl+','.


https://developer.gnome.org/hig/stable/keyboard-input.html.en
https://docs.microsoft.com/en-us/windows/uwp/design/input/keyboard-accelerators
https://docs.kde.org/trunk5/en/applications/fundamentals/kbd.html

I think this indicates the need to preload the user config directory 
with a platform specific hotkeys file.


Until then, ctrl+',' is the best choice in my opinion because it 
adversely affect the fewest number of people.




On 17/10/2018 11:00 AM, John Beard wrote:

Hi,

I'd suggest perhaps Ctrl-Shift-P, which is used by Inkscape. P with 
various modifiers is fairly common shortcut for preferences: 
https://defkey.com/search?irq=Preferences


I feel like Ctrl-, might be useful as paired hotkey with Ctrl-. (eg 
increase/decrease)?


Cheers,

John

On 16 October 2018 22:24:51 BST, Michael Kavanagh 
 wrote:


Hi,

Attached is a patch that assigns Ctrl+, (Cmd+, on Mac as per the HIG)
to opening the preferences dialog and adds the hotkey to all menu bar
menus.

Please note this causes a conflict with the "Interactive Router
Settings..." hotkey in Pcbnew (pcbnew/hotkeys.cpp line 275), so this
should be set to something else. I didn't know what to set it as so I
left it. Perhaps require shift or alt?

Also corrected the "hokey" typo throughout.

Cheers,
Michael



___
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] Add preferences dialog hotkey

[hauptmech]

This highlights the need for platform specific hotkey config files on 
install rather than relying on a single hard coded default. Nothing says 
cross-platform amateur hour more than having the software not be 
integrated with your platform at all.



On 17/10/2018 11:00 AM, John Beard wrote:

Hi,

I'd suggest perhaps Ctrl-Shift-P, which is used by Inkscape. P with 
various modifiers is fairly common shortcut for preferences: 
https://defkey.com/search?irq=Preferences


I feel like Ctrl-, might be useful as paired hotkey with Ctrl-. (eg 
increase/decrease)?


Cheers,

John

On 16 October 2018 22:24:51 BST, Michael Kavanagh 
 wrote:


Hi,

Attached is a patch that assigns Ctrl+, (Cmd+, on Mac as per the HIG)
to opening the preferences dialog and adds the hotkey to all menu bar
menus.

Please note this causes a conflict with the "Interactive Router
Settings..." hotkey in Pcbnew (pcbnew/hotkeys.cpp line 275), so this
should be set to something else. I didn't know what to set it as so I
left it. Perhaps require shift or alt?

Also corrected the "hokey" typo throughout.

Cheers,
Michael



___
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] Net selector

[hauptmech]

I strongly agree.

On 10/10/2018 10:16 PM, John Beard wrote:

Correct handling of focus, tab-traversal and so on is also important
for accessibility reasons, as well as being indicative of a coherent
UI in general. It's pretty annoying to be able to fill in almost all
of a dialog, but have controls fail to work at random.




___
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] DRC roadmap

[hauptmech]

Hi Seth,

I appreciate you sharing your thoughts on this, but it's long in the 
past. I shared the thread links with Wayne so he could see what 'not 
interested' looks like from this community members side. First post with 
no feedback on changing the TRACK object I figured people were busy. 
Second post with no feedback and I figured it was a no-go zone. The 
magnitude of the job touched a lot of points in the source but none of 
it hard. I would have been happy to implement a patch that satisfied the 
core devs. I was little disappointed at the time that I didn't get much 
interest, but otherwise no hard feelings.


I don't agree with you that I, or any other non-core developer, should 
be touching the roadmap. It's a priorities and goals document, a form 
letter so that Wayne and the core team do not have to repeat this info 
for every person that is new or only checks in occasionally. And the 
people achieving the goals should be removing them from the roadmap. It 
would take me days of combing through commits and posts to do what they 
could do in minutes. Not really a good use of time in my opinion.


I do want to mention that if you'd written this a year ago in response 
my original posts, it probably would have led me to persist a bit 
longer. I appreciate that.


Right now I have no time for development, no immediate need for arcs, 
and a big patch for clearances and fan-out that may well have bit-rotted 
into irrelevance by the time work on 6 starts.


Thanks for the reply.

-Hauptmech



On 2/09/18 03:57, Seth Hillbrand wrote:

Hello hauptmech-

I suspect that the tepid response you have received may be partially a 
result of the magnitude of doing this job well.  It touches many 
aspects of the PNS router, zone filling, connectivity, drc among 
others.  Without a clear, written plan first, it will be hard to say 
which aspects you are missing.  I suspect that this is why Tomasz gave 
you a list of definite prerequisites to a good implementation that 
would be accepted.  Now that these are mostly implemented in the code, 
you could use them to implement the next steps that Wayne listed below 
(Gerber plotting/DRC).


In other words, the responses you have received have given you 
suggestions for groundwork that will let us ensure the overall 
implementation fits in the project and can be supported in the future.


That said, if your primary interest in Altium import, you might have a 
look at the Eagle plugin that handles curved traces by approximating 
them with segments of straight traces.  This gets you everything 
except PNS support as PNS requires 45º increments at the moment.


On the roadmap, you are correct, it is out of date.  Please feel free 
to submit a patch to update them (clear the things that are 
accomplished, move missing v5 items onto v6) and then propose 
additions.  The files are located in Documentation/development.


Best-
Seth


Am Fr., 31. Aug. 2018 um 21:45 Uhr schrieb hauptmech 
mailto:hauptm...@gmail.com>>:


 On 1/09/18 00:44, Wayne Stambaugh wrote:


I don't ever remember myself or JP not being interested in round traces.
  It's just been a matter of priorities and manpower.

With arc tracks I had an itch to scratch and tried twice to get
core dev buy-in
(https://lists.launchpad.net/kicad-developers/msg27878.html,
https://lists.launchpad.net/kicad-developers/msg29877.html) so
that I could put together a patch that used an approach that would
get accepted. When suggesting options for modifying class TRACK I
got silence from the core devs and took the hint. C'est la vie.

I do remember
being pretty firm on ensuring that the gerber plotting and DRC are
correct before the drawing tools and file format changes go live.  The
reason for this should be obvious.  Fixing the DRC is in the v6 road map
so that would be the best place to start for someone who has a lot of
free time.


Why limit development to people that have a lot of free time?

The v6 roadmap has not been updated in a long time. What remains
to be fixed? Looking at the commit history to DRCish files, it
looks like there is plenty of activity going on. Can we ask those
people to touch the roadmap and update it?

There have been some ambitious ideas posted on this list about
what DRC needs to be, as well as bugs and blueprints. They are not
in the v6 roadmap. Should any of them be added?



The amount of work to implement this is not going to be
trivial and I will expect the design and quality of the DRC code changes
to be high.

Cheers,

Wayne


___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://l

Re: [Kicad-developers] DRC roadmap

[hauptmech]

On 1/09/18 22:40, Jeff Young wrote:


And then there’s the question of editing.  How do you drag tracks with 
curved corners?  Would one expect the PNS router to create curved 
tracks under some set of conditions?



I think you'd need a survey of the different uses.


Curved corners implies alternating line and arc segments to me. What I 
would do is have a corner radius setting. Constant during any drag. 
Dragging curved corner tracks would not be different than shark corner 
tracks, though the corner radius might force a track-to-neighbor 
distance larger than the clearance distance.


Allowing the existing arc tool to work on copper layers would handle the 
rest. I'd drag both endpoints plus a radius proxy (usually one drags the 
middle of the arc) instead of the current start, center, angle nodes.


I, myself, would not want the PNS to add curved tracks (different than 
curved corners) automatically.



___
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] DRC roadmap

[hauptmech]

 On 1/09/18 00:44, Wayne Stambaugh wrote:


I don't ever remember myself or JP not being interested in round traces.
  It's just been a matter of priorities and manpower.
With arc tracks I had an itch to scratch and tried twice to get core dev 
buy-in (https://lists.launchpad.net/kicad-developers/msg27878.html, 
https://lists.launchpad.net/kicad-developers/msg29877.html) so that I 
could put together a patch that used an approach that would get 
accepted. When suggesting options for modifying class TRACK I got 
silence from the core devs and took the hint. C'est la vie.

I do remember
being pretty firm on ensuring that the gerber plotting and DRC are
correct before the drawing tools and file format changes go live.  The
reason for this should be obvious.  Fixing the DRC is in the v6 road map
so that would be the best place to start for someone who has a lot of
free time.


Why limit development to people that have a lot of free time?

The v6 roadmap has not been updated in a long time. What remains to be 
fixed? Looking at the commit history to DRCish files, it looks like 
there is plenty of activity going on. Can we ask those people to touch 
the roadmap and update it?


There have been some ambitious ideas posted on this list about what DRC 
needs to be, as well as bugs and blueprints. They are not in the v6 
roadmap. Should any of them be added?




The amount of work to implement this is not going to be
trivial and I will expect the design and quality of the DRC code changes
to be high.

Cheers,

Wayne


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Round trace bends

[hauptmech]

I need bends as well (arc tracks). I check in occasionally on this 
topic. Last time I did, Thomasz summarized what was needed on the DRC 
side but there was no buy-in from Wayne or JP, and I was not going to 
start submitting patches for the TRACK object unless they are on board.


https://lists.launchpad.net/kicad-developers/msg29877.html



On 31/08/18 19:14, Martin Laabs wrote:

Hi,

is there is any development for chamfer trace edges ongoing? I use 
KiCAD frequently for RF designs and strongly miss the functionality to 
change 45°/90° bends to round ones.
If there is no development planned I would try it on my own or try to 
find a student implementing it for us.


Thank you,
 Martin Laabs

___
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] 5.1 UI feedback

[hauptmech]

Just a friendly reminder that net classes are not a good approach for 
some of us.


I have never used net classes because they make the assumption that one 
want's constant trace/space on a net.


Most of my boards these days are using components with BGA or LGA pad 
spacing tighter than I want to use for the rest of the board.


I have to keep all the new router features turned off so that I can lay 
down tracks which violate the default netclass (which I keep set at a 
medium trace/space so that my whole board is not laid out with the 
minimum space my manufacturers can do, the alternative to is adjust the 
default space as I go, but I find that I forget to change it back to the 
larger space too often).




On 17/07/18 04:56, jp charras wrote:

Moreover if (or when) netclasses will take in account the layers and the 
netclass management is more
powerful, I am guessing this setup will be frequently modified, so it deserves 
a easy and fast access.



___
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] Zone fillet radius limitation

[hauptmech]

It was 4000 previously.

https://github.com/KiCad/kicad-source-mirror/commit/1f50b2c7674e53e74dbd8595dac124785db2089b

This appears to be a useless limit. Can we remove it completely? The 
Poly fillet code correctly handles fillets that are (too) large.




On 7/07/18 12:41, Marcos Chaparro wrote:

Hi,
could we increase the radius limit for the zone fillets?

It currently is at 0.4 inch radius, its a rather arbitrary limitation, 
and when I try a workaround to make a copper arc zone, I type 15mm but 
I'm being limited to 10.14mm (0.4inch)


image.png

Its an easy fix, just change the max 400 mils to a higher value. 4000 
maybe?


#defineMAX_ZONE_CORNER_RADIUS_MILS400

https://github.com/KiCad/kicad-source-mirror/blob/b43dc7954ce1a76ff19581db02ca7c8d2cf5b4d2/pcbnew/zone_settings.h#L35

Cheers

Marcos


___
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] Documenting environment variables

[hauptmech]

Hi Eeli,

It's really cool you wrote this up. I encourage you to publish this as a 
blog article, or an informational post on kicad.info once you are happy 
with it. Ironically it's more likely to be read and used there than the 
official documentation.


-hauptmech

On 25/06/18 08:30, Eeli Kaikkonen wrote:
Thanks for the feedback. I don't feel need to aim this for the 
official documentation. I can of course host it where it is now or put 
it in a git service. And it certainly won't be "ready" for the 5.0 
release. Right now the factual content is the most important. It's 
meant to help especially those who need to change configurations for 
e.g. KiCad 4 + 5 combination, so I just keep it available and try to 
enhance it little by little. If I'll get comments, I'll gather and 
store them for future editing sessions. Possible factual errors I try 
to fix immediately.


Eeli Kaikkonen

su 24. kesäk. 2018 klo 22.56 Wayne Stambaugh (stambau...@gmail.com 
<mailto:stambau...@gmail.com>) kirjoitti:


Hi Eeli,

This is a good first start but it definitely needs some work
before it's
ready for the kicad documentation.  I don't see this being ready
for the
stable 5 release unless someone has some time to step up and clean up
the grammar and overly verbose writing.  I'm also not sure where this
document would live.  The KiCad documentation seems like a good
choice
but it also might be reasonable to break it into specific app related
pieces.

Cheers,

Wayne

On 06/23/2018 06:45 AM, Eeli Kaikkonen wrote:
> As I have said earlier, I have written a document about KiCad and
> environment variables. It ended up being larger than I expected. It
> handles even some tangential subjects and my style is verbose.
Still I
> hope it could be useful. I need feedback. Facts are of course
the most
> important, but I also take constructive criticism about the
content in
> general, structure and English grammar (I'm not a native speaker).
>
> It was suggested that maybe this could be added to the official
> documentation. I'm open to different possibilities. I'm ready to
convert
> the document to a different format.
>
> Here's the link:
>

https://docs.google.com/document/d/1Rq8i2Ay7qpGpffaj-AQmE-Xp88ikHhgyt0Ygpi8717o/edit?usp=sharing
>
> Eeli Kaikkonen
>
>
> ___
> Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
> Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
> More help   : https://help.launchpad.net/ListHelp
>

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-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] [PATCH] V5 upgrade documentation

[hauptmech]

Attached

On 24/06/18 02:46, Wayne Stambaugh wrote:

Hey hauptmech

For the most part I'm fine with these changes.  I think that the first
two paragraphs (sentences) in the "Schematic Symbol Libraries" section
of the version upgrade document could be merged into a single paragraph
since they are related.

If no one else objects to these changes, please create a merge request
and I'll merge them into my repo and push them upstream today or tomorrow.

Thanks for the help.

Cheers,

Wayne

On 06/23/2018 12:15 AM, hauptmech wrote:

Hi Wayne,

Really awesome that you are creating this documentation!

A couple thoughts:
* No one reads documentation unless they have to. Usually after stabbing
in the dark for a while.
* If one has to read documentation, one wants it short and to the point.
* Whatever basic knowledge you want the reader to have about how kicad
works, they won't have it.

With that in mind I did a little example editing with the following goals:

* Link to any info that is a requirement for understanding this
document. If you can't find any existing documentation to link to,
that's a good clue that we need to fill in more info locally.
* Leave out as many extra words as possible.

https://github.com/hauptmech/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc

https://github.com/hauptmech/kicad-doc/blob/master/src/eeschema/eeschema_symbol_library_table.adoc


It's not formatted as a patch because I only edited a few paragraphs,
and in those I rewrote things completely as an example of the above.




On 23/06/18 04:10, Wayne Stambaugh wrote:

I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
made it part of the KiCad documentation but I don't have a strong
opinion about where to add it.  This just seemed like the most logic
place.  Please review it when you get a chance.  If you find any issues
let me know, send me a patch, or submit a pull request against my doc
repo.  Keep in mind that this document is only to detail the changes
that will effect project compatibility with older versions of kicad and
the perils of symbol remapping.  Thanks in advance for the help.

Cheers,

Wayne

[1]:
https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc


___
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



>From 870401845b1bb785dcb7b3ff3d40bec185921ac4 Mon Sep 17 00:00:00 2001
From: Hauptmech 
Date: Sat, 23 Jun 2018 13:36:38 +1200
Subject: [PATCH] Simplify language and add some background info the reader may
 lack.
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.17.0"

This is a multi-part message in MIME format.
--2.17.0
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
 .../eeschema_symbol_library_table.adoc| 22 +++---
 src/kicad/kicad_upgrading_from_v4_to_v5.adoc  | 73 ++-
 2 files changed, 47 insertions(+), 48 deletions(-)


--2.17.0
Content-Type: text/x-patch; name="0001-Simplify-language-and-add-some-background-info-the-r.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Simplify-language-and-add-some-background-info-the-r.patch"

diff --git a/src/eeschema/eeschema_symbol_library_table.adoc b/src/eeschema/eeschema_symbol_library_table.adoc
index fc60bb42..18a3a753 100644
--- a/src/eeschema/eeschema_symbol_library_table.adoc
+++ b/src/eeschema/eeschema_symbol_library_table.adoc
@@ -1,14 +1,17 @@
 == Manage Symbol Libraries
 
-Symbol libraries need to be made available in order to create schematics.
-The manner in which this is accomplished varies according to the version
-of KiCad being used.
+Symbol libraries hold collections of symbols used when creating schematics. Each symbol
+in a schematic is uniquely identified by a full name that is composed of a library nickname
+and a symbol name. An example is `Audio:AD1853`.
 
 === Symbol Library Table
 
-As of November 2017, Eeschema uses a new library management tool based on
-*_symbol library tables_* which is identical in design to the footprint
-library table used in CvPcb and Pcbnew.
+The symbol library table holds a list of all library files KiCad knows about.
+The symbol l

[Kicad-developers] v4 -> v5 schematic conversion, symbol name corner case

[hauptmech]

Hi,

Is there anything in the schematic rescue or parsing code to handle the 
change in valid characters (removal of ':' and '/')?


An internal translation when reading a pre v5 symbol or library that 
translates all ':' to '' and '/' to '', would save the few 
miserable people who will get caught by this a lot of time.







___
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] Version 5 upgrade document review.

[hauptmech]

Hi Wayne,

Really awesome that you are creating this documentation!

A couple thoughts:
* No one reads documentation unless they have to. Usually after stabbing 
in the dark for a while.

* If one has to read documentation, one wants it short and to the point.
* Whatever basic knowledge you want the reader to have about how kicad 
works, they won't have it.


With that in mind I did a little example editing with the following goals:

* Link to any info that is a requirement for understanding this 
document. If you can't find any existing documentation to link to, 
that's a good clue that we need to fill in more info locally.

* Leave out as many extra words as possible.

https://github.com/hauptmech/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc
https://github.com/hauptmech/kicad-doc/blob/master/src/eeschema/eeschema_symbol_library_table.adoc

It's not formatted as a patch because I only edited a few paragraphs, 
and in those I rewrote things completely as an example of the above.





On 23/06/18 04:10, Wayne Stambaugh wrote:

I pushed the v5 upgrade document to my personal repo[1] on git hub.  I
made it part of the KiCad documentation but I don't have a strong
opinion about where to add it.  This just seemed like the most logic
place.  Please review it when you get a chance.  If you find any issues
let me know, send me a patch, or submit a pull request against my doc
repo.  Keep in mind that this document is only to detail the changes
that will effect project compatibility with older versions of kicad and
the perils of symbol remapping.  Thanks in advance for the help.

Cheers,

Wayne

[1]:
https://github.com/stambaughw/kicad-doc/blob/master/src/kicad/kicad_upgrading_from_v4_to_v5.adoc

___
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] Upgrading from V4 to V5 resources?

[hauptmech]

Please link to it from the symbol remapping dialogs so that it can be found.

Also, if there will be long form documentation in the user manual, the 
Remap symbols dialog info can be cleaned to something like:

"""
Symbol look up has changed and symbols must be remapped.

Backups of will be made in the folder "remap_backup" before remapping.

If you close the dialog, you must remap the symbols manually.

See http://kicad/manual/location for more details.
"""

Changing the button "Close" to "Skip" would also reduce confusion.

-hauptmech

On 18/06/18 05:05, Wayne Stambaugh wrote:

Adam,

AFAIK, there is not an upgrading reference but we should probably create
one.  Since the biggest change that has the potential to confuse users
is the symbol remapping, I will write a short document and add it to the
end of the KiCad users manual.

Cheers,

Wayne


On 06/17/2018 12:03 PM, Adam Wolf wrote:

Hi folks!

Do we have a good reference for users upgrading from V4 to V5, telling
them any important precautions they'll need to take, and maybe even
what they can expect to be different?  I would love to help to write
this for V6 but for V5 I am too swamped with macOS (but still
optimistic we can hit Wayne's current schedule).

If so, I would like to refer to this in the macOS README.

Adam

___
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] Resistor 2512 footprint [Kicad 4.07]

[hauptmech]

You should be able to check the footprint just by looking at it in a 
text editor or online. That will be faster than compiling Kicad.


https://github.com/KiCad/Resistors_SMD.pretty/blob/master/R_2512_HandSoldering.kicad_mod
https://github.com/KiCad/kicad-footprints/blob/master/Resistor_SMD.pretty/R_2512_6332Metric_Pad1.34x3.40mm_HandSolder.kicad_mod


On 4/04/18 09:56, Augusto Fraga Giachero wrote:

Sorry for the noise, I'll try to compile the Kicad 5 rc2 and check if
this issue persists in the new library.

Thanks,
Augusto Fraga Giachero.

Nick Østergaard writes:


The kicad-developers list is not really for detailed library discussions
like this. You may have better luck reporting the issue directly on
https://github.com/kicad/kicad-footprints/issues

I am not sure what the plan is, but I don't think the Librarians will
update the old footprints, all activity are done in the new repos.

http://kicad-pcb.org/post/kicad-official-libraries/

2018-04-03 23:33 GMT+02:00 Augusto Fraga Giachero :


Hi!

I've had a an unpleasant surprise with a 2512 (imperial) smd resistor
footprint (Resistors_SMD:R_2512_HandSoldering) available in the Kicad's
official library (shame on me for not checking the dimensions before
sending the gerbers). When our boards arrived we verified that the pads
of this footprint are too further apart, up to the point that the
resistor barely touches the pads.

I've looked on some datasheets and other sources and confirmed that this
footprint is out of the recommended dimensions
(http://www.resistorguide.com/resistor-sizes-and-packages/).

I've attached an image showing the dimensions from the website
above. The recommended dimensions for 2512 are a = 3.5mm, b = 1.6mm and
c = 3.8mm, while in the footprint available on Kicad a = 3.2mm, b =
2.7mm (no problems with this been wider as it is a hand soldering
variant) and c = 5.2mm.

Dim(mm) Average Kicad
a   3.5 3.2
b   1.6 2.7 (ok, hand soldering)
c   3.8 5.2 (too further apart)

I don't known if it is fixed in the new Kicad 5 libraries, but it would
be nice to be fixed in the legacy libraries as well. I can make the fix
if nobody have already made.

Thanks,
Augusto Fraga Giachero.


___
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] [PATCH] Fix for bug/1754049

[hauptmech]

No comments on the current discussion, it all makes sense. Just want to
point out a couple things in case they were missed.

The layers are being deleted (instead of disabled) to prevent DRC problems
and prevent file cruft, according to comments in the code.

kicad plugin is deleting layers from footprints when it saves a board by
omitting layers not enabled. If you think removing layers from footprints
is a bad idea, you will need to fix that.


>From a user point of view I would prefer layer setup to not delete
anything. I can use the global deletion tool to delete ghings if i need. If
there is DRC problems on a disabled layer, an exra note that the layer is
disabled in the drc message would help.

On Fri, 23 Mar 2018, 07:34 jp charras, <jp.char...@wanadoo.fr> wrote:

> Le 22/03/2018 à 18:48, Andrey Kuznetsov a écrit :
> > I thought we were talking about deleting layers, not disabling them?
>
> Both.
> The dialog disables layers.
> How to manage items living on disabled layers (considering they can live
> on more than one layer,
> like pads and keepout zones)?
>
> Currently, I certainly do not see this problem as fixed.
>
> >
> > I agree with Wayne, a footprint is a whole item, deleting part of it
> means it is no longer valid,
> > and thus must be removed.
> >
> > What if someone wants to remove the silkscreen layer because they don't
> want it for production? I
> > guess they can just delete the silk gerber before sending it in. I can't
> think of a reason someone
> > would want to delete a layer on a final product, without being able to
> do it through gerber files.
> > Otherwise deleting layers would be done during initial design stage
> where someone is trying to
> > figure out how many layers to have, but if they delete a top layer with
> all the SMDs on it, then
> > well, they should be warned about it, and if they choose to delete it,
> it's their fault and they
> > will have to undo or reimport all the items again.
>
> Plot files has its own layer list.
> Anyway, plot file list is not only the layers needed to make a board.
> Fabrication files are needed only for assembly.
> Gerber files are for making the board.
> Other files are for assembly/documentation, and are usually not in Gerber
> format.
>
> >
> > Disabling a layer should never delete existing objects.
>
> However this topic is about deleting objects living on disabled layers.
>
> >
> > On Thu, Mar 22, 2018 at 10:15 AM, jp charras <jp.char...@wanadoo.fr
> <mailto:jp.char...@wanadoo.fr>>
> > wrote:
> >
> > Le 21/03/2018 à 17:46, Wayne Stambaugh a écrit :
> > > JP,
> > >
> > > Did you take a look at this patch?  I know we have talked about
> this in
> > > the past and that the fix would not be easy.  Until we can define
> and
> > > implement a complete solution, this could be a short term fix.
> When you
> > > get a chance, please take a look at it an comment on it.
> > >
> > > hauptmech,
> > >
> > > I'm not sure about the idea of breaking a footprint (module) into
> layer
> > > by layer pieces to match the removed layers.  Footprints are
> typically
> > > thought of as atomic objects.  I wonder if it wouldn't be more
> prudent
> > > to remove the footprint if any of it's layers are removed from the
> layer
> > > list and warn the user that removing said layer(s) would result in
> > > footprints being removed.
> > >
> > > Thanks,
> > >
> > > Wayne
> > >
> >
> > I had a look at this patch.
> >
> > I do not think removing something to footprints already on board is
> a good idea.
> >
> > I understand other board items can or must be removed when disabling
> a layer, but removing something
> > to a footprint is breaking this footprint, that become no more
> reliable.
> >
> > What happens if later, a disabled layer like a silkscreen is
> re-enabled for some reason?
> > Footprints carefully designed are now broken.
> >
> > Like Seth, I am thinking disabling a layer (disabling is not
> deleting) should not modify footprints.
> >
> > Currently, the Layer Setup dialog can create issues because it
> allows disabling layers that are now
> > used in DRC (edge cuts, courtyard, and margin that should be used in
> V6 to create obstacles).
> > Some other layers are mandatory to make a board: solder mask, solder
> paste.
> > These layers should be *always* enabled.
> &g

Re: [Kicad-developers] [PATCH] Fix for bug/1754049

[hauptmech]

On 20/03/18 14:07, Seth Hillbrand wrote:



2018-03-19 17:18 GMT-07:00 hauptmech <hauptm...@gmail.com 
<mailto:hauptm...@gmail.com>>:


On 20/03/18 11:19, Seth Hillbrand wrote:

Hi hauptmech-

I disagree with your assessment of whether we should allow the
creation of broken boards.  I don't think that we should ever
allow KiCad to create a board that it cannot modify itself. Doing
this is to invite confusion and bug reports.


Seth I'd rather you say that you think this puts the board in a
broken state and you don't think we should do it. I'm ok  with
that. But when you summarize my assessment using your own framing
and then disagree with it, it makes it hard to work on this
objectively.


​That's fair.  Your phrasing is much better.  I'm sorry my statement 
misrepresented your assessment.

All good.


If you can update your patch to allow for fully-editable boards after 
removing layers, I'll have another look at it.


I'm not sure I can. I don't have any more free time for a while. You'll 
have to figure out which is worse, the bug as it is now or the patch as 
it is now.


I think allowing KiCad to delete/edit a module using only the remaining 
reference point is the best option if someone picks this bug up.





Best-
​S​



___
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] Fix for bug/1754049

[hauptmech]

On 20/03/18 11:19, Seth Hillbrand wrote:

Hi hauptmech-

I disagree with your assessment of whether we should allow the 
creation of broken boards.  I don't think that we should ever allow 
KiCad to create a board that it cannot modify itself.  Doing this is 
to invite confusion and bug reports.


Seth I'd rather you say that you think this puts the board in a broken 
state and you don't think we should do it. I'm ok  with that. But when 
you summarize my assessment using your own framing and then disagree 
with it, it makes it hard to work on this objectively.


I don't think leaving things as they are will result in broken boards. 
The boards will load and save cleanly until the GUI can catch up.


I think the best option of what you suggested is to allow selecting 
modules via the reference point. This allows selecting (via box select I 
presume) modules that have nothing showing on any visible layers. 
However, this is beyond what I am able to do for this patch.


I am able to implement either of the other two options suggested, 
deleting the module or preventing deletion of the layer. The layers are 
being deleted because of an issue with the DRC according to code 
comments, so preventing deletion may not have the affect that is desired.


I already said why I don't think deleting the modules are the way to go, 
however I am happy to implement whatever you guys want.


Were this work for version 6 I'd say that the kicad team really needs to 
rethink the setup layers dialog and how it fits into the workflow.


Anyway, let me know. I just got a pile of new work and would like to put 
this to rest.


I don't have an opinion as to which is preferable, deleting all of the 
module or preventing deletion of a selectable layer.  But either one 
will allow KiCad to edit the file later.  Alternatively, we might 
consider allowing KiCad to delete/edit a module using only the 
remaining reference point.


As it is, the patch resolves an issue and creates another.  I'd prefer 
we didn't kick the can down the road like this.


-S



2018-03-18 2:09 GMT-07:00 hauptmech <hauptm...@gmail.com 
<mailto:hauptm...@gmail.com>>:


Updated patch attached. Coding standard stuff fixed.

I took a second look at the case where all items in a module are
deleted.

I checked the parser and writer. In the case where all items are
deleted, the modules are still OK as far as reading and writing to
the file.

I don't think deleting the module is the right way to go. They are
on layers which cannot be deleted in the current implementation.

Most modules will have pads on the undeleteable layers, so they
will be fine.

For the case of someone with modules composed only of
non-top/bottom elements and who are messing with the layer setup
midway through the design, I think we should just leave it as it
is. Either they are a ninja doing things that kicad should stay
out of the way of  or they are a very confused beginner for whom a
little extra cruft in the file is the least of their problems.

    -hauptmech




On 15/03/18 05:17, Seth Hillbrand wrote:

Hi hautmech-

Looks good.  Two comments:

- Code style.  There are a couple of small issues: one line is
too long, there should be spaces in parentheses for
pad->GetParent()->Remove(pad) and no space before parentheses in
"if ( pad->GetLayerSet()..."

- We need to handle the case where all items in a module are
deleted.  Currently, the code will remove all items except the
value and reference.  This means that we can no longer select the
module in pcbnew to delete it. Either we need to fully delete the
module when the last selectable item is removed or we need to
keep sufficient information to allow the module to be selected
when the layers are re-enabled.

Best-
Seth

2018-03-14 2:54 GMT-07:00 hauptmech <hauptm...@gmail.com
<mailto:hauptm...@gmail.com>>:

https://bugs.launchpad.net/kicad/+bug/1754049
<https://bugs.launchpad.net/kicad/+bug/1754049>

This patch follows the edict (stated in
dialog_layers_setup.cpp) that items on a layer that is
removed must be deleted.



___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>







___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https:/

Re: [Kicad-developers] [PATCH] Fix for bug/1754049

[hauptmech]

Updated patch attached. Coding standard stuff fixed.

I took a second look at the case where all items in a module are deleted.

I checked the parser and writer. In the case where all items are 
deleted, the modules are still OK as far as reading and writing to the file.


I don't think deleting the module is the right way to go. They are on 
layers which cannot be deleted in the current implementation.


Most modules will have pads on the undeleteable layers, so they will be 
fine.


For the case of someone with modules composed only of non-top/bottom 
elements and who are messing with the layer setup midway through the 
design, I think we should just leave it as it is. Either they are a 
ninja doing things that kicad should stay out of the way of  or they are 
a very confused beginner for whom a little extra cruft in the file is 
the least of their problems.


-hauptmech



On 15/03/18 05:17, Seth Hillbrand wrote:

Hi hautmech-

Looks good. Two comments:

- Code style. There are a couple of small issues: one line is too 
long, there should be spaces in parentheses for 
pad->GetParent()->Remove(pad) and no space before parentheses in "if ( 
pad->GetLayerSet()..."


- We need to handle the case where all items in a module are deleted. 
Currently, the code will remove all items except the value and 
reference.  This means that we can no longer select the module in 
pcbnew to delete it.  Either we need to fully delete the module when 
the last selectable item is removed or we need to keep sufficient 
information to allow the module to be selected when the layers are 
re-enabled.


Best-
Seth

2018-03-14 2:54 GMT-07:00 hauptmech <hauptm...@gmail.com 
<mailto:hauptm...@gmail.com>>:


https://bugs.launchpad.net/kicad/+bug/1754049
<https://bugs.launchpad.net/kicad/+bug/1754049>

This patch follows the edict (stated in dialog_layers_setup.cpp)
that items on a layer that is removed must be deleted.



___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>




>From a1dee36c3f0fde28646d5448d7aacd25996e159d Mon Sep 17 00:00:00 2001
From: hauptmech <hauptm...@gmail.com>
Date: Wed, 14 Mar 2018 22:31:59 +1300
Subject: [PATCH] Fix Layer setup can be changed leading to data loss Edit
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


Check for items inside modules and delete them if they belong to the layer we are removing.
Pads get the offending layer removed from their layers list and deleted if they have no more layers.

Fixes: lp:1754049
https://bugs.launchpad.net/kicad/+bug/1754049
---
 pcbnew/collectors.cpp  | 14 +-
 pcbnew/dialogs/dialog_layers_setup.cpp | 27 ++-
 2 files changed, 39 insertions(+), 2 deletions(-)


--2.16.2
Content-Type: text/x-patch; name="0001-Fix-Layer-setup-can-be-changed-leading-to-data-loss-.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-Layer-setup-can-be-changed-leading-to-data-loss-.patch"

diff --git a/pcbnew/collectors.cpp b/pcbnew/collectors.cpp
index 2219886c2..6e1477f52 100644
--- a/pcbnew/collectors.cpp
+++ b/pcbnew/collectors.cpp
@@ -65,6 +65,9 @@ const KICAD_T GENERAL_COLLECTOR::BoardLevelItems[] = {
 PCB_VIA_T,
 PCB_TRACE_T,
 PCB_MODULE_T,
+PCB_MODULE_TEXT_T,
+PCB_MODULE_EDGE_T,
+PCB_PAD_T,
 PCB_ZONE_T,
 PCB_ZONE_AREA_T,
 EOT
@@ -499,7 +502,16 @@ SEARCH_RESULT PCB_LAYER_COLLECTOR::Inspect( EDA_ITEM* testItem, void* testData )
 {
 BOARD_ITEM* item = (BOARD_ITEM*) testItem;
 
-if( item->GetLayer() == m_layer_id )
+if( item->Type() == PCB_PAD_T )
+{
+D_PAD* pad = nullptr;
+
+wxASSERT( !pad );
+pad = static_cast<D_PAD*>( item );
+if( pad->GetLayerSet()[m_layer_id] )
+Append( testItem );
+}
+else if( item->GetLayer() == m_layer_id )
 Append( testItem );
 
 return SEARCH_CONTINUE;
diff --git a/pcbnew/dialogs/dialog_layers_setup.cpp b/pcbnew/dialogs/dialog_layers_setup.cpp
index 28b4d2d33..0c9817b2e 100644
--- a/pcbnew/dialogs/dialog_layers_setup.cpp
+++ b/pcbnew/dialogs/dialog_layers_setup.cpp
@@ -35,6 +35,7 @@
 #include 
 
 #include 
+#include 
 
 
 // some define to choose how copper layers widgets are shown
@@ -655,7 +656,31 @@ bool DIALOG_LAYERS_S

Re: [Kicad-developers] Feedback on 6.0 work

[hauptmech]

On 18/03/18 03:58, Thomas Pointhuber wrote:

I would hide the text properties (with the exception of Show) by
default. I don't think many people would change for example the position
or orientation using this dialog. Every text attribute also has its own
menu as well which can be used for editing. Instead use the gained space
to add a footprint preview as it was developed for the symbol chooser.
It's annoying to first click on the footprint row to be able to
view/change it.


I agree.


___
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] - File format shim for clearance data

[hauptmech]

While i would still like to see this (my) shim go in, I agree with wayne.
Until/unless a less brittle approach is used for the parser, it's better to
signal a problem painfully and maintain the integrity of the file.

I have to admit that when i first heard the s-expressions idea I assumed
that the intention was to use a lisp like virtual machine for loading and
maintaining design data. I've used vm's for data storage before (lua and
python), and it's great. Parsing is free and you can jam in functions and
other data when needed.



On 17 Mar 2018 07:17, "Jeff Young" <j...@rokeby.ie> wrote:

> Hi Wayne,
>
> Patch reverted.
>
> However, I think your concern is misplaced.  If we want to prevent
> dataloss (ie: from reading a 6.0 file into 5.0), then we should warn the
> user based on the version string (and give them a chance to say “I still
> want to open”).
>
> But either way, actually failing to read the file leaves the user in a
> pickle (especially when it’s easy enough for them to try out a nightly that
> may very well be ahead of their stable).
>
> (And for that reason I think it’s important to put it into 5.0, as
> otherwise it won’t help until we start making 7.0 file format changes.)
>
> Cheers,
> Jeff.
>
> > On 16 Mar 2018, at 18:00, Wayne Stambaugh <stambau...@gmail.com> wrote:
> >
> > Jeff,
> >
> > Please revert this patch.  Any changes to the board file parser and/or
> > formatter need to be discussed before the changes are committed.  It has
> > been the intention that the board parser be pendantic by design to
> > prevent data loss by ignoring unknown formatting.  Allowing anything
> > outside of the expected formatting in the board file is not something
> > that I want to introduce without some discussion.  Even should we decide
> > to accept this patch, I would prefer we put it off until v6.
> >
> > That being said, the patch fails to build on windows with following
> error:
> >
> > C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp: In
> > member function 'void PCB_PARSER::parseUnknown()':
> > C:/msys64/home/wstambaugh/src/kicad-trunk/pcbnew/pcb_parser.cpp:1269:12:
> > error: request for member 'LogText' in '__acrt_iob_func(2)', which is of
> > pointer type  FILE* {aka _iobuf*}' (maybe you meant to use '->' ?)
> > stderr.LogText( msg );
> >^~~
> >
> > Cheers,
> >
> > Wayne
> >
> > On 3/16/2018 1:08 PM, Jeff Young wrote:
> >> Perhaps somewhat germane to this discussion I have removed the
> strict-format nags from the PCB parser.  It now logs warnings to stderr but
> otherwise ignores structures it doesn’t understand.
> >>
> >> I’m not sure that helps hauptmech much as if the file is subsequently
> written the unknown markup will be lost, but I thought I’d mention it.
> >>
> >> Cheers,
> >> Jeff.
> >>
> >>> On 7 Mar 2018, at 20:12, hauptmech <hauptm...@gmail.com> wrote:
> >>>
> >>> Hi Thomasz,
> >>>
> >>> I hope I'm able to address you concerns. I'm stuck using kicad stable
> in many situations. I brought clearances up for discussion last July but no
> one moved on it, nor are they required to. Clearance management is a major
> pain point for me so I wrote a fix. This patch will let us (me and the
> people I collaborate with) work using version 5, but open and close files
> written with a version patched with clearance handling code.
> >>>
> >>> I believe that code exactly like this will go into version 6. Getting
> it in earlier makes a huge difference to me, so I'm submitting it.
> >>>
> >>> On 07/03/18 23:30, Tomasz Wlostowski wrote:
> >>>> Hi hauptmech,
> >>>>
> >>>> I'm sorry but IMHO we can't accept your patch:
> >>>> - it changes the file format while we are already in feature freeze.
> >>>> This is a way too big change to accept for the V5.
> >>>
> >>> This patch simply adds tokens to the file format. No clearance data is
> saved for files that use the netclass only. Files without clearance tokens
> continue to remain without them.
> >>>
> >>> Yes it is a backward compatible file format change, but it does no
> harm to V5 files already in the wild.
> >>>
> >>>> - we are planning to overhaul the clearance/design rules system in V6.
> >>>> Storing the clearance *DIRECTLY* for each track segment/via will
> >>>> conflict with any more sophisticated design rule management system.
> >>>>
> >>> 

Re: [Kicad-developers] [PATCH] Fix for bug/1754049

[hauptmech]

On 15 Mar 2018 05:17, "Seth Hillbrand" <seth.hillbr...@gmail.com> wrote:

Hi hautmech-

Looks good.  Two comments:

- Code style.  There are a couple of small issues: one line is too long,
there should be spaces in parentheses for pad->GetParent()->Remove(pad) and
no space before parentheses in "if ( pad->GetLayerSet()..."


Thanks, I'll fix that.


- We need to handle the case where all items in a module are deleted.
Currently, the code will remove all items except the value and reference.
This means that we can no longer select the module in pcbnew to delete it.
Either we need to fully delete the module when the last selectable item is
removed or we need to keep sufficient information to allow the module to be
selected when the layers are re-enabled.


Is there a preferred approach?

If we don't delete it, then we need to keep the minimum valid info to round
trip to the file (need to check what this is) rather than worry about if it
is selectable, no? UI functionality always lags the internal and external
tools...


Best-
Seth

2018-03-14 2:54 GMT-07:00 hauptmech <hauptm...@gmail.com>:

> https://bugs.launchpad.net/kicad/+bug/1754049
>
> This patch follows the edict (stated in dialog_layers_setup.cpp) that
> items on a layer that is removed must be deleted.
>
>
>
> ___
> 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] [PATCH] Fix for bug/1754049

[hauptmech]

https://bugs.launchpad.net/kicad/+bug/1754049

This patch follows the edict (stated in dialog_layers_setup.cpp) that items
on a layer that is removed must be deleted.
From 2a77ec7609cccf70f17d7e830237006c1d72d528 Mon Sep 17 00:00:00 2001
From: hauptmech <hauptm...@gmail.com>
Date: Wed, 14 Mar 2018 22:31:59 +1300
Subject: [PATCH] Fix Layer setup can be changed leading to data loss Edit
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


Check for items inside modules and delete them if they belong to the layer we are removing.
Pads get the offending layer removed from their layers list and deleted if they have no more layers.

Fixes: lp:1754049
https://bugs.launchpad.net/kicad/+bug/1754049
---
 pcbnew/collectors.cpp  | 14 +-
 pcbnew/dialogs/dialog_layers_setup.cpp | 26 +-
 2 files changed, 38 insertions(+), 2 deletions(-)


--2.16.2
Content-Type: text/x-patch; name="0001-Fix-Layer-setup-can-be-changed-leading-to-data-loss-.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-Layer-setup-can-be-changed-leading-to-data-loss-.patch"

diff --git a/pcbnew/collectors.cpp b/pcbnew/collectors.cpp
index 2219886c2..a19efbdd7 100644
--- a/pcbnew/collectors.cpp
+++ b/pcbnew/collectors.cpp
@@ -65,6 +65,9 @@ const KICAD_T GENERAL_COLLECTOR::BoardLevelItems[] = {
 PCB_VIA_T,
 PCB_TRACE_T,
 PCB_MODULE_T,
+PCB_MODULE_TEXT_T,
+PCB_MODULE_EDGE_T,
+PCB_PAD_T,
 PCB_ZONE_T,
 PCB_ZONE_AREA_T,
 EOT
@@ -499,7 +502,16 @@ SEARCH_RESULT PCB_LAYER_COLLECTOR::Inspect( EDA_ITEM* testItem, void* testData )
 {
 BOARD_ITEM* item = (BOARD_ITEM*) testItem;
 
-if( item->GetLayer() == m_layer_id )
+if( item->Type() == PCB_PAD_T )
+{
+D_PAD* pad = nullptr;
+
+wxASSERT( !pad );
+pad = static_cast<D_PAD*>( item );
+if ( pad->GetLayerSet()[m_layer_id] )
+Append( testItem );
+}
+else if( item->GetLayer() == m_layer_id )
 Append( testItem );
 
 return SEARCH_CONTINUE;
diff --git a/pcbnew/dialogs/dialog_layers_setup.cpp b/pcbnew/dialogs/dialog_layers_setup.cpp
index 28b4d2d33..a62fe5645 100644
--- a/pcbnew/dialogs/dialog_layers_setup.cpp
+++ b/pcbnew/dialogs/dialog_layers_setup.cpp
@@ -35,6 +35,7 @@
 #include 
 
 #include 
+#include 
 
 
 // some define to choose how copper layers widgets are shown
@@ -655,7 +656,30 @@ bool DIALOG_LAYERS_SETUP::TransferDataFromWindow()
 if( collector.GetCount() != 0 )
 {
 for( int i = 0; i < collector.GetCount(); i++ )
-m_pcb->Remove( collector[i] );
+if( collector[i]->Type() == PCB_PAD_T )
+{
+//pads are multi-layer items that need to be handled specially
+D_PAD* pad = nullptr;
+
+wxASSERT( !pad );
+pad = static_cast<D_PAD*>( collector[i] );
+pad->SetLayerSet( pad->GetLayerSet().set( layer_id, false ) );
+if( pad->GetLayerSet().count() == 0 )
+pad->GetParent()->Remove(pad);
+}
+else if( collector[i]->Type() == PCB_MODULE_TEXT_T )
+{
+if( static_cast<TEXTE_MODULE*>( collector[i] )->GetType() == TEXTE_MODULE::TEXT_is_DIVERS )
+collector[i]->GetParent()->Remove( collector[i] );
+}
+else if( collector[i]->Type() == PCB_MODULE_EDGE_T )
+{
+collector[i]->GetParent()->Remove( collector[i] );
+}
+else
+{
+m_pcb->Remove( collector[i] );
+}
 }
 }
 }

--2.16.2--


___
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] Why do current nightlies report that they are kicad 5.0.0-rc2?

[hauptmech]

I would not change anything. As long as your version increments as 
documented, there is no problem. But if you change that by jumping 
backwards, you create an exception that has the opportunity to bite people.


So what if you skipped RC1 in your version string (and therefore in your 
development sequence). It's just a number.


On 14/03/18 05:49, Wayne Stambaugh wrote:

To prevent version issues for packagers, I will remove the -rc2 tag from
the source repo and change the default (when git is not found) version
string to 5.0.0-rc1-unknown to indicate that the version is somewhere
between rc1 and rc2.  I don't know that this makes things any clearer or
not but I'm pretty sure no matter what we do, someone will be confused.
I'm not really interested in making the cmake version string code any
more complicated so unless there are some options to `git describe` that
would make things clearer, I'm going to stick with the current code.

On 3/13/2018 12:18 PM, Carsten Schoenert wrote:

Am 13.03.2018 um 17:05 schrieb Eeli Kaikkonen:

2018-03-13 17:44 GMT+02:00 Jon Evans :


I know what the G means, just wish git describe had an option to disable
it, since it makes copy/paste more tedious.

I think if we had left the tag at rc1, then we'd just have users thinking
they had rc1 when they really have a newer nightly. Better to make a new
tag that doesn't include rcN in it, or at least tries to make it a lot more
obvious that it isn't a RC version despite having those letters in the
string.


In a project where I took part in we solved a similar problem by using
{previous-tagged-version-number}+{version-control-reference}, for example
5.0RC1+gitX. We felt the plus sign is less ambiguous.

That would be the correct way and done by a lot of projects.

The now additional tag -rc2-dev makes it more difficult for
distributions to determine if a new version is available.

-rc2* is greater as -rc1 and I'd need to tune the watch file again in
Debian we use (and it's already a bit more complicated due the dfsg + rc
part). The added tag -rc2-dev solves nothing and shouldn't be used in
future situations.


___
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] Volunteer

[hauptmech]

Thanks, at first glance it looked like the work there was fast and 
furious with devs working on bugs without formally grabbing the 
assignment, so I was afraid of stepping on toes.


On 13/03/18 11:59, Nick Østergaard wrote:
If you have a hard time to find a bug worth looking at, you could 
probably have a look at 
https://launchpad.net/kicad/+milestone/5.0.0-rc2 and pick one where no 
one is assigned.


2018-03-12 23:38 GMT+01:00 Jeff Young <j...@rokeby.ie 
<mailto:j...@rokeby.ie>>:


I threw one your way, but it would also be handy to know what
platform you’re on, as some of them are platform-specific.

Cheers,
Jeff.


> On 12 Mar 2018, at 22:07, hauptmech <hauptm...@gmail.com
<mailto:hauptm...@gmail.com>> wrote:
>
> I'm able to do some work on v5-rc bugs. I'm reasonably familiar
with all corners of the code. Bugs where the desired results are
clear from the bug discussion are probably best. Just assign them
to me on launchpad and I'll get to work.
> ___
> Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
> Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
> Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
> More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>


___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<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] Volunteer

[hauptmech]

Linux (Arch, though Ubuntu LTS is always on a partition nearby). I have 
the other platforms on my desk but don't have a kicad build set up on 
them, nor do I know much about their build/wx related quirks.



On 13/03/18 11:38, Jeff Young wrote:

I threw one your way, but it would also be handy to know what platform you’re 
on, as some of them are platform-specific.

Cheers,
Jeff.



On 12 Mar 2018, at 22:07, hauptmech <hauptm...@gmail.com> wrote:

I'm able to do some work on v5-rc bugs. I'm reasonably familiar with all 
corners of the code. Bugs where the desired results are clear from the bug 
discussion are probably best. Just assign them to me on launchpad and I'll get 
to work.
___
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] Volunteer

[hauptmech]

I'm able to do some work on v5-rc bugs. I'm reasonably familiar with all
corners of the code. Bugs where the desired results are clear from the bug
discussion are probably best. Just assign them to me on launchpad and I'll
get to work.
___
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] - Symbol Table Reference column fix

[hauptmech]

Oops, gotta set git diff to highlight that. Thanks!

On 9/03/18 15:00, Jon Evans wrote:
Works for me, although your comments have tabs instead of spaces in 
front.  I fixed this and committed your patch.  Thanks!


On Thu, Mar 8, 2018 at 8:49 PM, hauptmech <hauptm...@gmail.com 
<mailto:hauptm...@gmail.com>> wrote:


https://bugs.launchpad.net/kicad/+bug/1753330
<https://bugs.launchpad.net/kicad/+bug/1753330>

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<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] [PATCH] - Symbol Table Reference column fix

[hauptmech]

https://bugs.launchpad.net/kicad/+bug/1753330
From 5094bf1e3f38ea7f67e7adf79c7bf7c4ab3b2114 Mon Sep 17 00:00:00 2001
From: hauptmech <hauptm...@gmail.com>
Date: Fri, 9 Mar 2018 14:44:20 +1300
Subject: [PATCH] Use fixed width on first Symbol Table column
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


Autosize when the reference field is a list of all components was too long.

Fixes: lp:1753330
https://bugs.launchpad.net/kicad/+bug/1753330
---
 eeschema/dialogs/dialog_fields_editor_global.cpp | 10 +-
 1 file changed, 9 insertions(+), 1 deletion(-)


--2.16.2
Content-Type: text/x-patch; name="0001-Use-fixed-width-on-first-Symbol-Table-column.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Use-fixed-width-on-first-Symbol-Table-column.patch"

diff --git a/eeschema/dialogs/dialog_fields_editor_global.cpp b/eeschema/dialogs/dialog_fields_editor_global.cpp
index a5b679eae..2d630bb78 100644
--- a/eeschema/dialogs/dialog_fields_editor_global.cpp
+++ b/eeschema/dialogs/dialog_fields_editor_global.cpp
@@ -84,8 +84,16 @@ DIALOG_FIELDS_EDITOR_GLOBAL::DIALOG_FIELDS_EDITOR_GLOBAL( SCH_EDIT_FRAME* parent
 sortColumn->SetWidth( wxCOL_WIDTH_AUTOSIZE );
 sortColumn->SetResizeable( false );
 
+
+	// Reference column is either single reference or a list of references.
+	// Autosize can fill the window in the case of a list so use a fixed width.
+	// wxCOL_WIDTH_DEFAULT is wxDVC_DEFAULT_WIDTH on all platforms and too small.
+auto refcol = m_bomView->GetColumn( 0 );
+refcol->SetWidth( wxDVC_DEFAULT_WIDTH * 2 );
+refcol->SetResizeable( true );
+
 // Set default column widths for BOM table
-for( unsigned int ii = 0; ii < m_bomView->GetColumnCount(); ii++ )
+for( unsigned int ii = 1; ii < m_bomView->GetColumnCount(); ii++ )
 {
 auto col = m_bomView->GetColumn( ii );
 

--2.16.2--


___
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] - File format shim for clearance data

[hauptmech]

Hi Thomasz,

I hope I'm able to address you concerns. I'm stuck using kicad stable in 
many situations. I brought clearances up for discussion last July but no 
one moved on it, nor are they required to. Clearance management is a 
major pain point for me so I wrote a fix. This patch will let us (me and 
the people I collaborate with) work using version 5, but open and close 
files written with a version patched with clearance handling code.


I believe that code exactly like this will go into version 6. Getting it 
in earlier makes a huge difference to me, so I'm submitting it.


On 07/03/18 23:30, Tomasz Wlostowski wrote:

Hi hauptmech,

I'm sorry but IMHO we can't accept your patch:
- it changes the file format while we are already in feature freeze.
This is a way too big change to accept for the V5.


This patch simply adds tokens to the file format. No clearance data is 
saved for files that use the netclass only. Files without clearance 
tokens continue to remain without them.


Yes it is a backward compatible file format change, but it does no harm 
to V5 files already in the wild.



- we are planning to overhaul the clearance/design rules system in V6.
Storing the clearance *DIRECTLY* for each track segment/via will
conflict with any more sophisticated design rule management system.

I'm glad you are planning this. I am sure that regardless of the 
sophistication of the rule system, you will store clearance directly for 
exactly the same reason that track width is stored directly now. There 
are always exceptions to the rules.


If kicad choose a direction that does not store clearances per item, 
then it is easy to rip these few lines back out.


Did this answer your existing concerns about this patch? Are there any 
other concerns you have about this patch?




___
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] - File format shim for clearance data

[hauptmech]

I have a patch for treating track clearance the same as track width. The 
user can already specify a track width that is an exception to the 
netclass width, and now do the same for clearance. ( 
https://youtu.be/05vfAvYwDio )


This is not that patch.

This is a small shim for the file format that will allow reading and 
writing clearance data from the kicad_pcb file without causing a file 
parse error. This will allow us to transparently load and save files 
with clearance data using version 5 stable.


There are 2 patch files. The first deals with the clearance data. It 
adds a (clearance ) field to vias and segments that is only populated if 
the item has a non-netclass clearance. The second patch preserves user 
clearances. It adds a (user_clearance ) field to setup to compliment the 
(user_width ) already there. As stated in the patch title, the 1st patch 
is enough to make a significant difference for my team.


Issues:

    TRACK gains an int sized member. There are hints in the source 
comments that this was a planned improvement all along. Meanwhile some 
may be concerned about impact on memory usage. If anyone is, I'm happy 
to do a memory impact analysis.


    I reduced the patch to the smallest one that would make a 
meaningful impact on the work we do here. Easy to review and most likely 
to be acceptable given the point in the release cycle we are. The wider 
impact of this patch is therefore limited and as a result it might be 
just our team that benefits.


If it's not clear, some of our work computers are locked to the stable 
kicad version, while others are not. We gain benefit from being able to 
do flexible clearance layout on the non-locked computers and still edit 
those files on a stable version of kicad. If you would prefer to look at 
the minimum patch which allows flexible clearance layout, I am happy to 
submit that.



-hauptmech


>From 08165106624d2940ae4507b8981298d58f4ae1a2 Mon Sep 17 00:00:00 2001
From: hauptmech <hauptm...@gmail.com>
Date: Wed, 7 Mar 2018 13:12:20 +1300
Subject: [PATCH 1/2] Minimum viable shim for kicad file format to handle track
 clearances
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
 common/pcb.keywords |  1 +
 pcbnew/class_track.cpp  |  1 +
 pcbnew/class_track.h| 22 ++
 pcbnew/kicad_plugin.cpp |  6 ++
 pcbnew/pcb_parser.cpp   | 14 ++
 5 files changed, 44 insertions(+)


--2.16.2
Content-Type: text/x-patch; name="0001-Minimum-viable-shim-for-kicad-file-format-to-handle-.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Minimum-viable-shim-for-kicad-file-format-to-handle-.patch"

diff --git a/common/pcb.keywords b/common/pcb.keywords
index 1998f9ab5..c36971085 100644
--- a/common/pcb.keywords
+++ b/common/pcb.keywords
@@ -187,6 +187,7 @@ thru_hole_only
 tstamp
 unlocked
 user
+user_clearance
 user_trace_width
 user_via
 uvia_dia
diff --git a/pcbnew/class_track.cpp b/pcbnew/class_track.cpp
index 1c5f69be7..9fd08dae0 100644
--- a/pcbnew/class_track.cpp
+++ b/pcbnew/class_track.cpp
@@ -99,6 +99,7 @@ TRACK::TRACK( BOARD_ITEM* aParent, KICAD_T idtype ) :
 m_Width = Millimeter2iu( 0.2 );
 start   = end = NULL;
 m_Param = 0;
+m_Clearance = NETCLASS_HAS_CLEARANCE; // Netlist drives clearance by default
 }
 
 
diff --git a/pcbnew/class_track.h b/pcbnew/class_track.h
index 1da81e6ff..0de9014b4 100644
--- a/pcbnew/class_track.h
+++ b/pcbnew/class_track.h
@@ -60,6 +60,8 @@ enum VIATYPE_T
 
 #define MIN_VIA_DRAW_SIZE  4   /// Minimum size in pixel for full drawing
 
+#define NETCLASS_HAS_CLEARANCE-1
+
 /**
  * Function GetTrack
  * is a helper function to locate a trace segment having an end point at \a aPosition
@@ -280,6 +282,25 @@ public:
 return wxT( "TRACK" );
 }
 
+/**
+ * Function HasClearance
+ * Return false if clearance is provided by the netclass, otherwise true.
+ */
+bool HasClearance() const
+{
+return m_Clearance != NETCLASS_HAS_CLEARANCE;
+}
+
+void SetClearance( int aClearance )
+{
+m_Clearance = aClearance;
+}
+
+int GetInternalClearance() const
+{
+return m_Clearance;
+}
+
 /**
  * Function GetClearance
  * returns the clearance in internal units.  If \a aItem is not NULL then the
@@ -333,6 +354,7 @@ protected:
 void DrawShortNetname( EDA_DRAW_PANEL* panel, wxDC* aDC, GR_DRAWMODE aDrawMode,
 COLOR4D aBgColor );
 
+int m_Clearance;///< Clearance between this and other elements
 int m_Width;///< Thickness of track, or via diameter
 wxPoint m_Start;///< Line start point
 wxPoint m

[Kicad-developers] [PATCH] Fix depency bug introduced in RPATH patch

[hauptmech]

The attached patch may fix the build error seen after the RPATH patch.

>From 4bdf9c309ae7a794014d5c3240ad8599b1273dc9 Mon Sep 17 00:00:00 2001
From: hauptmech <hauptm...@gmail.com>
Date: Tue, 6 Mar 2018 13:46:05 +1300
Subject: [PATCH] Fix dependency bug introduced in RPATH patch e0b33ee8
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit

---
 pcbnew/CMakeLists.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)


--2.16.2
Content-Type: text/x-patch; name="0001-Fix-dependency-bug-introduced-in-RPATH-patch-e0b33ee.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-dependency-bug-introduced-in-RPATH-patch-e0b33ee.patch"

diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 3ec6bbc23..dfe8e7113 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -685,7 +685,7 @@ add_dependencies( pcbnew pcbnew_kiface )
 
 # add dependency to specctra_lexer_source_files, to force
 # generation of autogenerated file
-add_dependencies( pcbnew_kiface specctra_lexer_source_files )
+add_dependencies( pcbnew_kiface_objects specctra_lexer_source_files )
 
 # these 2 binaries are a matched set, keep them together:
 if( APPLE )

--2.16.2--


___
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] Build error

[hauptmech]

Sorry, you did and I missed it.

A dependency was missed. I think the following might fix it.

in pcbnew/CMakeLists.txt
-add_dependencies( pcbnew_kiface specctra_lexer_source_files )
+add_dependencies( pcbnew_kiface_objects specctra_lexer_source_files )


On 06/03/18 13:10, Nick Østergaard wrote:
I just gave you hints on how to reproduce this. I suspect the most 
important part is the high number of make jobs. I use cmake version 
3.10.2 on archlinux.


2018-03-06 1:03 GMT+01:00 hauptmech <hauptm...@gmail.com 
<mailto:hauptm...@gmail.com>>:


If you have any hints on how to reproduce the failure I can try to
help. The cmake version being used might help.


On 06/03/18 12:55, Nick Østergaard wrote:

I reproduce in a clean workspace like this:
git clone https://github.com/KiCad/kicad-source-mirror.git
<https://github.com/KiCad/kicad-source-mirror.git> kicad_steven
cd kicad_steven/
mkdir build
cd build/
cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF
-DKICAD_SCRIPTING_WXPYTHON=OFF
make -j40


On 5.0.0-rc2-dev-101-gf7ef010fe

2018-03-06 <tel:20%2018%2003%2006> 0:37 GMT+01:00 Nick Østergaard
<oe.n...@gmail.com <mailto:oe.n...@gmail.com>>:

Ok, now I also see that issue. It could very easily be that
RPATH commit making the build system unstable. It is a
problem that the generated files are not in the build dir,
but in the source dir.


2018-03-05 23:22 GMT+01:00 Nick Østergaard <oe.n...@gmail.com
<mailto:oe.n...@gmail.com>>:

It also seem to build correctly on jenkins.

2018-03-05 23:16 GMT+01:00 Steven A. Falco
<stevenfa...@gmail.com <mailto:stevenfa...@gmail.com>>:

I'm going to retract this report.  It builds
correctly on copr, so the problem must be something
in my local setup.

Sorry for the noise.

        Steve

___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>






___
Mailing list:https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to :kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe :https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   :https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>




___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<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] Build error

[hauptmech]

If you have any hints on how to reproduce the failure I can try to help. 
The cmake version being used might help.


On 06/03/18 12:55, Nick Østergaard wrote:

I reproduce in a clean workspace like this:
git clone https://github.com/KiCad/kicad-source-mirror.git kicad_steven
cd kicad_steven/
mkdir build
cd build/
cmake .. -DKICAD_SCRIPTING=OFF -DKICAD_SCRIPTING_MODULES=OFF 
-DKICAD_SCRIPTING_WXPYTHON=OFF

make -j40


On 5.0.0-rc2-dev-101-gf7ef010fe

2018-03-06 0:37 GMT+01:00 Nick Østergaard >:


Ok, now I also see that issue. It could very easily be that RPATH
commit making the build system unstable. It is a problem that the
generated files are not in the build dir, but in the source dir.


2018-03-05 23:22 GMT+01:00 Nick Østergaard >:

It also seem to build correctly on jenkins.

2018-03-05 23:16 GMT+01:00 Steven A. Falco
>:

I'm going to retract this report.  It builds correctly on
copr, so the problem must be something in my local setup.

Sorry for the noise.

        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



___
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] Settable clearances

[hauptmech]

Yeah, this is a really tough part of leading a project, figuring out 
what is whim and what is worth adjusting course for.  Anyway, I'll 
finish the patch, get it checked, and then present my case.


On 06/03/18 04:01, Wayne Stambaugh wrote:

This happened last stable release.  Users wait to the last minute and
then make a request for a new feature.  If this would have been proposed
six months ago, it probably would be part of the v5 release.  The
feature itself is a good idea but it will have to be deferred to some
later version.  We really need to stay focused on the v5 release.  It's
too easy to give into every whim and just keep pushing back v5.  This
happened somewhat in v4 and it took a long time to get from feature
freeze to release so I'm trying to prevent that from happening again.
We are never going to win this fight.  There will always be people who
think we should push back a stable release for some new feature.

Wayne

On 3/5/2018 8:59 AM, Jon Evans wrote:

I can certainly help check it.  I think Wayne would have to make a call
as to whether or not it's too big a change to introduce now.

-Jon

On Mon, Mar 5, 2018 at 7:59 AM, hauptmech <hauptm...@gmail.com
<mailto:hauptm...@gmail.com>> wrote:

 While testing version 5 I realized that clearances are still not
 settable (like track width or via size) and my life is going to be
 miserable if I have to continue with my current work flow which is
 to change the default netclass clearance to the desired clearance
 constantly as I lay down different tracks which require different
 clearances even though they are part of the some net.

 There is a previous thread detailing why netclass is not sufficient
 for all use cases. Search for netclass in the subject.

 Anyway, I wrote most of a patch today (it's 1am in my timezone now)
 and expect to finish it tomorrow. I believe I have a solution which
 will be useful for those that need it and mostly invisible to those
 that don't.

 The question is whether there is a core developer willing to check,
 sign off, and help sell it for inclusion in 5. (I'm stuck using
 whatever the current stable version of kicad is when I'm working)

 This is a huge pain point for me and I'm willing to negotiate a
 small bounty if that helps.



 ___
 Mailing list: https://launchpad.net/~kicad-developers
 <https://launchpad.net/~kicad-developers>
 Post to     : kicad-developers@lists.launchpad.net
 <mailto:kicad-developers@lists.launchpad.net>
 Unsubscribe : https://launchpad.net/~kicad-developers
 <https://launchpad.net/~kicad-developers>
 More help   : https://help.launchpad.net/ListHelp
 <https://help.launchpad.net/ListHelp>




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

[Kicad-developers] Settable clearances

[hauptmech]

While testing version 5 I realized that clearances are still not settable
(like track width or via size) and my life is going to be miserable if I
have to continue with my current work flow which is to change the default
netclass clearance to the desired clearance constantly as I lay down
different tracks which require different clearances even though they are
part of the some net.

There is a previous thread detailing why netclass is not sufficient for all
use cases. Search for netclass in the subject.

Anyway, I wrote most of a patch today (it's 1am in my timezone now) and
expect to finish it tomorrow. I believe I have a solution which will be
useful for those that need it and mostly invisible to those that don't.

The question is whether there is a core developer willing to check, sign
off, and help sell it for inclusion in 5. (I'm stuck using whatever the
current stable version of kicad is when I'm working)

This is a huge pain point for me and I'm willing to negotiate a small
bounty if that helps.
___
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: Right Click Context Menu

[hauptmech]

I agree that it could be improved; though I agree with Jon that messing 
with someone's muscle memory might make them sad.


Editable context menus are the solution I've seen (and used) in other 
complex software.


The heuristics that kicad uses to create the context menu are complex, 
so the user-editable approach that would probably work best is a 
suppression list. A list of Command IDs for which popup entries will be 
suppressed, in the config file. When one eventually wants to make it 
user friendly, it looks like 
http://blogs.solidworks.com/tech/wp-content/uploads/sites/4/menu-customisation.jpg.


On 26/02/18 15:27, Andrey Kuznetsov wrote:

Hi,

Does anyone else think the right context menu in pcbnew should have 
some items shelved into submenus?





___
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] RPATH issue on _pcbnew.so

[hauptmech]

Attached

On 26/02/18 11:15, Wayne Stambaugh wrote:

hauptmech,

Would you please attach this change as a committed patch when you get 
a chance?  I want to test this on windows and linux and maybe we can 
get one of our macos devs to test it there as well.  I would like to 
work out any packaging issues as soon as possible to give our package 
devs as much time as possible to work out any issue for the stable 
release.


Thanks,

Wayne

On 02/24/2018 08:49 PM, hauptmech wrote:
I don't have enough understanding of all the platforms to suggest a 
full patch. However the following works for me on linux (two targets, 
but shared object files so there should be no significant change in 
compile time)


>From 4aa94f47c48befee4c9bcd85c974b92a0b99dd4e Mon Sep 17 00:00:00 2001
From: hauptmech <hauptm...@gmail.com>
Date: Mon, 26 Feb 2018 14:36:12 +1300
Subject: [PATCH] Fix RPATH not removed in shared object file for python
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="2.16.2"

This is a multi-part message in MIME format.
--2.16.2
Content-Type: text/plain; charset=UTF-8; format=fixed
Content-Transfer-Encoding: 8bit


Build pcbnew_kiface files as object target that can then be linked in to pcbnew.kiface and _pcbnew.so
Only create _pcbnew.so target if scripting modules is enabled.
For linux builds only.
---
 pcbnew/CMakeLists.txt | 17 +
 1 file changed, 13 insertions(+), 4 deletions(-)


--2.16.2
Content-Type: text/x-patch; name="0001-Fix-RPATH-not-removed-in-shared-object-file-for-pyth.patch"
Content-Transfer-Encoding: 8bit
Content-Disposition: attachment; filename="0001-Fix-RPATH-not-removed-in-shared-object-file-for-pyth.patch"

diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 520dc1166..3ec6bbc23 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -608,12 +608,15 @@ if( PCBNEW_LINK_MAPS )
 endif()
 
 # the main pcbnew program, in DSO form.
-add_library( pcbnew_kiface MODULE
+add_library( pcbnew_kiface_objects OBJECT
 pcbnew.cpp
 ${PCBNEW_SRCS}
 ${PCBNEW_COMMON_SRCS}
 ${PCBNEW_SCRIPTING_SRCS}
 )
+
+add_library( pcbnew_kiface MODULE $ )
+
 set_target_properties( pcbnew_kiface PROPERTIES
 # Decorate OUTPUT_NAME with PREFIX and SUFFIX, creating something like
 # _pcbnew.so, _pcbnew.dll, or _pcbnew.kiface
@@ -640,7 +643,7 @@ if( ${OPENMP_FOUND} )
 )
 endif()
 
-target_link_libraries( pcbnew_kiface
+set( PCBNEW_KIFACE_LIBRARIES
 3d-viewer
 pcbcommon
 pnsrouter
@@ -660,6 +663,9 @@ target_link_libraries( pcbnew_kiface
 ${OPENMP_LIBRARIES}
 )
 
+
+target_link_libraries( pcbnew_kiface ${PCBNEW_KIFACE_LIBRARIES} )
+
 set_source_files_properties( pcbnew.cpp PROPERTIES
 # The KIFACE is in pcbnew.cpp, export it:
 COMPILE_DEFINITIONS "BUILD_KIWAY_DLL;COMPILING_DLL"
@@ -777,9 +783,12 @@ if( KICAD_SCRIPTING_MODULES )
 )
 add_dependencies( ScriptingModulesPcbnewSoCopy ScriptingWxpythonCopy )
 set( PYMOD_EXT "so" )
-
 else()  # only linux remains among supported platforms
-install( FILES ${CMAKE_BINARY_DIR}/pcbnew/_pcbnew.so DESTINATION ${PYTHON_DEST} )
+add_library( pcbnew_python MODULE $ )
+target_link_libraries( pcbnew_python ${PCBNEW_KIFACE_LIBRARIES} )
+set_target_properties( pcbnew_python PROPERTIES OUTPUT_NAME pcbnew PREFIX "_" SUFFIX ".so" )
+install( TARGETS pcbnew_python DESTINATION ${PYTHON_DEST} COMPONENT binary )
+
 set( PYMOD_EXT "so" )
 endif()
 

--2.16.2--


___
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] RPATH issue on _pcbnew.so

[hauptmech]

I don't have enough understanding of all the platforms to suggest a full
patch. However the following works for me on linux (two targets, but shared
object files so there should be no significant change in compile time)

diff --git a/pcbnew/CMakeLists.txt b/pcbnew/CMakeLists.txt
index 520dc1166..78bd19cee 100644
--- a/pcbnew/CMakeLists.txt
+++ b/pcbnew/CMakeLists.txt
@@ -608,12 +608,14 @@ if( PCBNEW_LINK_MAPS )
 endif()

 # the main pcbnew program, in DSO form.
-add_library( pcbnew_kiface MODULE
+add_library( pcbnew_kiface_objects OBJECT
 pcbnew.cpp
 ${PCBNEW_SRCS}
 ${PCBNEW_COMMON_SRCS}
 ${PCBNEW_SCRIPTING_SRCS}
 )
+add_library( pcbnew_kiface MODULE $ )
+
 set_target_properties( pcbnew_kiface PROPERTIES
 # Decorate OUTPUT_NAME with PREFIX and SUFFIX, creating something like
 # _pcbnew.so, _pcbnew.dll, or _pcbnew.kiface
@@ -640,7 +642,7 @@ if( ${OPENMP_FOUND} )
 )
 endif()

-target_link_libraries( pcbnew_kiface
+set( PCBNEW_KIFACE_LIBRARIES
 3d-viewer
 pcbcommon
 pnsrouter
@@ -660,6 +662,9 @@ target_link_libraries( pcbnew_kiface
 ${OPENMP_LIBRARIES}
 )

+
+target_link_libraries( pcbnew_kiface ${PCBNEW_KIFACE_LIBRARIES})
+
 set_source_files_properties( pcbnew.cpp PROPERTIES
 # The KIFACE is in pcbnew.cpp, export it:
 COMPILE_DEFINITIONS "BUILD_KIWAY_DLL;COMPILING_DLL"
@@ -779,7 +784,11 @@ if( KICAD_SCRIPTING_MODULES )
 set( PYMOD_EXT "so" )

 else()  # only linux remains among supported platforms
-install( FILES ${CMAKE_BINARY_DIR}/pcbnew/_pcbnew.so DESTINATION
${PYTHON_DEST} )
+add_library( pcbnew_python MODULE
$ )
+target_link_libraries( pcbnew_python ${PCBNEW_KIFACE_LIBRARIES})
+set_target_properties( pcbnew_python PROPERTIES OUTPUT_NAME pcbnew
PREFIX "_" SUFFIX ".so")
+install( TARGETS pcbnew_python DESTINATION ${PYTHON_DEST}
COMPONENT binary)
+
 set( PYMOD_EXT "so" )
 endif()




On Sun, Feb 25, 2018 at 2:42 PM, Cirilo Bernardo <cirilo.berna...@gmail.com>
wrote:

> What do you mean by a second target? Keep in mind that we don't want to
> recompile everything twice just because of the kiface libraries. If you can
> create a target which is dependent on the pcbnew stand-alone app and
> which used the object files to create a shared library, that would be good.
> I can't recall offhand if some object files would need to be rebuilt for
> the kiface library, but that can be handled by CMake as well.
>
> Regarding  KiCad using pcbnew.kiface directly, I suspect the intention was
> for
> pcbnew to use that library regardless of whether it was run via the KiCad
> application or as the pcbnew standalone application. On that topic I'd
> rather
> do nothing until KiCad could be refactored to the point where a core pcb
> API
> is completely independent of the GUI; at the moment there is such a tight
> coupling between the GUI and operations on the PCB that it's difficult to
> see how some things work.
>
> Cirilo
>
> On Sun, Feb 25, 2018 at 1:20 AM, hauptmech <hauptm...@gmail.com> wrote:
> > I took a look at what approaches might work to fix this.
> >
> > I looked at removing the RPATH manually, in keeping with manual file
> > manipulation approach used by the authors of this section of the CMake
> file.
> > Shell tools to do this don't appear to be universal and it's not using
> the
> > CMake way. So I moved on.
> >
> > The approach that looks the most promising to me is to create a second
> > target for the scripting library with the same sources as pcbnew.kiface.
> > Then CMakes install Target will remove the RPATH as expected. To reduce
> the
> > impact on compile time one could use:
> > https://cmake.org/Wiki/CMake/Tutorials/Object_Library
> >
> > In the CMake file, Dick Hollenbeck mentions a future plan to use the
> > pcbnew.kiface file directly. Not sure what was involved with that.
> >
> > On 25/02/18 10:37, Carsten Schoenert wrote:
> >>
> >> Hello Wayne,
> >>
> >> Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:
> >>>
> >>> Carsten,
> >>>
> >>> On 02/24/2018 02:08 PM, Carsten Schoenert wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> I guess it's not intended that the library / shared object _pcbnew.so
> >>>> build in pcbnew/ set up a RPATH based on the build directory?
> >>>
> >>> This is the kicad python scripting shared object which should get
> >>> installed in the correct python library path.  CMake installs it in the
> >>> correct place on both my Debian and Ubuntu builds so I don't understand
> >>> what the issue is here.
>

Re: [Kicad-developers] RPATH issue on _pcbnew.so

[hauptmech]

I took a look at what approaches might work to fix this.

I looked at removing the RPATH manually, in keeping with manual file 
manipulation approach used by the authors of this section of the CMake 
file. Shell tools to do this don't appear to be universal and it's not 
using the CMake way. So I moved on.


The approach that looks the most promising to me is to create a second 
target for the scripting library with the same sources as pcbnew.kiface. 
Then CMakes install Target will remove the RPATH as expected. To reduce 
the impact on compile time one could use: 
https://cmake.org/Wiki/CMake/Tutorials/Object_Library


In the CMake file, Dick Hollenbeck mentions a future plan to use the 
pcbnew.kiface file directly. Not sure what was involved with that.


On 25/02/18 10:37, Carsten Schoenert wrote:

Hello Wayne,

Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:

Carsten,

On 02/24/2018 02:08 PM, Carsten Schoenert wrote:

Hi,

I guess it's not intended that the library / shared object _pcbnew.so
build in pcbnew/ set up a RPATH based on the build directory?

This is the kicad python scripting shared object which should get
installed in the correct python library path.  CMake installs it in the
correct place on both my Debian and Ubuntu builds so I don't understand
what the issue is here.

the build and installation is just fine, the issue is that this file has
a RUNPATH set to folder there it was compiled. It should have *no* RUNPATH.




___
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] RPATH issue on _pcbnew.so

[hauptmech]

I've confirmed that there is a wrong RPATH in the install. The issue is 
in pcbnew/CMakeFiles.txt#if( KICAD_SCRIPTING_MODULES ).


Rather than using the CMake install target script, _pcbnew.so is getting 
copied manually and then installed as a file.


On 25/02/18 10:37, Carsten Schoenert wrote:

Hello Wayne,

Am 24.02.18 um 21:44 schrieb Wayne Stambaugh:

Carsten,

On 02/24/2018 02:08 PM, Carsten Schoenert wrote:

Hi,

I guess it's not intended that the library / shared object _pcbnew.so
build in pcbnew/ set up a RPATH based on the build directory?

This is the kicad python scripting shared object which should get
installed in the correct python library path.  CMake installs it in the
correct place on both my Debian and Ubuntu builds so I don't understand
what the issue is here.

the build and installation is just fine, the issue is that this file has
a RUNPATH set to folder there it was compiled. It should have *no* RUNPATH.


root@i5:/# ldd build/kicad-5.0.0~rc0+dfsg1/debian/build/pcbnew/_pcbnew.so | 
grep build
libkicad_3dsg.so.2.0.0 => 
/build/kicad-5.0.0~rc0+dfsg1/debian/build/3d-viewer/3d_cache/sg/libkicad_3dsg.so.2.0.0
 (0x7f8188148000)

This causes that lintian (a big QS tool for Debian packaging) is writing
a error out on this. This package wouldn't be accepted from the FTP
master if I'd do a upload to NEW. And I need to upload to NEW as the
package structure will change.

This is the build path not the install path.

Partially correct. :-)
In Debian the build folder is created by '/build/$PACKAGE_$VERSION', the
out of tree build is typically done within the folder debian/build so
the root for building all is

/build/kicad-5.0.0~rc0+dfsg1/debian/build/...

So yes, the the first line from my paste is the build path, the second
line is just the output of 'ldd' with a grepped 'build' as argument.
_pcbnew.so is looking for libkicad_3dsg.so.2.0.0 in the path which is
shown there. And this is obviously wrong.


  By default on linux builds the shared object gets installed in
/usr/local/lib/libkicad_3dsg.so.2.0.0.  This is the 3D viewer plugin so
I don't know if this the correct convention for plugins but as it is a
shared object, it will get recognized by the os and load properly.  If
plugins should be installed in a different path, please let me know what
that path should be and we can change the cmake install path for this
shared object.

The installation of this private library is no problem, kicad does here
exactly what the standard folder is if the INSTALL_PATH isn't given. No
need something to change here.

...

I don't know what has to be changed here so I'd like to ask someone who
is more experienced with the cmake world.
I could change this with chrpath but it's better if upstream would fix
this. Surprisingly the library _pcbnew.kiface hasn't this issue so I'm a
bit clueless.

I don't know that anything changed that I am aware of with _pcbnew.so.
The 3D viewer plugin was introduced during this development cycle but I
have been successfully building and installing from source on Debian
during the entire current development cycle so I don't have any good
answers for you.

I have really no knowledge about cmake, but I can see some information
of setting the RUNPATH to an empty string while installing binaries or
shared objects in opposite of this Python library.


-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/share/kicad/scripting/kicad_pyshell/__init__.py
-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/python2.7/dist-packages/_pcbnew.so 
 <--- no modification here
-- Installing: /build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/bin/pl_editor
> -- Installing:

/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/bin/_pcb_calculator.kiface

-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_idf.so
-- Set runtime path of 
"/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_idf.so"
 to ""  <--
-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_vrml.so
-- Set runtime path of 
"/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_vrml.so"
 to ""  <--
-- Installing: 
/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_oce.so
-- Set runtime path of 
"/build/kicad-5.0.0~rc0+dfsg1/debian/tmp/usr/lib/x86_64-linux-gnu/kicad/plugins/3d/libs3d_plugin_oce.so"
 to ""  <--

It's probably just a small thing that is needed to add $SOMETHERE to the
installation of this Python library.




___
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] RPATH issue on _pcbnew.so

[hauptmech]

On 25/02/18 10:37, Carsten Schoenert wrote:

the build and installation is just fine, the issue is that this file has
a RUNPATH set to folder there it was compiled. It should have*no*  RUNPATH.


I'm not understanding this thread 100% so apologies if this misses the 
point.


RPATH is set by default by CMake in the build folder and then the RPATH 
is removed by the CMake install script during installation.


The explanation is here: https://cmake.org/Wiki/CMake_RPATH_handling

If this is a source build and install, you need to be checking the rpath 
on the installed file, not the build directory file.


If this is a packaging toolset for debian, I'm unfamiliar, however it 
seems strange to run lintian on the build files instead of the installed 
(presumably installed on a chroot) files.


___
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] Hard coded hotkeys

[hauptmech]

Thanks for pointing that out.

https://bugs.launchpad.net/kicad/+bug/1751183

On 24/02/18 00:38, Nick Østergaard wrote:

Where is the bug report? Please link it here. I guess you just forgot it.

2018-02-23 4:35 GMT+01:00 hauptmech <hauptm...@gmail.com 
<mailto:hauptm...@gmail.com>>:


Jon Evans, Kristoffer Ödmark, John Beard, and maybe Tomasz Włostowski

I filed a bug report for the temporary hard-coded hotkeys that
have not been cleaned up. I'm super motivated to not have them in
5 so if you can't get to it let me know and I'll see if I can
figure out how to do it.

    -hauptmech






___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<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] Hard coded hotkeys

[hauptmech]

Jon Evans, Kristoffer Ödmark, John Beard, and maybe Tomasz Włostowski

I filed a bug report for the temporary hard-coded hotkeys that have not 
been cleaned up. I'm super motivated to not have them in 5 so if you 
can't get to it let me know and I'll see if I can figure out how to do it.


-hauptmech






___
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] Change to object visibility system for usability/clarity

[hauptmech]

I know the use case is implied in this thread, and the only real need 
before 5 is to fix the blatant bugs, but I thought it might be helpful 
to explicitly state the use case.


A PCB layout has too much information for it to be displayed all 
together on the screen at once. The user (or the workflow) needs to 
limit the displayed info to what is relevant to the job at hand and 
remove the info that obscures or causes confusion.


Tasks to be done (among many) include:

_ solve the topology problem of where to have copper. Beyond simple 
connectivity, there are thermal, inductive, capacitive, and even visual 
design problems to be solved and different people have ways of getting 
their head around this.


_ check for errors or DFM issues. DRC helps but is not yet fine-grained 
enough to do it all. A visual review all manufacturing info is part of 
many peoples process.


_ lay out on-board documentation; typically copper or silkscreen, both 
of which are affected by the mask layer.


_ Add/review design notes for self or others

_ Transfer info from parts to the designer, some of which kicad supports 
(courtyards) and some of which gets hacked in on auxiliary layers 
(manufacturers recommended fanout).


_ Lay out assembly documentation and act as a live view and query system 
during actual assembly


Different users will have different tasks that are important to them, 
and different groups of visibility states that they use for each task.


Ideally each user can set groups of arbitrary visibility states to 
toggle between for each task they have in an easy and intuitive manner. 
Something to consider for 6.


It's been made clear in the discussion so far that different people have 
different ideas about what is useful grouping (linking, locking). I 
don't think there is a way to do it in the current interface that will 
avoid annoying a group of people. Perhaps favor flexibility (no linking 
with the cost of extra check box clicking) over convenience for a subset.





On 19/02/18 09:00, Jon Evans wrote:

Hi all,

Right now the behavior of the "Layer" and "Render" tabs of the layers 
widget are confusing to users, resulting in complaints on the forum 
and some bug reports:


https://bugs.launchpad.net/kicad/+bug/1748181
https://bugs.launchpad.net/kicad/+bug/1743890

I could take a crack at fixing this (before or after 5.0 depending on 
what the complexity ends up being) but before I write any code I 
wanted to propose how I think it should work.


I think the visibility of any object should be the AND of layer 
visibility and render visibility.


To get there:

1) In the Render tab, get rid of the distinction between front/back. 
For example "Pads Back" and "Pads Front" becomes just "Pads"


2) Change the visibility code so that an object is visible if (a) the 
associated Render setting is turned on for the type of object, and (b) 
at least one of the layers the object is on is enabled in the Layers tab.


3) (optionally) Rename "Render" to something more friendly like 
"Items" or "Item Types" to make it more clear to the user that this is 
where they can turn off the display of various types of items as 
opposed to various layerse


If this plan is OK, I will start working out the details of how to get 
there.  Right now the Render tab is directly controlling the 
visibility of certain "GAL Layers" but unfortunately the set of 
objects that appears on one GAL layer is not always equal to the set 
of objects that the user would expect to turn on and off, as seen by 
the bug reports.  So, there will have to be some additional logic 
created to manage these settings beyond just turning on and off layers 
in the GAL.


-Jon


___
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] Reverse parsing for spaces

[hauptmech]

Just adding another opinion to the mix here.

%20 does not make the current file format any more difficult to read 
than it already is. The current format can be parsed by a human and 
edited with a text editor. That's good, and that's all you need.


\x20 (which is what you would use if you were to use a \ escape format 
that is in wide use) is the same for readability.


\ is cleaner visually but will confuse more people as there are 
less tools (mostly shells) that use this escape.


All have the potential to clash with existing files in the wild.

If you tweak the format then you introduce file migration headaches and 
issues for tools that read kicad files directly (I have a few and I 
don't think I'm the only one.)


Please just leave it as it is (no spaces) until 6.




On 17/02/18 10:17, Wayne Stambaugh wrote:

My beef with % encoding is that it is not human readable.  Human
readability is an important goal when designing KiCad file formats.

On 2/16/2018 4:04 PM, Jeff Young wrote:

Yeah, that’s why I was suggesting %-encoding.  Substituting %20 for spaces 
wouldn’t be a file format change.  And it’s a common enough escape sequence 
that anyone writing 3rd-party tools could easily deal with it.

I think %-encoding is probably better than ‘\’-prefixing, mostly because it can 
also handle the space issue.


On 16 Feb 2018, at 20:56, Wayne Stambaugh  wrote:

The space issue is tricky because it's not a quoted string.  Quoting the
string would be a file format change although you could make the
argument so is the space.

I believe all of the other strings in question are quoted in the file
format so it should just be a matter of quoting any special characters
with a '\' character.  That is what I intend to do with the LIB_ID
parser and formatter after v5 is released.  This will change both the
schematic and board file formats.  That's why I wont do this until after
the new schematic file format is implemented so it will be a non issue.
An easy solution is to use a validator to veto any forbidden characters
from being used where applicable.

The other place '/' cannot be used is in sheet names because the human
readable sheet path uses '/' to separate each sheet name.  I'm sure
there are some other places this issue exists as well.

On 2/16/2018 3:32 PM, Jeff Young wrote:

There was an issue a while back where we were considering reverse parsing 
something or another so that spaces didn’t trip us up.  What’s the status of 
that?

The reason I ask is that I’m looking at another bug where a user wants to put 
‘/‘ characters in their global labels (which we of course use as a path 
delimiter between sheets and labels.

In general we need to get our implementation out of the way of users.  So I was 
thinking about applying %-encoding to the label case now, and perhaps rolling 
it out more widely in 6.0.  Which brought me to wondering if it would work for 
the space problem we were having….



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] UI changes for 5.0?

[hauptmech]

On 9/02/18 20:57, Maciej Sumiński wrote:

Please consider that there are documenters that have just updated some
screenshots and so they probably will have to update some more because
of these UI changes.

The changes proposed by Jeff are not that disruptive. It is just adding
'...' or changing Cancel->Close, so I guess it is not a big deal for the
users. Obviously it is better to have pictures showing dialogs and menus
exactly as you find them in the software, but I suppose nobody will even
notice that a button is labeled 'Close' instead of 'Cancel'.


We notice and it immediately casts doubt as to whether the documentation 
one is reading is valid. Worst case we spend a lot of time searching or 
cross checking to make sure we have the right info. Best case, we just 
think it's poor workmanship.


4.0.x has felt like the team lost control of the project. I for one 
would rather wait a few more months to get to a clean, consistent, and 
complete 5.0 if that's what it takes. I don't need features, just for 
what's there to work well.



___
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] Migrating old designs best practice

[hauptmech]

On 26/11/17 04:00, Wayne Stambaugh wrote:

On 11/24/2017 05:01 PM, hauptmech wrote:

On 25/11/17 02:14, Wayne Stambaugh wrote:

This is *the* fatal flaw with the cache library.  User's assume it is
stale symbols or a temporary copy.  It is not.  It is a snapshot of the
current library symbols linked to the symbols in the schematic.  It gets
refreshed every time the schematic is saved.  Once you delete this file
or keep an out of date copy using cvs, all bets are off.  It is only a
matter of time before one of your symbol libraries changes or gets
removed and you will end up with a broken schematic.  The rescue code
depends on the cache being up to date in order preserve you schematic.
If the cache is not current, the rescuing cannot be guaranteed.

I don't think it's necessarily a flaw. And your description above is
indeed a cache. That's not a bad thing. I recall that I left it out of
version control because I wanted to make sure fixes to my symbols were
always propagated to the design. In the repo I'm referencing for this
discussion I had 10 project files all using the same local library. I
didn't want to have to manually update each schematic to propagate
changes. Deleting untracked files was what I did instead. At the time no
one was making breaking changes to system installed symbols, so the
system libs were stable for this workflow.

I'm trying think of the least effort way to migrate an old design in
these circumstances.

Can we have the rescue code fail if no cache file is found? That at
least lets the user know they are in uncharted territory. Then if a lot
of users come complaining you will know if it is worth doing a bit more
in the rescue code.

If the cache is not available during rescue you can load a copy of the
libraries that were current at the schematic save date and either
re-cache them or rescue them directly. But this is only worth doing if a
significant number of users are affected.

AFAIK, the rescue code doesn't do anything if there is not cache file
because the cache file is used for the comparison.  I actually
considered adding a check on schematic load to warn the user with a list
of all of symbols linked to the cache library so they could fix them.
I'm not sure this is desirable but at least users would know that
symbols were missing from their libraries and the links were falling
back to the cache which is tenuous at best.



It depends on how you view the role of the rescue code. While the 
schematic itself is not changed, the library files are, and in the case 
of no cache, the library files are part of the schematic dataset.  The 
schematic still needs rescuing.


It would be nice if we could just point to a folder full of the old 
libraries on load that could then be the source for the symbols copied 
into the rescue.lib


But, a simple warning that symbols were changed if there is no cache 
file would at least let people what's going on.  You and I know what's 
going on now, but the next person to see this will just see the rescue 
operation succeed and then a broken schematic full of disconnected wires.


The symbols from cache list sounds like it would be useful.


___
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] Migrating old designs best practice

[hauptmech]

On 25/11/17 02:14, Wayne Stambaugh wrote:

This is *the* fatal flaw with the cache library.  User's assume it is
stale symbols or a temporary copy.  It is not.  It is a snapshot of the
current library symbols linked to the symbols in the schematic.  It gets
refreshed every time the schematic is saved.  Once you delete this file
or keep an out of date copy using cvs, all bets are off.  It is only a
matter of time before one of your symbol libraries changes or gets
removed and you will end up with a broken schematic.  The rescue code
depends on the cache being up to date in order preserve you schematic.
If the cache is not current, the rescuing cannot be guaranteed.


I don't think it's necessarily a flaw. And your description above is 
indeed a cache. That's not a bad thing. I recall that I left it out of 
version control because I wanted to make sure fixes to my symbols were 
always propagated to the design. In the repo I'm referencing for this 
discussion I had 10 project files all using the same local library. I 
didn't want to have to manually update each schematic to propagate 
changes. Deleting untracked files was what I did instead. At the time no 
one was making breaking changes to system installed symbols, so the 
system libs were stable for this workflow.


I'm trying think of the least effort way to migrate an old design in 
these circumstances.


Can we have the rescue code fail if no cache file is found? That at 
least lets the user know they are in uncharted territory. Then if a lot 
of users come complaining you will know if it is worth doing a bit more 
in the rescue code.


If the cache is not available during rescue you can load a copy of the 
libraries that were current at the schematic save date and either 
re-cache them or rescue them directly. But this is only worth doing if a 
significant number of users are affected.



___
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] Migrating old designs best practice

[hauptmech]

On 25/11/17 03:26, Rene Pöschl wrote:

On 24/11/17 12:38, hauptmech wrote:

On 24 Nov 2017 10:52 pm, "Rene Pöschl" <poesc...@gmail.com> wrote:

On 24/11/17 04:47, hauptmech wrote:


I can confirm unconnected wires. It may be worth noting that I did not
preserve the -cache.lib file when I archived the design.

I also had an issue with an old asymmetric diode footprint having its
anode and cathode reversed when I used it in a new design. If pin
numbers in the library got swapped around, then now I know why.

For myself, I would much rather that the old library parts get loaded
with my old design instead of trying to convert old parts to new parts.
Is it unreasonable to do that? Load the design with the old parts and
then do the rescue/migration rename? That way the old parts go into the
-rescue.lib file unchanged except for a name modification. Including 
the

old parts lib (perhaps concatenated into one file) does not seem too
difficult.

If the symbols are still unchanged in the library then you would not 
need

the cache lib. (The migration would simply point to the full name of the
symbol including the library name. Unless i understand the process 
wrong.)


The cache lib is necessary if the symbol in the library does change 
or is
deleted. If you also delete the cache lib, from where should KiCad 
get the

information how your old symbol(s) looked like? (The symbol data is not
stored inside the schematic files. It is only stored in the cache lib.)

These are not my symbols, they are kicad library symbols, for which i 
would

hope for either stability or a migration path.


So we can never ever change symbols?

It is not the responsibility of the library team to ensure that you 
archive your projects correctly.


(Also the lib is a git repo. So if you know when you made your project 
you can check out that old version of the lib.) 


Of course you can change symbols, though the peculiarities of the symbol 
data (lack of GUID's, use of pin location to determine schematic 
connectivity) along with the legacy of kicad being around a while means 
that the impact of changes might be hard to follow.


I do know when I made the project (and I already have a copy of the 
correct libs). Can you elaborate on how this works? Assuming I check out 
the correct version of the lib, how do I tell kicad to use that version 
instead of the system installed version?












___
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] Migrating old designs best practice

[hauptmech]

One the one hand, yes, if there is a cache file you can take advantage of
the fact that it is a stale copy of the old parts.

On the other hand, since caches are, by definition, temporary copies of
data, they don't get versioned or archived in my projects. (The kicad
libraries, and binaries, were though).

On 24 Nov 2017 10:21 pm, "Nick Østergaard" <oe.n...@gmail.com> wrote:

> This would haven been resolved if you kept the cache lib, IIRC.
>
> Den 24. nov. 2017 4.48 AM skrev "hauptmech" <hauptm...@gmail.com>:
>
>> I can confirm unconnected wires. It may be worth noting that I did not
>> preserve the -cache.lib file when I archived the design.
>>
>> I also had an issue with an old asymmetric diode footprint having its
>> anode and cathode reversed when I used it in a new design. If pin numbers
>> in the library got swapped around, then now I know why.
>>
>> For myself, I would much rather that the old library parts get loaded
>> with my old design instead of trying to convert old parts to new parts. Is
>> it unreasonable to do that? Load the design with the old parts and then do
>> the rescue/migration rename? That way the old parts go into the -rescue.lib
>> file unchanged except for a name modification. Including the old parts lib
>> (perhaps concatenated into one file) does not seem too difficult.
>>
>>
>>
>>
>>
>> On 24/11/17 10:09, Wayne Stambaugh wrote:
>>
>>> I stand corrected.  I just looked and pin numbers are checked by
>>> position so swapped pins should get rescued.  What isn't rescued is pins
>>> that changed length which is a bit surprising since that would possibly
>>> leave unconnected wires.  I'm not sure why it was done this way but I
>>> guess I'll have to do some testing before the stable 5 release to see if
>>> it needs to be fixed.
>>>
>>> On 11/23/2017 11:12 AM, Nick Østergaard wrote:
>>>
>>>> Maybe I am mistaken then.
>>>>
>>>> 2017-11-23 13:21 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com
>>>> <mailto:stambau...@gmail.com>>:
>>>>
>>>>  On 11/22/2017 11:02 PM, hauptmech wrote:
>>>>  > When opening an old design I noticed that the C and R symbol pin
>>>> nodes
>>>>  > changed position (I'm guessing other symbols as well), breaking
>>>> the
>>>>  > schematic. Did the people who changed these symbols have a plan
>>>> for
>>>>  > migrating old designs? Is the 'rescue' supposed to handle this?
>>>>  >
>>>>
>>>>  AFAIK, the rescuer does not handle this case.  I'm not even sure
>>>> if it
>>>>  could.  That's something someone would have to take a look at.
>>>>
>>>>  ___
>>>>  Mailing list: https://launchpad.net/~kicad-developers
>>>>  <https://launchpad.net/~kicad-developers>
>>>>  Post to : kicad-developers@lists.launchpad.net
>>>>  <mailto:kicad-developers@lists.launchpad.net>
>>>>  Unsubscribe : https://launchpad.net/~kicad-developers
>>>>  <https://launchpad.net/~kicad-developers>
>>>>  More help   : https://help.launchpad.net/ListHelp
>>>>  <https://help.launchpad.net/ListHelp>
>>>>
>>>>
>>>> ___
>>> Mailing list: https://launchpad.net/~kicad-developers
>>> Post to : kicad-developers@lists.launchpad.net
>>> Unsubscribe : https://launchpad.net/~kicad-developers
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>
>>
>>
>> ___
>> Mailing list: https://launchpad.net/~kicad-developers
>> Post to : kicad-developers@lists.launchpad.net
>> Unsubscribe : https://launchpad.net/~kicad-developers
>> More help   : https://help.launchpad.net/ListHelp
>>
>
___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

Re: [Kicad-developers] Migrating old designs best practice

[hauptmech]

On 24 Nov 2017 10:52 pm, "Rene Pöschl" <poesc...@gmail.com> wrote:

On 24/11/17 04:47, hauptmech wrote:

> I can confirm unconnected wires. It may be worth noting that I did not
> preserve the -cache.lib file when I archived the design.
>
> I also had an issue with an old asymmetric diode footprint having its
> anode and cathode reversed when I used it in a new design. If pin
> numbers in the library got swapped around, then now I know why.
>
> For myself, I would much rather that the old library parts get loaded
> with my old design instead of trying to convert old parts to new parts.
> Is it unreasonable to do that? Load the design with the old parts and
> then do the rescue/migration rename? That way the old parts go into the
> -rescue.lib file unchanged except for a name modification. Including the
> old parts lib (perhaps concatenated into one file) does not seem too
> difficult.
>

If the symbols are still unchanged in the library then you would not need
the cache lib. (The migration would simply point to the full name of the
symbol including the library name. Unless i understand the process wrong.)

The cache lib is necessary if the symbol in the library does change or is
deleted. If you also delete the cache lib, from where should KiCad get the
information how your old symbol(s) looked like? (The symbol data is not
stored inside the schematic files. It is only stored in the cache lib.)

These are not my symbols, they are kicad library symbols, for which i would
hope for either stability or a migration path.






___
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] Migrating old designs best practice

[hauptmech]

I can confirm unconnected wires. It may be worth noting that I did not 
preserve the -cache.lib file when I archived the design.


I also had an issue with an old asymmetric diode footprint having its 
anode and cathode reversed when I used it in a new design. If pin 
numbers in the library got swapped around, then now I know why.


For myself, I would much rather that the old library parts get loaded 
with my old design instead of trying to convert old parts to new parts. 
Is it unreasonable to do that? Load the design with the old parts and 
then do the rescue/migration rename? That way the old parts go into the 
-rescue.lib file unchanged except for a name modification. Including the 
old parts lib (perhaps concatenated into one file) does not seem too 
difficult.






On 24/11/17 10:09, Wayne Stambaugh wrote:

I stand corrected.  I just looked and pin numbers are checked by
position so swapped pins should get rescued.  What isn't rescued is pins
that changed length which is a bit surprising since that would possibly
leave unconnected wires.  I'm not sure why it was done this way but I
guess I'll have to do some testing before the stable 5 release to see if
it needs to be fixed.

On 11/23/2017 11:12 AM, Nick Østergaard wrote:

Maybe I am mistaken then.

2017-11-23 13:21 GMT+01:00 Wayne Stambaugh <stambau...@gmail.com
<mailto:stambau...@gmail.com>>:

 On 11/22/2017 11:02 PM, hauptmech wrote:
 > When opening an old design I noticed that the C and R symbol pin nodes
 > changed position (I'm guessing other symbols as well), breaking the
 > schematic. Did the people who changed these symbols have a plan for
 > migrating old designs? Is the 'rescue' supposed to handle this?
 >

 AFAIK, the rescuer does not handle this case.  I'm not even sure if it
 could.  That's something someone would have to take a look at.

 ___
 Mailing list: https://launchpad.net/~kicad-developers
 <https://launchpad.net/~kicad-developers>
 Post to     : kicad-developers@lists.launchpad.net
 <mailto:kicad-developers@lists.launchpad.net>
 Unsubscribe : https://launchpad.net/~kicad-developers
 <https://launchpad.net/~kicad-developers>
 More help   : https://help.launchpad.net/ListHelp
 <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] Migrating old designs best practice

[hauptmech]

When opening an old design I noticed that the C and R symbol pin nodes 
changed position (I'm guessing other symbols as well), breaking the 
schematic. Did the people who changed these symbols have a plan for 
migrating old designs? Is the 'rescue' supposed to handle this?






___
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] Recent eeschema changes

[hauptmech]

On 23/11/17 07:03, Julius Schmidt wrote:

On Wed, 22 Nov 2017, Andy Peters wrote:

This “touching” of projects occurs with more applications than I can 
count. For example: every time I want to view a completed Altium 
project and I change layer visibility, Altium marks the layout as 
modified. It asks me if I want to save the file before closing the 
application.
The solution I’ve found is: let the tool do whatever it wants to do, 
then simply don’t save the files after you’re doing viewing them. At 
the very least, make a copy of the project before viewing. My 
projects are in a Subversion repository, so it’s a simple matter of 
checking out a new working copy, and then deleting the working copy 
when I’m done.


The difference is that, presumably, Altium does not modify the files 
on disk if you do not save.


This is really my core complaint, I don't expect kicad to be able to
modify old projects and save back into the old format.

I do expect it to be able to open them without damaging the files.


I strongly agree with julius here.

Not everyone wants to (or has admin ability to) migrate their workflow 
to the newest version of any software. Those of us that collaborate with 
these people maintain multiple versions of software X to handle this. 
Opening the wrong project with the wrong software version is a common 
accident in these situations.


Long story short, an intentional migration of files from one version to 
another is fine but changing files to a different format/version on load 
in the background is not cool.





___
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] Update of KiCad documentation?

[hauptmech]

A URL into the documentation would probably lessen the friction of 
locating exactly what section of documentation needs fixing. Dev's 
changing user facing stuff will be familiar with (if not actively 
stubbing out, or updating the docs) it so it seems a reasonable ask.


CHANGED: Synopsis. url#section

Consider just one keyword (CHANGE, or FEATURE) so we are not doing "git 
log --grep=CHANGE|NEW|REMOVED"


On 10/11/17 05:44, Wayne Stambaugh wrote:

I like this idea as well.  It's simple and easy to remember.  If there
are no objections, I will updated the commit message policy to add NEW,
CHANGED, and REMOVED tags and a brief explanation of when each tag
should be used.  Is there any special formatting that we want to use
with these tags to make life easier for folks trying to extract
information using scripts?  Rather than adding the tag to the end which
may be a bit limiting, I was thinking it may make more sense to add the
tag to the beginning of the description of the change separated by empty
lines.  It could look something like this.

Major rewrite of some existing feature.

NEW: The feature adds support for X, Y, and Z operations.

REMOVED: The feature no longer supports the foo operation.

CHANGED: The feature operations bar and baz now require manual frobnication.

If anyone has any better ideas, now is the time.

Cheers,

Wayne

On 11/9/2017 11:06 AM, Maciej Sumiński wrote:

I am in favor of including the information in commit messages. In the
simplest version, one can simple append "CHANGE" at the end of a commit
message. If we follow this scheme, then to get a changelog it is enough
to execute "git log --grep=CHANGE". One can also modify the query to get
changelog for different periods.

It is a tiny effort on the developers side which significantly helps
people willing to work on the documentation, therefore I think it is
worth pursuing. The only possible problem I see here is to get into the
habit, but we did well with "Fixes".

Regards,
Orson

On 11/09/2017 01:40 PM, Nick Østergaard wrote:

I didn't mean to indicate that one shall not write useful commit messages
in the kicad source repo. The start of this topic was how to make sure to
keep the doc up to date. This is what I was trying to comment on. Here it
is better to track the work where it is to be done, in the kicad-doc repo.
That does not hinder anyone from grepping the kicad commit log for new
features, when one gets the urge to create documentation. This shall of
course not hinder anyone who submits a feature to kicad to also submit
documentation updates for it either.

When we release I expect a release note to be composed that will describe
the new features as we did with http://kicad-pcb.org/post/release-4.0.0/

2017-11-09 12:39 GMT+01:00 Kristoffer Ödmark :


That doesnt sound like a good idea, when adding patches, just having to
add a line or two to the commit message seems best, and I imagine the news
or changelog file is just there to later help the kicad-doc repo to do a
proper changelog. Having to go to a new repo seems a bit more annoying.

Or skip the file totally this time, and just enfore the commit messages.
This way this will not be such a hassle next time one wonders what have
changed between versions.

On 11/09/2017 11:05 AM, Nick Østergaard wrote:


I think this might be better handled as bugs on the kicad-doc repo. Then
everyone can contribute easily and we can track it for the documentation,
where the info is to be used anyways. For now label them new_kicad_feature
if it is.

2017-11-09 10:54 GMT+01:00 Kristoffer Ödmark <
kristofferodmar...@gmail.com >:


 I think for this to start happen, a decision has to be made, and
 enforced by everyone with commit access to the repo.

 Bugfixes need not be tagged like this. Major changes only.

 I still think a we should start collect a list in the repo with
 changes from kicad 4 up to the point this commit message policy is
 set. I for one love reading changelogs when upgrading, and I think
 the users are expecting this as well, and it probably will be useful
 in the FOSDEM presentation :)


 On 11/04/2017 01:53 AM, Wayne Stambaugh wrote:

 On 11/3/2017 8:54 AM, Maciej Sumiński wrote:

 On 11/03/2017 11:30 AM, Kristoffer Ödmark wrote:

 I think starting small would be best in this case. The
 least needed
 would be a "News" File, that is always refering to kicad
 stable.

 I propose the same way that patches with policy errors
 are rejected,
 patches that introduces new functionality or change of
 existing
 functionality are required to add to the News file, max
 one line. Just
 something like this, I would like markdown formatting.


 Changes from Kicad 4
  

Re: [Kicad-developers] wxAUI woes

[hauptmech]

On 28/10/17 01:00, Wayne Stambaugh wrote:

If the pane is mandatory (no view toggle) you probably need to hard-code
unhiding it after LoadPerspective to be nice to users upgrading with
config files in place.

You will most likely have to force the change in the perspective to
ensure that you can unhide panes.  I would be careful about what aui
behavior you enable.  If I recall, detachable panes was also broken but
that make have been fixed.  Have you tried testing with wx 3.1?  Maybe
the wx project fixed some of these issues.

Internal to Aui, there is no such thing as a perspective. It's just just 
the name used to load and save all the pane (and dock) info.


It's been a long time but my recollection is that Aui worked fine once I 
read the [aui] code and got an understanding of how it was designed to 
be used. The written documentation was sparse and kicad authors had 
misinterpreted some of how Aui is supposed to work. EDA_PANEINFO 
(kicad/include/wxstruct.h) captured much of what I learned. My goal at 
the time was detachable panes, which worked without problem once the 
panes were configured properly. My patch left out the final setting for 
detachable panes because everyone was gunshy about aui at the time and 
it was too big a step.





___
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] wxAUI woes

[hauptmech]

That must have been painful to find...

A quick read of the Aui code says yes there is a problem. They hide all 
panels at the beginning of LoadPerspective and then update only panels 
with keys in the configuration string. So anything new and not in the 
config file will stay hidden.


I'm not current on kicad gui policy.  That said, everything works as I 
would expect it to.


A user with an existing config will keep that config and can use the 
pane toggle in the view menu to turn the pane on.
A new user will have an empty config file and will get the default 
config as defined in the code.


Going forward  LoadSettings() or SaveSettings() probably need a property 
filter added, as those are where SavePerspective (and LoadPerspective 
once Dick finishes per his comment in the code) are called.


If the pane is mandatory (no view toggle) you probably need to hard-code 
unhiding it after LoadPerspective to be nice to users upgrading with 
config files in place.


Take a peek at the Aui source code if I didn't explain the above well 
enough and it should quickly make sense.



On 27/10/17 16:32, Oliver Walters wrote:
I finally discovered the issue. To add a new wxAUI pane, I had to go 
into ~/.config/kicad/pcbnew and delete all entries relating to 
modview. After this, I was able to see the new item.


So, is there is a potential problem with 
wxAuiManager::LoadPerspective, if the layout configuration has changed?


On Mon, Oct 16, 2017 at 9:58 PM, hauptmech <hauptm...@gmail.com 
<mailto:hauptm...@gmail.com>> wrote:


Looks like I missed modview_frame at the time so you'll want to
reference one of the other frames and update it. I converted a lot
of erroneous Row() calls to Layer() and standardized the
initialization. On the git repo it's commit bd19d31082...

Remembering more about this now. From back when tearing off the
AUI panels and moving them to a second monitor gave me a crucial
few more cm of room to view my design. These days with a 4K
display it doesn't seem so critical.



    -Hauptmech

On 16/10/17 15:00, Oliver Walters wrote:

The image is 1920x1020, there should be no issue reading the text...

Anyway, the issue is that I have tried to add a new panel to the
module selector window, by copying the code used to add the
panels that are currently there. Compiles ok but when I run KiCad
and open the selector, the new panel is not visible anywhere. I
realize this isn't much of a problem description, but I was
wondering if there was some trick that is undocumented (or
documented somewhere that I haven't found it) that I need to know
to display wxAUI panels.



On Mon, Oct 16, 2017 at 12:29 PM, Greg Smith
<ecomput...@yahoo.com <mailto:ecomput...@yahoo.com>> wrote:

I can't read the text, there's not enough resolution. What is
the issue?

I've had windows that seem to be tucked under the horizontal
toolbar.

Greg S.

On Oct 15, 2017, at 7:46 PM, Oliver Walters
<oliver.henry.walt...@gmail.com
<mailto:oliver.henry.walt...@gmail.com>> wrote:


I'm trying to add a new panel to the module viewer window.
"screenshot" below.

However I can't get wxAUI to play along at all. I cannot
even get a new panel to be displayed in this window. Are
there any particular tricks that may be non-obvious?

https://i.imgur.com/dXj51u1.png
<https://i.imgur.com/dXj51u1.png>

Cheers,

Oliver
___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>





___
Mailing list:https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to :kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe :https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   :https://help.launchpad.net/ListHelp
<https://help.launchpad.net/ListHelp>




___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to     : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/

Re: [Kicad-developers] wxAUI woes

[hauptmech]

Looks like I missed modview_frame at the time so you'll want to 
reference one of the other frames and update it. I converted a lot of 
erroneous Row() calls to Layer() and standardized the initialization. On 
the git repo it's commit bd19d31082...


Remembering more about this now. From back when tearing off the AUI 
panels and moving them to a second monitor gave me a crucial few more cm 
of room to view my design. These days with a 4K display it doesn't seem 
so critical.




-Hauptmech

On 16/10/17 15:00, Oliver Walters wrote:

The image is 1920x1020, there should be no issue reading the text...

Anyway, the issue is that I have tried to add a new panel to the 
module selector window, by copying the code used to add the panels 
that are currently there. Compiles ok but when I run KiCad and open 
the selector, the new panel is not visible anywhere. I realize this 
isn't much of a problem description, but I was wondering if there was 
some trick that is undocumented (or documented somewhere that I 
haven't found it) that I need to know to display wxAUI panels.




On Mon, Oct 16, 2017 at 12:29 PM, Greg Smith <ecomput...@yahoo.com 
<mailto:ecomput...@yahoo.com>> wrote:


I can't read the text, there's not enough resolution. What is the
issue?

I've had windows that seem to be tucked under the horizontal toolbar.

Greg S.

On Oct 15, 2017, at 7:46 PM, Oliver Walters
<oliver.henry.walt...@gmail.com
<mailto:oliver.henry.walt...@gmail.com>> wrote:


I'm trying to add a new panel to the module viewer window.
"screenshot" below.

However I can't get wxAUI to play along at all. I cannot even get
a new panel to be displayed in this window. Are there any
particular tricks that may be non-obvious?

https://i.imgur.com/dXj51u1.png <https://i.imgur.com/dXj51u1.png>

Cheers,

Oliver
___
Mailing list: https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
Post to : kicad-developers@lists.launchpad.net
<mailto:kicad-developers@lists.launchpad.net>
Unsubscribe : https://launchpad.net/~kicad-developers
<https://launchpad.net/%7Ekicad-developers>
More help   : https://help.launchpad.net/ListHelp
<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] wxAUI woes

[hauptmech]

It looks like I left some notes in wxstruct.h/class EDA_PANEINFO way 
back when I set up moveable toolbars for my branch... Not sure if they 
are relevant as this has long faded from my memory.


On 16/10/17 15:00, Oliver Walters wrote:

The image is 1920x1020, there should be no issue reading the text...

Anyway, the issue is that I have tried to add a new panel to the 
module selector window, by copying the code used to add the panels 
that are currently there. Compiles ok but when I run KiCad and open 
the selector, the new panel is not visible anywhere. I realize this 
isn't much of a problem description, but I was wondering if there was 
some trick that is undocumented (or documented somewhere that I 
haven't found it) that I need to know to display wxAUI panels.




On Mon, Oct 16, 2017 at 12:29 PM, Greg Smith > wrote:


I can't read the text, there's not enough resolution. What is the
issue?

I've had windows that seem to be tucked under the horizontal toolbar.

Greg S.

On Oct 15, 2017, at 7:46 PM, Oliver Walters
> wrote:


I'm trying to add a new panel to the module viewer window.
"screenshot" below.

However I can't get wxAUI to play along at all. I cannot even get
a new panel to be displayed in this window. Are there any
particular tricks that may be non-obvious?

https://i.imgur.com/dXj51u1.png 

Cheers,

Oliver
___
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] [PATCH] Dark Theme Fixups

[hauptmech]

Hurray for shovels! And as a fan, thanks Windsor!

On 28/09/17 10:38, Maciej Sumiński wrote:

I am sure that responding to this message awards me the Golden Shovel
for digging out the oldest thread ever, but I think the patch indeed
makes the interface look better.

I changed it a bit to avoid code duplication and managed to test it on
our supported problems without any issues.

On behalf of all dark theme fans, thank you Windsor!

Regards,
Orson




___
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] File format version increment

[hauptmech]

Well put, Wayne and Orson.

@Nox, I agree with you that it's better to have the user drive instead 
of automagic that may cause more confusion than help.


On 22/09/17 00:00, Wayne Stambaugh wrote:

I second Orson's comments.  Our nightly users deserve our gratitude for
testing and filing bug reports.  Thank you.

I wish we had the manpower to support multiple file versions but it's a
feature that has a very high cost for very little net gain.  I realize
it's a less than ideal situation but until we have the manpower, we will
have to live with it.

Wayne

On 9/21/2017 5:53 AM, Maciej Sumiński wrote:

Hi hauptmech,

In the meantime, there is an ongoing work to support custom shape pads,
which also demands a file format version bump (already done, right
before the long pad names patch to avoid too frequent version
increments). Such change calls for another set of if-elses to determine
whether we can reduce the file format version.

It takes some time to write, debug and *maintain* code to select the
most compatible file format version. As all of you know, time is a very
scarce resource in this project, which could be better spent on fixing
more serious problems or implementing new features. We planned to have
v5 released a few months ago.

On the other side, there are users who may need to cooperate on a
project. If you use nightlies, you implicitly agree to experience some
disturbances on the way, but we do as much as we can to reduce them
(i.e. quickly fix problems). In case of file format version update, all
you need to do is install a newer version. In most cases there is no
need to rebuild KiCad, because there are nightly builds for all major
platforms.

We are very happy to have so many nightly builds users, as you provide
significant help on the testing side. Thanks to you, many problems are
quickly spotted and resolved due to informative bug reports. Perhaps you
do not receive the well-deserved gratitude for taking the risk of
running experimental code, that is why now I loudly say: thank you,
guys! You are an important part of the team!

Regards,
Orson

On 09/21/2017 02:42 AM, hauptmech wrote:

File version issues have hit me a couple times when collaborating.
Solutions involve either installing bunch of binaries, stable first,
then nightlies, until we find a compatible one, or 'fixing' the file by
hand editing to a previous design.

It would be really nice to the user if you used the old file version for
designs that had no long names. (or whatever other incremental special
case feature change required the version bump)

I know writing code with different types of users in different
situations takes extra effort, but everything you guys do so that kicad
*just works* on the user side has a huge impact.




On 20/09/17 04:38, Maciej Sumiński wrote:

For your information: support for long pad and pin names has been just
merged. As the change affects both eeschema and pcbnew, and may result
in files that are not loaded correctly with older versions - the file
format versions had to be incremented.

Regards,
Orson



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
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] File format version increment

[hauptmech]

File version issues have hit me a couple times when collaborating. 
Solutions involve either installing bunch of binaries, stable first, 
then nightlies, until we find a compatible one, or 'fixing' the file by 
hand editing to a previous design.


It would be really nice to the user if you used the old file version for 
designs that had no long names. (or whatever other incremental special 
case feature change required the version bump)


I know writing code with different types of users in different 
situations takes extra effort, but everything you guys do so that kicad 
*just works* on the user side has a huge impact.





On 20/09/17 04:38, Maciej Sumiński wrote:

For your information: support for long pad and pin names has been just
merged. As the change affects both eeschema and pcbnew, and may result
in files that are not loaded correctly with older versions - the file
format versions had to be incremented.

Regards,
Orson



___
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] [RFC] Proof of concept of mathematical expression input for text fields.

[hauptmech]

or perhaps the python parser is already used in enough kicad builds that 
it should be used?


On 28/08/17 19:56, Tomasz Wlostowski wrote:

On 27.08.2017 22:28, Marco Ciampa wrote:

+1 muparser is already present in many distros:

apt-cache search muparser
libmuparser-dev - fast mathematical expressions parse library (development)
libmuparser-doc - fast mathematical expressions parser library (documentation)
libmuparser2v5 - fast mathematical expressions parser library (runtime)

...And exprtk is a single header file, which compiles on any OS. There
is life outside Linux, too.

- my 5 cents,
Tom


___
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] Additional Patch for via properties dialog (2)

[hauptmech]

On 22/08/17 18:25, jp charras wrote:

Le 22/08/2017 à 05:55, hauptmech a écrit :

Manufacturing techniques vary between manufacturers and continuously evolve. 
Why would kicad limit
itself to what eurocircuits can do? They have optimized their process for quick 
turn prototyping and
while they document their process nicely, they are probably not a good 
reference for what can be done.

On 21/08/17 05:44, jp charras wrote:

Before working on blind and buried vias dialog, please have a look at:
https://www.eurocircuits.com/blog/Blind-and-buried-vias

Currently there is no control in Kicad.

Sure, but it looks like there are some constraints on blind/buried vias 
(microvias are blind/buried
vias) depending on board houses.

So it could be worth to be able to control these constraints inside Kicad (at 
least to have a
minimal control).

We currently have a DRC which detects too small clearances and track widths:
this is most of time due to manufacturing constraints which continuously evolve.

I don't think I have enough understanding of the proposal to have an 
opinion. I just want to caution against creating unnecessary limitations 
in kicad. It really depends on the board house. I used to work for one 
and there were quite a few atypical techniques used for customer 
specific projects (many kept confidential to that customer).






___
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] Additional Patch for via properties dialog (2)

[hauptmech]

Manufacturing techniques vary between manufacturers and continuously 
evolve. Why would kicad limit itself to what eurocircuits can do? They 
have optimized their process for quick turn prototyping and while they 
document their process nicely, they are probably not a good reference 
for what can be done.


On 21/08/17 05:44, jp charras wrote:

Before working on blind and buried vias dialog, please have a look at:
https://www.eurocircuits.com/blog/Blind-and-buried-vias




___
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] Netclass and clearance

[hauptmech]

I think the following is part of the assumptions of everyone ideas so 
far, but I just want to state it explicitly as it's a really fundamental 
assumption for me.


The purpose of pcbnew is to generate manufacturing data for pcb 
manufacture. Users should be limited only by their imagination and 
manufacturers process limits, not by kicad.


DRC, (especially in it's current form) can only handle a subset of the 
above. And that's ok as long as we remember that DRC is an assist for 
many, but not all, users. (I happen to be one of the 'not all' users).


Likewise, layout assist tools as they are now only handle a subset. 
Again, ok as long as the user has foundation tools to make the shapes 
they need. Kicad does not do the best job here, but thanks to the text 
file format and some thankfully loose checks for correctness, external 
tools can do things like put arcs on copper layers and do complex 
interpolated shapes, after which one can still do some things in the 
editor and make correct manufacturing files.


Bottom line, kicad is just one stop in the chain from a users 
imagination to finished PCBs. Assisting the users in this is awesome. 
But be careful about blocking the user when they need to fall back on 
more basic/manual techniques to do their job.


The DRC tool is useful, but the way I used it (had to) was to generate a 
report files at multiple default netclass clearances with all the 
violations and the grep the file for the violations that were valid for 
me.  Having DRC "pass" with no violations has no meaning once the rules 
are different than the netclass approach.


But while a more generic approach would be cool, it's not what I needed 
last night at 1am. What I needed was to be able to set a routing 
clearance at anytime for any amount, for the drc reporting to let me set 
the minimum clearance and be a little richer (distance rather than 
go/no-go in the file).






___
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] Netclass and clearance

[hauptmech]

This is a nice concept. A more generic constraint system.

What I'll be doing and was asking if there was others needing, is the 
pre-net-class approach of a single clearance that is easily adjusted 
while laying tracks.


I think this used to be there. Having it would not affect netclass 
behaviour or drc behaviour, but would allow manual control of clearance 
for the situations where useful.


On 27/07/17 01:17, Maciej Sumiński wrote:

Hi hauptmech,

I am sure there are many users who would benefit from the suggested DRC
improvements, so I would say it is an interesting idea. There is a plan
to upgrade it, but I am afraid you will have you board finished before
this happens.

It is not entirely clear to me what do you propose. At the moment there
is an option to set clearance per net class, so I assume you want to be
able to set clearance per [net class,layer] pair. How do you want to
modify the user interface (Design Rules Editor dialog)?

I am not sure how much time are you willing to spend on this, but if I
were to implement such feature, then I would:
- in the "Net Classes Editor" remove the grid widget where you specify
the constraints (clearance, track width, etc.)
- add a new tab "Constraints" with a list widget and two buttons: "Add"
and "Remove"
- the "Add" button invokes a dialog where you can specify the target for
the rule (Net/Net Class/Layer) and the type of constraint you want to
apply (clearance, track width, etc). For each category used to specify
the target (Net/Net Class/Layer) one selects 'Any' or a concrete value.

This way the design rules definition become very flexible as you may
easily specify exact targets. In case there is more than one rule for an
item, the strictest one applies. For items that do not trigger any of
the rules, the global design rules are used.

To give an rule set example with your case:
- global design rules: whatever your PCB house is able to manufacture
- inner layers, any net: 0.1 mm width
- outer layers, any net: 0.3 mm width

Regards,
Orson

On 07/26/2017 10:05 AM, hauptmech wrote:

I have nets that have different clearance requirements depending on
where they are. There are two situations that are in my designs:

1) Technical/Manufacturing limitations: Trace and space limitations
depend on layer copper thickness and whether it's an inner layer or
outer layer. For instance, my current project has 0.1mm trace and space
and a 15um thick copper layer on one pair of inner layers. Outer layers
are 30um and use 0.125mm minimum trace and space because 0.1 can't be
done at that copper thickness.

2) Designers preference: I like to move to larger traces and spaces when
the component spacing allows. Apart from a mild optimization on current
carrying capacity and capacitive coupling, there is not a big technical
reason; it's just the way I like to do things.

Both of these things have me manually changing the default netclass
clearance constantly, and when I forget to change it back to the larger
trace and space I have to redo chunks of layout. Happens more often that
I'd like to admit. A sign of aging I guess.

Running the DRC I first do a pass at the lowest clearance, and then
(doing this now) run the same DRC on a larger clearance and check each
error to see if it's real (many are) or allowed for the layer and
location manually.

There's a lot of ways to approach this issue and a 'good' way to do this
has not occured to me yet. Meanwhile I have work to do. I'm seeing a big
chunk of work in 2013 by Dick on the netclass and vaguely remember
clearance being as settable as trace width once upon a time.

Pulling forward the old clearance setting widgets and possibly allow
specifying layers for the DRC are what I'm looking at doing in my
personal branch. Probably add a 'netclass' default entry in the
clearance dropdown I am remembering

All this to ask, does anyone else have issues with the netclass approach
to clearance and would the mainline want an integration of both netclass
and manually set clearances?

-hauptmech



___
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] Performance issues in pcbnew

[hauptmech]

Could you test this patch, and see if it changes something in performance 
issues in pcbnew?
Thanks.



___
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



Now I'm scratching my head here. I rolled the patch back and the 
subjective framerate did not change back to the slow one.


I can confirm that perf reports that the top call chain used to be 
active about 42% of the time, 28% of which was BuildSheetList and is now 
active about 16% of the time.  So a definitive internal improvement.


For the interactivity, I don't know. It's interactive now  and was not 
before I built your patch but very possibly my interactivity problem was 
something else. I was running a release build off of master from the 
last couple days.


___
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] Performance issues in pcbnew

[hauptmech]

On 26/07/17 20:11, jp charras wrote:

Could you test this patch, and see if it changes something in performance 
issues in pcbnew?
Thanks.

-- Jean-Pierre CHARRAS


Wow! Night and day. For pan and zoom my frame rate is now interactive. 
Subjectively it was somewhere between 0.5 and 2 frames per second before 
and seems closer to 10FPS now.


Thanks!


___
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] Netclass and clearance

[hauptmech]

I have nets that have different clearance requirements depending on 
where they are. There are two situations that are in my designs:


1) Technical/Manufacturing limitations: Trace and space limitations 
depend on layer copper thickness and whether it's an inner layer or 
outer layer. For instance, my current project has 0.1mm trace and space 
and a 15um thick copper layer on one pair of inner layers. Outer layers 
are 30um and use 0.125mm minimum trace and space because 0.1 can't be 
done at that copper thickness.


2) Designers preference: I like to move to larger traces and spaces when 
the component spacing allows. Apart from a mild optimization on current 
carrying capacity and capacitive coupling, there is not a big technical 
reason; it's just the way I like to do things.


Both of these things have me manually changing the default netclass 
clearance constantly, and when I forget to change it back to the larger 
trace and space I have to redo chunks of layout. Happens more often that 
I'd like to admit. A sign of aging I guess.


Running the DRC I first do a pass at the lowest clearance, and then 
(doing this now) run the same DRC on a larger clearance and check each 
error to see if it's real (many are) or allowed for the layer and 
location manually.


There's a lot of ways to approach this issue and a 'good' way to do this 
has not occured to me yet. Meanwhile I have work to do. I'm seeing a big 
chunk of work in 2013 by Dick on the netclass and vaguely remember 
clearance being as settable as trace width once upon a time.


Pulling forward the old clearance setting widgets and possibly allow 
specifying layers for the DRC are what I'm looking at doing in my 
personal branch. Probably add a 'netclass' default entry in the 
clearance dropdown I am remembering


All this to ask, does anyone else have issues with the netclass approach 
to clearance and would the mainline want an integration of both netclass 
and manually set clearances?


-hauptmech



___
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] Performance issues in pcbnew

[hauptmech]

This would be a demo for testing only. I'll have to obfuscate and 
sabatoge parts.  Still useful?



On 25/07/17 02:07, Wayne Stambaugh wrote:

I would accept a patch for a more complex demo for performance testing
purposes.

On 7/24/2017 4:05 AM, Kristoffer Ödmark wrote:

I for one would really appreciate having a larger testproject in the demos.

- Kristoffer

On 07/24/2017 01:36 AM, hauptmech wrote:

I'm getting a distracting amount of lag when panning and zooming with
GAL. Perf reports TOOL_MANAGER::dispatchInternal and, when eeschema is
open, SCH_SHEET_LIST::BuildSheetList, as the main time sinks.

Anyone have any hints for me improve this?

In general I'm getting the impression that the design I'm working on
is a bit more complex than the developers normally test on. I'll see
if my client will allow a sanitized version of this board to go into
/demos.

-hauptmech





___
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] Performance issues in pcbnew

[hauptmech]

I haven't learned enough about the KIWAY to trace the events from pcbnew 
to eeschema yet.


I'd be curious is this is reproducible in other systems. Easy to test on 
linux using the perf tool https://perf.wiki.kernel.org/index.php/Main_Page


1) run kicad, open a pcb and schematic of any size.
2) in a terminal run > perf record -g -p $(pidof kicad)
3) pan and zoom the pcb continuously for a statistically significant 
time (about 15-30 sec works for me).

4) CTRL C stop perf
5) > perf report

On a release build SCH_SHEET_LIST() or a sub function shows up at the top.



On 25/07/17 10:25, Wayne Stambaugh wrote:

On 7/24/2017 6:12 PM, hauptmech wrote:

Yeah, it's weird since all I'm doing when collecting perf data is
zooming and panning the pcb, (with eeschema open).  A root page and 11
sub pages at the next level. Roughly 800 components and 2000 wires.

Probably something somewhere is instantiating a new SCH_SHEET_LIST
(which then has to chew through each and every schematic item to find
the sheets) on every event?

This is even more disturbing.  When did we start building the sheet list
in pcbnew and more importantly why?




On 25/07/17 01:59, Wayne Stambaugh wrote:

On 7/23/2017 7:36 PM, hauptmech wrote:

I'm getting a distracting amount of lag when panning and zooming with
GAL. Perf reports TOOL_MANAGER::dispatchInternal and, when eeschema is
open, SCH_SHEET_LIST::BuildSheetList, as the main time sinks.

Given that all BuildSheetList does is create a list of unique sheets in
a schematic, I find it difficult to believe that you would have that
many sheets (hierarchical or otherwise) that would cause a performance
hit.  How many sheets does your design have and how deeply are they
nested?


Anyone have any hints for me improve this?

In general I'm getting the impression that the design I'm working on is
a bit more complex than the developers normally test on. I'll see if my
client will allow a sanitized version of this board to go into /demos.

-hauptmech





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
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] Performance issues in pcbnew

[hauptmech]

I don't see anything that suggests pcbnew is doing sheet list stuff. I 
was assuming that whatever event connection between pcbnew and eeschema 
exists was the culprit.




On 25/07/17 10:25, Wayne Stambaugh wrote:

On 7/24/2017 6:12 PM, hauptmech wrote:

Yeah, it's weird since all I'm doing when collecting perf data is
zooming and panning the pcb, (with eeschema open).  A root page and 11
sub pages at the next level. Roughly 800 components and 2000 wires.

Probably something somewhere is instantiating a new SCH_SHEET_LIST
(which then has to chew through each and every schematic item to find
the sheets) on every event?

This is even more disturbing.  When did we start building the sheet list
in pcbnew and more importantly why?




On 25/07/17 01:59, Wayne Stambaugh wrote:

On 7/23/2017 7:36 PM, hauptmech wrote:

I'm getting a distracting amount of lag when panning and zooming with
GAL. Perf reports TOOL_MANAGER::dispatchInternal and, when eeschema is
open, SCH_SHEET_LIST::BuildSheetList, as the main time sinks.

Given that all BuildSheetList does is create a list of unique sheets in
a schematic, I find it difficult to believe that you would have that
many sheets (hierarchical or otherwise) that would cause a performance
hit.  How many sheets does your design have and how deeply are they
nested?


Anyone have any hints for me improve this?

In general I'm getting the impression that the design I'm working on is
a bit more complex than the developers normally test on. I'll see if my
client will allow a sanitized version of this board to go into /demos.

-hauptmech





___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp


___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
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] Performance issues in pcbnew

[hauptmech]

Yeah, it's weird since all I'm doing when collecting perf data is 
zooming and panning the pcb, (with eeschema open).  A root page and 11 
sub pages at the next level. Roughly 800 components and 2000 wires.


Probably something somewhere is instantiating a new SCH_SHEET_LIST 
(which then has to chew through each and every schematic item to find 
the sheets) on every event?




On 25/07/17 01:59, Wayne Stambaugh wrote:

On 7/23/2017 7:36 PM, hauptmech wrote:

I'm getting a distracting amount of lag when panning and zooming with
GAL. Perf reports TOOL_MANAGER::dispatchInternal and, when eeschema is
open, SCH_SHEET_LIST::BuildSheetList, as the main time sinks.

Given that all BuildSheetList does is create a list of unique sheets in
a schematic, I find it difficult to believe that you would have that
many sheets (hierarchical or otherwise) that would cause a performance
hit.  How many sheets does your design have and how deeply are they nested?


Anyone have any hints for me improve this?

In general I'm getting the impression that the design I'm working on is
a bit more complex than the developers normally test on. I'll see if my
client will allow a sanitized version of this board to go into /demos.

-hauptmech





___
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] Performance issues in pcbnew

[hauptmech]

I'm getting a distracting amount of lag when panning and zooming with 
GAL. Perf reports TOOL_MANAGER::dispatchInternal and, when eeschema is 
open, SCH_SHEET_LIST::BuildSheetList, as the main time sinks.


Anyone have any hints for me improve this?

In general I'm getting the impression that the design I'm working on is 
a bit more complex than the developers normally test on. I'll see if my 
client will allow a sanitized version of this board to go into /demos.


-hauptmech





___
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] Via tool in Pcbnew.

[hauptmech]

Hi Orson,

I do agree that a single solution does not satisfy everyone, nor does it 
have to.


I was just adding my voice to Heikki's that the PNS router does not 
quite handle some of the basic tasks that I am needing to do, that the 
legacy interface does handle. The details are complex, partially rooted 
in the fact that net class based clearances are not a good approach for 
my current situation where I need to use mixed trace/space technology on 
the same nets. Meanwhile I'm dropping back to the legacy interface 
occasionally to make progress and that fact is significant in itself.


Dragging track nodes, including dragging the free end of a track that is 
in progress but also in the way of the track I'm laying, is the 
difference that causes me to drop back the most.


The assumption in the PNS that I want 45degree angles when dragging a 
track and that the free end of a track should be fixed, don't work for 
me. (However these are things I'd tweak to suit myself if others had no 
need)


The ability to delete a segment (or walkaround chain) is something from 
the legacy that I would bring over to my own branch if the core team did 
not.


The frequent mouse click drops I have not had time to understand enough 
to file a bug report. Whether it is PNS event handling or the load put 
on the system by PNS plus kicad or WX, I don't know.



On 20/07/17 23:41, Maciej Sumiński wrote:

Hi hauptmech,

On 07/20/2017 12:31 PM, hauptmech wrote:

I'm with Heikki. I've been using the GAL canvas for a complex project. I
don't really have time to learn the nuances of the interactive router; I
found that highlight collisions kept it from doing stuff I did not want
in tight layouts and I fall back to legacy for things like tweaking
track nodes and when I get tired of dropped mouse clicks.

Is there any related bug report so we could investigate the problem?

We realize that *any* change will have its opponents, therefore PNS
offers the highlight collision mode which is meant to work as the legacy
router. What is the difference in your opinion?


It's hard to articulate well, but I get the feeling that the interactive
router is either based on a single companies layout culture, or, with
the utmost respect for all the awesome hard work that's gone into it,
the authors are copying features in other software rather than working
with the needs and user stories of users that they are in contact with.

Do you agree it is very hard to satisfy everyone with a single solution?
KiCad offers multiple options to adjust it to your needs. We would love
to hear your story, but please keep in mind that we are simply unable to
fulfill all requests.

Regards,
Orson



___
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] Via tool in Pcbnew.

[hauptmech]

I'm with Heikki. I've been using the GAL canvas for a complex project. I 
don't really have time to learn the nuances of the interactive router; I 
found that highlight collisions kept it from doing stuff I did not want 
in tight layouts and I fall back to legacy for things like tweaking 
track nodes and when I get tired of dropped mouse clicks.


It's hard to articulate well, but I get the feeling that the interactive 
router is either based on a single companies layout culture, or, with 
the utmost respect for all the awesome hard work that's gone into it, 
the authors are copying features in other software rather than working 
with the needs and user stories of users that they are in contact with.


Not that the legacy canvas is a perfect interface.

On 20/07/17 22:04, Lorenzo Marcantonio wrote:

On Thu, Jul 20, 2017 at 12:47:50PM +0300, Heikki Pulkkinen wrote:

Hi Wayne

Why not support legacy users? Why everybody should use gal canvas? Do not
have to answer, just try to understand your politics.

It's legacy because new tools are not available for it, like the P router

However before junking it *please* implement everything on the new one
(like the cursor behaviour which is way more useful to measure than the
new tool in the GAL view)



___
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] Improving SCM behaviour of kicad_pcb

[hauptmech]

We have a fairly complex board that needs to be done yesterday. We've 
been experimenting with simultaneous editing of the pcb with moderate 
success.


We are using git. Each person works in a different area of the board, 
and we merge the results periodically.


Because of the time crunch, we are only focusing on what works in this 
process, and staying away from edits that do not work. Moving footprints 
and laying tracks works fine.


A couple things I've noticed that could improve things:

net indexes of nets are not stable. Maybe eeschema/netlist.cpp:369   
Maybe we could wait until we get close to running out of integers before 
we do this?


module order gets changed in some edits (Not sure but probably "fix 
module file details and update modules in pcb" type edits). Ordering 
modules by reference would fix this.



We are getting enough benefit that we'll keep refining the technique.







___
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] Bump for arc tracks

[hauptmech]

I was missing the piecewise linear approximation of the higher order 
shapes part.


I don't know the answer.

My instinct is that for arcs the direct analytic tests for proximity and 
intersection are faster tests on an accurate piecewise linear 
approximation. But on the other hand, if you only have one datatype 
(triangles) then it's easier to push the calculation onto a GPU.



On 1/07/17 12:57, Greg Smith wrote:

I don't think you are missing anything. I was thinking that converting everything to line 
segments might make DRC faster. I haven't dug into the DRC code, but perhaps it relies on 
collision functions provided by the shape type itself (which theoretically could be 
either "true" arc calculations, or could be calculated with cached 
converted-to-line-segments shape if needed). If this is the case, maybe there's nothing 
substantial to do regarding my comment.

Greg S.


On Jun 30, 2017, at 6:24 PM, hauptmech <hauptm...@gmail.com> wrote:

Interesting idea. It might be a false comparison since we are choosing between 
a line segement chain and a curve segement chain composed of only lines.

For the maths aspect, the computational speed is equal.

For optimizations involving memory footprint and data structure traversal 
speed, I'm not able to come up with any that can only be done on the line 
segement chain and not on a curve segament chain.

Am I missing something?



On 30/06/17 23:57, Greg Smith wrote:
Is SHAPE_LINE_CHAIN a core element that potentially an ARC might be translated 
to for display, DRC, or other output needs? If so, it seems that they would be 
separate with a conversion function from ARC to SHAPE_LINE_CHAIN and there 
would be SHAPE_ARC_CHAIN or SHAPE_SEGMENT_CHAIN (or similar) that would contain 
both straight lines and arcs (and other non straight shapes).

Main point: seems like a structure for only straight lines would facilitate the 
speed other features and analysis.

Greg S.


On Jun 30, 2017, at 6:47 AM, hauptmech <hauptm...@gmail.com> wrote:


At first glance it looks like SHAPE_LINE_CHAIN and TRACK  are the points where 
the development clings to straight lines the most.

One could add a single variable to line segment data structures so that they 
could also represent arcs.

or

One could add a layer of abstraction so that curves and areas were piecewise 
constructs of whatever curve segments get implemented. (arcs, ellipsoids, 
spirals, splines, fractals, etc). SHAPE_LINE_CHAIN and TRACK would be lists of 
curve segments rather than lists of line vertices as they are now.

I'd hesitate to start anything without some support for the full picture.




On 30/06/17 21:11, Tomasz Wlostowski wrote:
On 30.06.2017 11:05, hauptmech wrote:
I asked earlier this year whether there was any interest in arc tracks
and got little response.

My use case was importing altium files.

Are any of the core developers likely to accept work in this direction?

Hi,

Sure, it would be awesome if someone could work on it. It's not in the
plans for the 5.0 release, although some base code for handling arc
tracks could be already written: geometry functions that we'll need for DRC:

- implement a SHAPE_ARC for the geometry library, describing a non-zero
thickness arc
- write an arc to segment collision function (see SHAPE::Collide)
- write an arc to arc collision function.

Cheers,
Tom


___
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] Bump for arc tracks

[hauptmech]

Interesting idea. It might be a false comparison since we are choosing 
between a line segement chain and a curve segement chain composed of 
only lines.


For the maths aspect, the computational speed is equal.

For optimizations involving memory footprint and data structure 
traversal speed, I'm not able to come up with any that can only be done 
on the line segement chain and not on a curve segament chain.


Am I missing something?


On 30/06/17 23:57, Greg Smith wrote:

Is SHAPE_LINE_CHAIN a core element that potentially an ARC might be translated 
to for display, DRC, or other output needs? If so, it seems that they would be 
separate with a conversion function from ARC to SHAPE_LINE_CHAIN and there 
would be SHAPE_ARC_CHAIN or SHAPE_SEGMENT_CHAIN (or similar) that would contain 
both straight lines and arcs (and other non straight shapes).

Main point: seems like a structure for only straight lines would facilitate the 
speed other features and analysis.

Greg S.


On Jun 30, 2017, at 6:47 AM, hauptmech <hauptm...@gmail.com> wrote:


At first glance it looks like SHAPE_LINE_CHAIN and TRACK  are the points where 
the development clings to straight lines the most.

One could add a single variable to line segment data structures so that they 
could also represent arcs.

or

One could add a layer of abstraction so that curves and areas were piecewise 
constructs of whatever curve segments get implemented. (arcs, ellipsoids, 
spirals, splines, fractals, etc). SHAPE_LINE_CHAIN and TRACK would be lists of 
curve segments rather than lists of line vertices as they are now.

I'd hesitate to start anything without some support for the full picture.




On 30/06/17 21:11, Tomasz Wlostowski wrote:

On 30.06.2017 11:05, hauptmech wrote:
I asked earlier this year whether there was any interest in arc tracks
and got little response.

My use case was importing altium files.

Are any of the core developers likely to accept work in this direction?

Hi,

Sure, it would be awesome if someone could work on it. It's not in the
plans for the 5.0 release, although some base code for handling arc
tracks could be already written: geometry functions that we'll need for DRC:

- implement a SHAPE_ARC for the geometry library, describing a non-zero
thickness arc
- write an arc to segment collision function (see SHAPE::Collide)
- write an arc to arc collision function.

Cheers,
Tom



___
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] Bump for arc tracks

[hauptmech]

At first glance it looks like SHAPE_LINE_CHAIN and TRACK  are the points 
where the development clings to straight lines the most.


One could add a single variable to line segment data structures so that 
they could also represent arcs.


or

One could add a layer of abstraction so that curves and areas were 
piecewise constructs of whatever curve segments get implemented. (arcs, 
ellipsoids, spirals, splines, fractals, etc). SHAPE_LINE_CHAIN and TRACK 
would be lists of curve segments rather than lists of line vertices as 
they are now.


I'd hesitate to start anything without some support for the full picture.



On 30/06/17 21:11, Tomasz Wlostowski wrote:

On 30.06.2017 11:05, hauptmech wrote:

I asked earlier this year whether there was any interest in arc tracks
and got little response.

My use case was importing altium files.

Are any of the core developers likely to accept work in this direction?

Hi,

Sure, it would be awesome if someone could work on it. It's not in the
plans for the 5.0 release, although some base code for handling arc
tracks could be already written: geometry functions that we'll need for DRC:

- implement a SHAPE_ARC for the geometry library, describing a non-zero
thickness arc
- write an arc to segment collision function (see SHAPE::Collide)
- write an arc to arc collision function.

Cheers,
Tom




___
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] Bump for arc tracks

[hauptmech]

I asked earlier this year whether there was any interest in arc tracks 
and got little response.


My use case was importing altium files.

Are any of the core developers likely to accept work in this direction?



___
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] Remove hardcoded hotkeys that have a context menu to fall back on.

[hauptmech]

Fixed blocked Lock/Unlock hotkey.
Add hotkeys for Select Trivial Connection and Select Copper Connection
---
 pcbnew/hotkeys.cpp  | 7 ++-
 pcbnew/hotkeys.h| 4 +++-
 pcbnew/router/pns_tool_base.cpp | 2 +-
 pcbnew/router/router_tool.cpp   | 4 ++--
 pcbnew/tools/pcb_editor_control.cpp | 6 +++---
 pcbnew/tools/selection_tool.cpp | 4 ++--
 6 files changed, 17 insertions(+), 10 deletions(-)


This was the minimum hotkey fix that I needed to get up and running. If
there are no issues I will create hotkey descriptors for the remaining
hardcoded keys.
diff --git a/pcbnew/hotkeys.cpp b/pcbnew/hotkeys.cpp
index e4239518b..54cd922e3 100644
--- a/pcbnew/hotkeys.cpp
+++ b/pcbnew/hotkeys.cpp
@@ -237,6 +237,10 @@ static EDA_HOTKEY HkIncLayerAlhpa( _HKI( "Increment Layer Transparency" ), HK_IN
 
 static EDA_HOTKEY HkDecLayerAlhpa( _HKI( "Decrement Layer Transparency" ), HK_DEC_LAYER_ALHPA, '{' );
 
+static EDA_HOTKEY HkSelectConnection( _HKI( "Select Trivial Connection" ), HK_SEL_TRIVIAL_CONNECTION, 'U' );
+
+static EDA_HOTKEY HkSelectCopper( _HKI( "Select Copper Connection" ), HK_SEL_COPPER_CONNECTION, 'I' );
+
 // List of common hotkey descriptors
 EDA_HOTKEY* common_Hotkey_List[] =
 {
@@ -288,7 +292,8 @@ EDA_HOTKEY* board_edit_Hotkey_List[] =
 ,  ,  ,
 ,
 ,  ,   ,
-,   ,
+,   ,  ,
+,
 NULL
 };
 
diff --git a/pcbnew/hotkeys.h b/pcbnew/hotkeys.h
index 36b91e944..6ddd6c764 100644
--- a/pcbnew/hotkeys.h
+++ b/pcbnew/hotkeys.h
@@ -103,7 +103,9 @@ enum hotkey_id_commnand {
 HK_ZONE_FILL_OR_REFILL,
 HK_ZONE_REMOVE_FILLED,
 HK_INC_LAYER_ALHPA,
-HK_DEC_LAYER_ALHPA
+HK_DEC_LAYER_ALHPA,
+HK_SEL_TRIVIAL_CONNECTION,
+HK_SEL_COPPER_CONNECTION
 };
 
 // Full list of hotkey descriptors for board editor and footprint editor
diff --git a/pcbnew/router/pns_tool_base.cpp b/pcbnew/router/pns_tool_base.cpp
index f8b484991..49f9d0369 100644
--- a/pcbnew/router/pns_tool_base.cpp
+++ b/pcbnew/router/pns_tool_base.cpp
@@ -61,7 +61,7 @@ using namespace KIGFX;
 namespace PNS {
 
 TOOL_ACTION TOOL_BASE::ACT_RouterOptions( "pcbnew.InteractiveRouter.RouterOptions",
-AS_CONTEXT, 'E',
+AS_CONTEXT, 0,
 _( "Routing Options..." ),
 _( "Shows a dialog containing router options." ), tools_xpm );
 
diff --git a/pcbnew/router/router_tool.cpp b/pcbnew/router/router_tool.cpp
index 61f34d361..d25100202 100644
--- a/pcbnew/router/router_tool.cpp
+++ b/pcbnew/router/router_tool.cpp
@@ -163,7 +163,7 @@ static const TOOL_ACTION ACT_SelLayerAndPlaceBlindVia(
 (void*) ( VIA_ACTION_FLAGS::BLIND_VIA | VIA_ACTION_FLAGS::SELECT_LAYER ) );
 
 static const TOOL_ACTION ACT_CustomTrackWidth( "pcbnew.InteractiveRouter.CustomTrackViaSize",
-AS_CONTEXT, 'Q',
+AS_CONTEXT, 0,
 _( "Custom Track/Via Size" ),
 _( "Shows a dialog for changing the track width and via size." ),
 width_track_xpm );
@@ -175,7 +175,7 @@ static const TOOL_ACTION ACT_SwitchPosture( "pcbnew.InteractiveRouter.SwitchPost
 change_entry_orient_xpm );
 
 static const TOOL_ACTION ACT_SetDpDimensions( "pcbnew.InteractiveRouter.SetDpDimensions",
-AS_CONTEXT, 'P',
+AS_CONTEXT, 0,
 _( "Differential Pair Dimensions..." ),
 _( "Sets the width and gap of the currently routed differential pair." ),
 ps_diff_pair_tune_length_xpm );
diff --git a/pcbnew/tools/pcb_editor_control.cpp b/pcbnew/tools/pcb_editor_control.cpp
index 163cca5c5..7ab80f147 100644
--- a/pcbnew/tools/pcb_editor_control.cpp
+++ b/pcbnew/tools/pcb_editor_control.cpp
@@ -70,11 +70,11 @@ TOOL_ACTION PCB_ACTIONS::trackWidthDec( "pcbnew.EditorControl.trackWidthDec",
 "", "" );
 
 TOOL_ACTION PCB_ACTIONS::viaSizeInc( "pcbnew.EditorControl.viaSizeInc",
-AS_GLOBAL, '\'',
+AS_GLOBAL,0,
 "", "" );
 
 TOOL_ACTION PCB_ACTIONS::viaSizeDec( "pcbnew.EditorControl.viaSizeDec",
-AS_GLOBAL, '\\',
+AS_GLOBAL, 0,
 "", "" );
 
 TOOL_ACTION PCB_ACTIONS::trackViaSizeChanged( "pcbnew.EditorControl.trackViaSizeChanged",
@@ -126,7 +126,7 @@ TOOL_ACTION PCB_ACTIONS::crossProbeSchToPcb( "pcbnew.EditorControl.crossProbSchT
 "", "" );
 
 TOOL_ACTION PCB_ACTIONS::toggleLock( "pcbnew.EditorControl.toggleLock",
-AS_GLOBAL, 'L',
+AS_GLOBAL, TOOL_ACTION::LegacyHotKey( HK_LOCK_UNLOCK_FOOTPRINT ),
 "Toggle Lock", "" );
 
 TOOL_ACTION PCB_ACTIONS::lock( "pcbnew.EditorControl.lock",
diff --git a/pcbnew/tools/selection_tool.cpp b/pcbnew/tools/selection_tool.cpp
index f05424670..f024b8ead 100644
--- a/pcbnew/tools/selection_tool.cpp
+++ b/pcbnew/tools/selection_tool.cpp
@@ -87,11 +87,11 @@ TOOL_ACTION PCB_ACTIONS::selectionClear( "pcbnew.InteractiveSelection.Clear",
 "", "" );// No description, it is not supposed to be shown 

[Kicad-developers] [PATCH] Improve matchDpSuffix() to match a wider range of differential pair names.

[hauptmech]

As before but with fewer tabs...
diff --git a/pcbnew/router/pns_kicad_iface.cpp b/pcbnew/router/pns_kicad_iface.cpp
index 2960f41e2..922a9a7a5 100644
--- a/pcbnew/router/pns_kicad_iface.cpp
+++ b/pcbnew/router/pns_kicad_iface.cpp
@@ -233,9 +233,9 @@ int PNS_PCBNEW_RULE_RESOLVER::matchDpSuffix( wxString aNetName, wxString& aCompl
 aComplementNet = "-";
 rv = 1;
 }
-else if( aNetName.EndsWith( "_P" ) )
+else if( aNetName.EndsWith( "P" ) )
 {
-aComplementNet = "_N";
+aComplementNet = "N";
 rv = 1;
 }
 else if( aNetName.EndsWith( "-" ) )
@@ -243,12 +243,35 @@ int PNS_PCBNEW_RULE_RESOLVER::matchDpSuffix( wxString aNetName, wxString& aCompl
 aComplementNet = "+";
 rv = -1;
 }
-else if( aNetName.EndsWith( "_N" ) )
+else if( aNetName.EndsWith( "N" ) )
 {
-aComplementNet = "_P";
+aComplementNet = "P";
 rv = -1;
 }
-
+	//Match P followed by 2 digits
+else if( aNetName.Right(2).IsNumber() && aNetName.Right(3).Left(1) == "P" )
+{
+aComplementNet = "N" + aNetName.Right(2);
+rv = 1;
+}
+	//Match P followed by 1 digit
+else if( aNetName.Right(1).IsNumber() && aNetName.Right(2).Left(1) == "P" )
+{
+aComplementNet = "N" + aNetName.Right(1);
+rv = 1;
+}
+	//Match N followed by 2 digits
+else if( aNetName.Right(2).IsNumber() && aNetName.Right(3).Left(1) == "N" )
+{
+aComplementNet = "P" + aNetName.Right(2);
+rv = 1;
+}
+	//Match N followed by 1 digit
+else if( aNetName.Right(1).IsNumber() && aNetName.Right(2).Left(1) == "N" )
+{
+aComplementNet = "P" + aNetName.Right(1);
+rv = 1;
+}
 if( rv != 0 )
 {
 aBaseDpName = aNetName.Left( aNetName.Length() - aComplementNet.Length() );



___
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] Improve matchDpSuffix() to match a wider range of differential pair names.

[hauptmech]

Includes matching bus line nets with one or two terminating digits as
suggested by Tomasz.

In addition to the original +/- and _P/_N suffix, we now match:

Match .*[PN]  ex: ANYNETP <-> ANYNETN
Match .*[PN]\d  ex: ANYNET_P7 <-> ANYNET_N7
Match .*[PN]\d\d ex: SNETP99 <-> SNETN99
---
 pcbnew/router/pns_kicad_iface.cpp | 33 -
 1 file changed, 28 insertions(+), 5 deletions(-)
diff --git a/pcbnew/router/pns_kicad_iface.cpp b/pcbnew/router/pns_kicad_iface.cpp
index 2960f41e2..922a9a7a5 100644
--- a/pcbnew/router/pns_kicad_iface.cpp
+++ b/pcbnew/router/pns_kicad_iface.cpp
@@ -233,9 +233,9 @@ int PNS_PCBNEW_RULE_RESOLVER::matchDpSuffix( wxString aNetName, wxString& aCompl
 aComplementNet = "-";
 rv = 1;
 }
-else if( aNetName.EndsWith( "_P" ) )
+else if( aNetName.EndsWith( "P" ) )
 {
-aComplementNet = "_N";
+aComplementNet = "N";
 rv = 1;
 }
 else if( aNetName.EndsWith( "-" ) )
@@ -243,12 +243,35 @@ int PNS_PCBNEW_RULE_RESOLVER::matchDpSuffix( wxString aNetName, wxString& aCompl
 aComplementNet = "+";
 rv = -1;
 }
-else if( aNetName.EndsWith( "_N" ) )
+else if( aNetName.EndsWith( "N" ) )
 {
-aComplementNet = "_P";
+aComplementNet = "P";
 rv = -1;
 }
-
+	//Match P followed by 2 digits
+else if( aNetName.Right(2).IsNumber() && aNetName.Right(3).Left(1) == "P" )
+{
+aComplementNet = "N" + aNetName.Right(2);
+rv = 1;
+}
+	//Match P followed by 1 digit
+else if( aNetName.Right(1).IsNumber() && aNetName.Right(2).Left(1) == "P" )
+{
+aComplementNet = "N" + aNetName.Right(1);
+rv = 1;
+}
+	//Match N followed by 2 digits
+else if( aNetName.Right(2).IsNumber() && aNetName.Right(3).Left(1) == "N" )
+{
+aComplementNet = "P" + aNetName.Right(2);
+rv = 1;
+}
+	//Match N followed by 1 digit
+else if( aNetName.Right(1).IsNumber() && aNetName.Right(2).Left(1) == "N" )
+{
+aComplementNet = "P" + aNetName.Right(1);
+rv = 1;
+}
 if( rv != 0 )
 {
 aBaseDpName = aNetName.Left( aNetName.Length() - aComplementNet.Length() );



___
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] Differential pair suffix matcher

[hauptmech]

I'm not sure what you mean by supporting busses. Aren't they already 
supported with the current matching code?


Or do you mean routing a bus of pairs in a single action?

On 29/06/17 00:53, Tomasz Wlostowski wrote:

On 28.06.2017 05:23, hauptmech wrote:

Are there any issues with matching "P" and "N" instead of "_P" and "_N"
for the differential pair suffix matcher? I have an existing design with
the former convention. Matching the single letters will also correctly
match the "_P" style suffix.

If the user selects a net that is not a differential pair, but does
match, they would have to cancel. But since it's a user guided
operation, that does not seem too onerous.

There's no issues, but someone needs to write the code for it. I can't
work on Kicad right now, so if you want it done fast, you can contribute
a patch.
The starting point is:

int DIFF_PAIR_PLACER::matchDpSuffix( wxString aNetName, wxString&
aComplementNet, wxString& aBaseDpName )

Also, it might be worth adding support for diff pair busses (e.g.
PAIR0_N, PAIR0_P, PAIR1_N, and so on).

Cheers,
Tom






___
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] Differential pair suffix matcher

[hauptmech]

Are there any issues with matching "P" and "N" instead of "_P" and "_N" 
for the differential pair suffix matcher? I have an existing design with 
the former convention. Matching the single letters will also correctly 
match the "_P" style suffix.


If the user selects a net that is not a differential pair, but does 
match, they would have to cancel. But since it's a user guided 
operation, that does not seem too onerous.





___
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] fp_arc confusion

[hauptmech]

The tokens for circles are fine.

I suspect it will come up about as often as it has (so once in 5 years?).

Perhaps you could a couple lines of documentation for fp_arc in the file 
formats pdf so the next person that encounters this has a chance to 
recognize the error? It would have saved me a bit of time and 
frustration had some (any) documentation been there.





On 28/06/17 03:32, Wayne Stambaugh wrote:

The tokens in the file format match the member names of the DRAWSEGMENT
object so I see how this could be confusing for arcs and circles.
Changing the "start" token to "center" is not a can of worms that I want
to open.

On 6/27/2017 8:45 AM, hauptmech wrote:

Just to clarify, I'm talking about the file format not the internal
implementation.

The file_formats documentation has the old format using 'center' and
'start' for circles and 'start' and 'end' for arcs (which go from a
start point to and end point as the terminology suggests). All good and
well.

fp_circle has 'center' and 'end'. Makes sense.
fp_arc is defined by a center point and a start point. Different than an
arc defined by a start point and an end point.

Arcs are a bit tricky since there are so many representations (choose 3
of center, start, end, and angle). Mislabeling the file format doesn't
help things.

I spent quite a while pouring over my arc generation math before
checking to see if kicad was doing something funny with it's start, end,
angle fp_arcs.  Imagine my surprise to find out there was no such thing
even though the s-expressions said there was and the old file format
confirmed that that was the way kicad did things.

I hope you can see why I thought this is an error.



On 28/06/17 00:07, Wayne Stambaugh wrote:

It's not an error.  Arcs are part of the DRAWSEGMENT object which
encapsulates line segments, arcs, etc.  The start coordinate (m_start
member) is the center point for arcs and circles.  It is documented as
such in the KiCad source.

  wxPoint m_Start;  ///< Line start point or Circle and Arc center


On 6/26/2017 8:19 PM, hauptmech wrote:

In the module s-expressions, what is the rationale for having arc center
labeled 'start' and having the arc starting point labeled 'end'?

This bit me as I was writing an Allegro footprint extractor to kicad and
got confused why my start,end,angle arcs were not displaying correctly.

Assuming it's an error, is there a way to fix the file format or is this
a permanent thing?



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp



___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp

___
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help   : https://help.launchpad.net/ListHelp




___
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