o 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.
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 Vio
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 VECTO
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
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 2
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
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
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 w
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
d 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/201
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 A
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 wit
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 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 control
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 filli
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 alter
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/
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
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
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 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 0
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
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 caugh
od 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
kups 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.
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
t; 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
> >
On 20/03/18 14:07, Seth Hillbrand wrote:
2018-03-19 17:18 GMT-07:00 hauptmech <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
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 re
h 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
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.
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
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 :
> https://bugs.launchpad.net/kicad/+bug/1754049
>
> This patch follows the edict (stat
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
Date: Wed, 14 Mar 2018 22:31:59 +1300
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
platform-specific.
Cheers,
Jeff.
> On 12 Mar 2018, at 22:07, hauptmech 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 fr
dy to know what platform you’re
on, as some of them are platform-specific.
Cheers,
Jeff.
On 12 Mar 2018, at 22:07, hauptmech 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
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: h
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 <mailto:hauptm...@gmail.com>&
https://bugs.launchpad.net/kicad/+bug/1753330
From 5094bf1e3f38ea7f67e7adf79c7bf7c4ab3b2114 Mon Sep 17 00:00:00 2001
From: hauptmech
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
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 cle
ok 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
Date: Wed, 7 Mar 2018 13:12:20 +1300
Subject: [PATCH 1/2] Minimum viable shim for kicad file format to
The attached patch may fix the build error seen after the RPATH patch.
>From 4bdf9c309ae7a794014d5c3240ad8599b1273dc9 Mon Sep 17 00:00:00 2001
From: hauptmech
Date: Tue, 6 Mar 2018 13:46:05 +1300
Subject: [PATCH] Fix dependency bug introduced in RPATH patch e0b33ee8
MIME-Version: 1.0
Cont
:
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 <mailto:hauptm...@gmail.com>>:
If you have any hints on how to reproduce the failure I c
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
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 mailto
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
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 us
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
perations on the PCB that it's difficult to
> see how some things work.
>
> Cirilo
>
> On Sun, Feb 25, 2018 at 1:20 AM, hauptmech wrote:
> > I took a look at what approaches might work to fix this.
> >
> > I looked at removing the RPATH manually, in keeping wit
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
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:
H
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 defau
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 <mailto:hauptm...@gmail.com>>:
Jon Evans, Kristoff
ut 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
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 wor
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
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 Ca
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 sy
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 sa
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" 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 desig
were though).
On 24 Nov 2017 10:21 pm, "Nick Østergaard" wrote:
> This would haven been resolved if you kept the cache lib, IIRC.
>
> Den 24. nov. 2017 4.48 AM skrev "hauptmech" :
>
>> I can confirm unconnected wires. It may be worth noting that I did
On 24 Nov 2017 10:52 pm, "Rene Pöschl" 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 footpr
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 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
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?
___
On 23/11/17 10:51, Wayne Stambaugh wrote:
On 11/22/2017 4:46 PM, hauptmech wrote:
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
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
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#se
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 u
UI 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,
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 is
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
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 cod
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 i
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 t
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 expres
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
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
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
class
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
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/~ki
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 se
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
_
eally 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::BuildSheetLi
n 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.
Proba
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
hen 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::dispatchInt
n 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/~kica
quent 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 wrot
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 n
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 a
to do regarding my comment.
Greg S.
On Jun 30, 2017, at 6:24 PM, hauptmech 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.
e for only straight lines would facilitate the
speed other features and analysis.
Greg S.
On Jun 30, 2017, at 6:47 AM, hauptmech 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 var
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 a
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/
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 ++--
pcbn
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( wxSt
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/
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 m
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 different
1 - 100 of 152 matches
Mail list logo
