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,
Hi Oliver,
>
>
> I think we need to fit this in with the existing PCBNew Attributes stuff
> (“attr” in the file format). We currently have through-hole, SMD and
> virtual (the later being similar to DNF/DNP), but a lot of folks have found
> that too limiting for various reasons. I suspect this
Hey John,
On 11/23/2018 8:26 AM, John Beard wrote:
> Hi,
>
> This is a patch to refactor the zooming of WX_VIEW_CONTROL. This is
> related to lp:1786515 [1], but it's not a fix, it's just a refactor to
> help debug the problem, and also tidy the code.
>
> The refactor is done to avoid big
On 11/25/2018 2:15 PM, jp charras wrote:
> Le 25/11/2018 à 20:06, Seth Hillbrand a écrit :
>> Am 2018-11-25 14:01, schrieb Wayne Stambaugh:
>>> I plan on tagging 5.0.2 tomorrow unless is a show stopper bug that I am
>>> not aware of. My goal is to give the library, doc, and translations a
>>>
On 11/25/2018 2:40 PM, Carsten Schoenert wrote:
> Hi,
>
> Am 25.11.18 um 20:01 schrieb Wayne Stambaugh:
>> I plan on tagging 5.0.2 tomorrow unless is a show stopper bug that I am
>> not aware of. My goal is to give the library, doc, and translations a
>> week to get tagged for 5.0.2 and another
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
Hi,
Am 25.11.18 um 20:01 schrieb Wayne Stambaugh:
> I plan on tagging 5.0.2 tomorrow unless is a show stopper bug that I am
> not aware of. My goal is to give the library, doc, and translations a
> week to get tagged for 5.0.2 and another week for the installers to get
> built so I can make the
Le 25/11/2018 à 20:06, Seth Hillbrand a écrit :
> Am 2018-11-25 14:01, schrieb Wayne Stambaugh:
>> I plan on tagging 5.0.2 tomorrow unless is a show stopper bug that I am
>> not aware of. My goal is to give the library, doc, and translations a
>> week to get tagged for 5.0.2 and another week for
Just a reminder, we already have a properties token for key/value pairs.
Key/value pairs are provided for use by third party tools and are not
used internally. All internal functionality must be implement as valid
file tokens. Also keep in mind that one of the goals of kicad file
formats is to
Am 2018-11-25 14:01, schrieb Wayne Stambaugh:
I plan on tagging 5.0.2 tomorrow unless is a show stopper bug that I am
not aware of. My goal is to give the library, doc, and translations a
week to get tagged for 5.0.2 and another week for the installers to get
built so I can make the release
I plan on tagging 5.0.2 tomorrow unless is a show stopper bug that I am
not aware of. My goal is to give the library, doc, and translations a
week to get tagged for 5.0.2 and another week for the installers to get
built so I can make the release announcement on 12/9. Please let me
know if this
su 25. marrask. 2018 klo 20.25 Jeff Young (j...@rokeby.ie) kirjoitti:
>
>
> I think we need to fit this in with the existing PCBNew Attributes stuff
> (“attr” in the file format). We currently have through-hole, SMD and
> virtual (the later being similar to DNF/DNP)
>
I have always found
Along these lines, we should probably figure out what attributes/properties
KiCad should store as rigidly-defined fields/data members rather than a
more flexible (key/value) system.
>From what I can tell, some of the commercial EDA software I have used
treats almost everything as an "attribute"
Hi Oliver,
I think we need to fit this in with the existing PCBNew Attributes stuff
(“attr” in the file format). We currently have through-hole, SMD and virtual
(the later being similar to DNF/DNP), but a lot of folks have found that too
limiting for various reasons. I suspect this means we
I've often seen "NC" used to mean "no connect" which usually is the "X"
symbol you put on pins to prevent ERC warnings.
DNP is also the one I've seen the most. I actually have heard from a
(US-based) assembly vendor that DNP is the most common, DNI is next after
that, and all other options are
>In the files I have used "DNF" or "fitted" - what should the accepted
nomenclature be here? I've seen DNF / DNP / NC and other examples used. I'd
like to get some clarity on what I should use going forward.
By far I've always seen DNP in mass usage. "Do not populate". I've seen
"NC" less often
Frank,
That's a good idea,I hadn't thought of that. I'll add it to my working
document.
Cheers,
On Sun, 25 Nov 2018, 20:00 Hi Oliver
>
> This looks very nice! A plot option to disable DNF components in paste
> layer would be nice
>
>
> 25. nov. 2018 05.38 skrev Oliver Walters :
>
> A feature I
Hi OliverThis looks very nice! A plot option to disable DNF components in paste layer would be nice 25. nov. 2018 05.38 skrev Oliver Walters :A feature I feel has been missing from KiCad is the ability to mark parts as "DNF" (Do Not Fit) so they are excluded from assembly files (BoM / PnP /
su 25. marrask. 2018 klo 6.38 Oliver Walters (oliver.henry.walt...@gmail.com)
kirjoitti:
>
>
>- (Eventually) ability to switch between assembly variants in PCBNEW
>
>
We regularly need several independent variants in the same board. For
example two different regulators for different kinds of
19 matches
Mail list logo
