The same feature request how Chris suggested.
Отправлено с устройства Samsung.
Исходное сообщение От: Chris Pavlina
Дата: 18.11.17 3:44 (GMT+03:00) Кому: Seth Hillbrand
Копия: KiCad Developers
Тема: Re: [Kicad-developers] [FEATURE]
Eeschema Line Styles
Nice! I've wa
Le 17/11/2017 à 21:22, Seth Hillbrand a écrit :
> Yes, this is ready to commit. Thanks for taking the time to dig back for
> this one!
>
> Best-
> Seth
I committed your patch. Thanks.
--
Jean-Pierre CHARRAS
___
Mailing list: https://launchpad.net/
Nice! I've wanted this for ages, thank you so much!
Can I make a minor feature request? It'd be really nice if I could set
the color and style before placing lines, so I can place arbitrarily
many without having to change the style for each segment. Some editors
do this by adding a style dropd
Hi Miles,
On 11/17/2017 02:14 PM, miles mccoo wrote:
> I see. Let me summarize to see if I understand.
>
> The python wrapper around wx was rewritten. A move to SIP is one of (the
> main) differences that the new version brings with it. I imagine this
> involves more than a simple recompile. At l
Thank you very much Simon, it should ease the testing process. I have
already found out what is wrong with the dynamic update on Windows, but
I am still working on a solution.
Actually, if the installer was created today, the most likely it is a
version with dynamic updates working correctly on Wi
Thank you!
On 18 Nov 2017 00:47, "Wayne Stambaugh" wrote:
> Oliver,
>
> I took another look at your patch set and I see now that the library
> table files only change when there are disabled libraries. This will
> ensure that the footprint library tables will be compatible with
> previous versi
Hi,
On 14.11.2017 17:37, Maciej Sumiński wrote:
> 1. https://code.launchpad.net/~orsonmmz/kicad/+git/kicad/+ref/libedit
Also known as
http://downloads.kicad-pcb.org/windows/testing/patched/kicad-patched-18-10de79260-x86_64.exe
Simon
signature.asc
Description: OpenPGP digital signature
__
Yes, this is ready to commit. Thanks for taking the time to dig back for
this one!
Best-
Seth
On Fri, Nov 17, 2017 at 11:00 AM, jp charras wrote:
> Le 17/11/2017 à 17:36, Seth Hillbrand a écrit :
> > No, JP is right, that behavior should not occur in merging (it's a
> secondary step when drawi
Has CERN began work on that yet?
On Fri, Nov 17, 2017 at 02:26:01PM +, Wayne Stambaugh wrote:
> Hey Jon,
>
> There is currently a CERN work order for improving bus handing which
> would almost certainly clash with anything you are working on so you may
> want to hold off until that is impleme
Le 17/11/2017 à 17:36, Seth Hillbrand a écrit :
> No, JP is right, that behavior should not occur in merging (it's a secondary
> step when drawing).
>
> JP, I assumed that this patch was not of interest, but I still needed the
> functionality for junction
> management, so I merged it with a late
A better option might be to expose the PCB_FILE_T enum so that they can
be used directly by the python scripting. The other option is to use
pcbnew.IO_MGR_EnumFromStr( "Legacy" ) to fetch the enum. Of course if
there is no reason to ever save a board file in any other format than
the kicad sexpr
No, JP is right, that behavior should not occur in merging (it's a
secondary step when drawing).
JP, I assumed that this patch was not of interest, but I still needed the
functionality for junction management, so I merged it with a later patchset.
I've broken out the corrected patch for this func
Le 17/11/2017 à 13:42, Nick Østergaard a écrit :
> Isn't this the expected behavior?
>
> Usually you can sort of trim a wire by drawing from the end of it and into
> itself to remove that
> section.
>
No: this is a merge algo, used to cleanup wires, and must merge collinear
segments, not remo
Hey Jon,
There is currently a CERN work order for improving bus handing which
would almost certainly clash with anything you are working on so you may
want to hold off until that is implemented.
On 11/16/2017 09:24 PM, Jon Evans wrote:
> Hi Wayne, JP, and others with lots of Eeschema knowledge,
>
Oliver,
I took another look at your patch set and I see now that the library
table files only change when there are disabled libraries. This will
ensure that the footprint library tables will be compatible with
previous versions of KiCad as long as users don't disable any libraries.
I will merge
Isn't this the expected behavior?
Usually you can sort of trim a wire by drawing from the end of it and into
itself to remove that section.
2017-11-17 11:03 GMT+01:00 jp charras :
> Le 10/10/2017 à 07:19, Seth Hillbrand a écrit :
> > Sorry for the repeat on this one. I missed a corner case in t
Wayne,
Please confirm if you really do not want this feature now. This thread is
quickly turning into a how-to for the new symbol table :)
Thanks
On Thu, Nov 16, 2017 at 8:42 AM, Oliver Walters <
oliver.henry.walt...@gmail.com> wrote:
>
> On Thu, Nov 16, 2017 at 1:42 AM, Wayne Stambaugh
> wrot
Wayne,
Please ignore the previous patch sets. I have made further tweaks and the
attached patch set 0001 through 0008 should be considered canonical.
.
I have fixed a couple of pointer errors, and have also dropped the
filter-by-library functionality. It was a bit hooky and I'd rather submit a
sol
Le 10/10/2017 à 07:19, Seth Hillbrand a écrit :
> Sorry for the repeat on this one. I missed a corner case in testing the
> first time (overlapping,
> horizontal segments offset in Y)
>
> I've attached a collapsed patch for this.
>
> -Seth
>
Hi Seth,
I tested you patch and unfortunately it d
Le 17/11/2017 à 01:02, Seth Hillbrand a écrit :
> Hi Fabrizio-
>
> Good call. Attached is a patch to do this.
>
> Chris, I am unable to re-create your issue. Can you send along more
> information about your system?
>
> -Seth
>
> On Thu, Nov 16, 2017 at 10:41 AM, Fabrizio Tappero
On 17/11/2017 9:08 AM, miles mccoo wrote:
Another thing, there will be no more wxPython releases. The project has
been renamed to wxPython and AFAIR nobody has tried to use it with
KiCad. It may turn out that our SWIG work might be dropped/converted or
we will stay stuck with wx3
21 matches
Mail list logo