I agree with Carsten Here,
The same way the footprints are not part of the symbol, the same way
SPICE models should be defined separate.
I would rather have a new atomic file-format or storage format, so one
could actually send a complete part in an easy way, that would include
3D-Files, SPI
I like the idea of using something as Protobuf and I agree fully with
the benefits, especially since one can add/remove fields with minimal
impact.
Basically the S-expression system used now is looking very much like a
reinvented XML to me anyway, and storing protobuf-defined stuff as XML
or
On Fri, 2018-07-13 at 11:33 -0600, Jeff Young wrote:
> Hi Kristoffer,
>
> What platform are you on?
Ill just paste my entire build info :)
Application: kicad
Version: (5.0.0-rc3-dev-82-g0bf877f83), release build
Libraries:
wxWidgets 3.0.4
libcurl/7.60.0 OpenSSL/1.1.0h zlib/1.2.11 libidn2
Hey! Nice job!
I am not really sure what is the difference everywhere but i will give
my opinion on what i noticed :)
Good:
- Finally i can read the status text on the bottom thank you!
- The BOM plugin menu is much nicer
- Text and graphics view in pcbnew, very nice
Bad:
- Crashes
I agree with all of these points and I am very happy that there now is
a plan! There is one thing I would like clarified for this though.
Would It be okay to add the suggested template fields as a starting
point for users? Ofcourse without the "silent" adding to symbols and
netlists and boms.
On
Yes, the only way to make them translateable is to hard-code these and
other values into kicad, same as the existing hard-coded fields.
That would be a good solution for me, having similar to layers a large set
of predefined fields, being able to name them and enable them at will. But
storing them
ds to whatever would be decided. Uniformity
> for
> plugins use would definitely be an advantage.
>
> -Ben
>
> On Tue, May 22, 2018 at 5:38 AM kristoffer ödmark <
> kristofferodmar...@gmail.com> wrote:
>
> > Thanks! This is exactly what i was going for
> Do the BOM generators automatically output all default fields or only
> those with values?
>
> > On 22 May 2018, at 09:22, kristoffer ödmark > il.com> wrote:
> >
> > Please disregard my previous mail, it got mangled badly somehow, it
> > did
> >
now, and
we can never have that. Because we can not suggest a name, that would
be rude. I dont get the problem with a default config that hints at
what it might be called. I chose MPN in my example since it is used be
the Digikey library on github amongst other projects i found.
>
> Cheers
le more useful,
> > but
> > that'll take to long for v5 so if Kristoffer's patch allows an easy
> > way
> > to add fields to all components or similar, I'd say do it because
> > people
> > will be pissed and waste their time doing it for every compone
t; but that'll take to long for v5
so if Kristoffer's patch allows an >> easy way to add fields to all
components or similar, I'd say do it >> because people will be pissed
and waste their time doing it for >> every component in their schematic.
>> >> O
asy way to add fields
to all components or similar, I'd say do it because people will be pissed and
waste their time doing it for every component in their schematic.
On Sun, May 20, 2018 at 3:01 PM, kristoffer Ödmark
wrote:
I obvviously disagree, the correct solution would be to have both.
.
- Kristoffer
On 2018-05-20 23:40, José Ignacio wrote:
I dont like this, the right solution would be to allow for importing a
default config into kicad for things like that, as different groups
will have different policies.
On Sun, May 20, 2018 at 3:31 PM, Kristoffer Ödmark
mailto:kristofferodmar
at?
-S
Am So., 20. Mai 2018 um 13:00 Uhr schrieb kristoffer Ödmark <
kristofferodmar...@gmail.com>:
> Hello!
>
> I will open this can of worms again, I feel that I have to. So from what
> I gather we have proffessionals as the main aim in Kicad.
> The reason I will open this
Hello!
I will open this can of worms again, I feel that I have to. So from what
I gather we have proffessionals as the main aim in Kicad.
The reason I will open this issue again is that I feel we have a
collaboration issue, maybe not a mayor one. But one nonetheless.
We really need more defau
I think another stop gap measure is to have the ERC handle this, but
otherwise I am for Orsons patch.
Better a defined bad behavior than an undefined random behavior is my
opinion :)
On Fri, May 18, 2018, 16:53 Maciej Sumiński wrote:
> How about my patch? I do not dare to go for the ultimate so
Thank you JP!
I will have a look when I get home, It was not happening on linux, and I
do not currently have a windows computer anywhere, but maybe I can force
the cursor to the end some other way.
-Kristoffer
On 2018-04-09 16:21, jp charras wrote:
Le 08/04/2018 à 00:42, kristoffer Ödmark
I know its not the most elegant solution, but it is actually quite
convenient. Just checking so that this tiny improvement isnt lost :)
-Kristoffer
On 2018-04-08 00:42, kristoffer Ödmark wrote:
Agreed, hereis a patch for that :)
- Kristoffer
On 2018-04-06 17:18, Kevin Cozens wrote:
On
Agreed, hereis a patch for that :)
- Kristoffer
On 2018-04-06 17:18, Kevin Cozens wrote:
On 2018-04-06 06:30 AM, kristoffer Ödmark wrote:
Attached is a patch that adds support for custom environment paths.
Previously the wizard would only accept KISYSMOD, KIPRJMOD and the
github one.
I
include the env var to KIPRJMOD, I guess there is a reason?
On 2018-04-06 13:05, Jeff Young wrote:
Patch looks good to me, although I’d rather see the redundant code removed.
On 6 Apr 2018, at 11:30, kristoffer Ödmark wrote:
<0001-Footprint-Wizard-now-also-handles-custom-Env-paths.patch>
Found a bug shortly after, I will reupload. I will also remove the
redundant code and check if it still works.
On 2018-04-06 13:05, Jeff Young wrote:
Patch looks good to me, although I’d rather see the redundant code removed.
On 6 Apr 2018, at 11:30, kristoffer Ödmark wrote:
<0
charras wrote:
Le 04/04/2018 à 10:01, kristoffer Ödmark a écrit :
Hello!
So it was a while since I made some noise, so its time again.
Is there a way to create new footprint libs from KiCad? I cannot find it,
right now I create them by mkdir name.pretty, thento be able to add them
with the wizard, I
stoffer
On 2018-04-04 11:02, jp charras wrote:
Le 04/04/2018 à 10:01, kristoffer Ödmark a écrit :
Hello!
So it was a while since I made some noise, so its time again.
Is there a way to create new footprint libs from KiCad? I cannot find it,
right now I create them by mkdir name.pretty, thent
Hello!
So it was a while since I made some noise, so its time again.
Is there a way to create new footprint libs from KiCad? I cannot find it,
right now I create them by mkdir name.pretty, thento be able to add them
with the wizard, I have to create a temp.kicad_mod file in that folder.
Should
Congratulations! I am very glad to see this! I have been following the
mailing list for a while now and seen the great contributions and ideas
from you guys! Well deserved promotion!
-Kristoffer
On 2018-03-02 15:05, David Novak wrote:
Great job guys! Thanks for your investment in the project
visibility rules per class and not per layer,
so we can check additional conditions.
Regards,
Orson
On 02/08/2018 01:02 PM, kristoffer Ödmark wrote:
I started investigating this some more, there is much more rendering
problems here.
for example, disbling rendering of front footprints disables all
I started investigating this some more, there is much more rendering
problems here.
for example, disbling rendering of front footprints disables all the
F.Silk, F.Fab, adhesive and many more.
Disabling the rendering of Text on the front only disables text
belonging to a footprint, no other.
Attached is a minimal patch that differs the dialog title.
- Kristoffer
On 2018-02-05 13:25, Marco Ciampa wrote:
On Mon, Feb 05, 2018 at 01:10:08PM +0100, kristoffer Ödmark wrote:
Hey!
I just spent some time trying to "debug" a library non-issue with a EE
switching from Altium for
Hey!
Another confusion arised when I was speaking to a friend. When disabling
the F.Cu layer, the pads are still visible. I can understand the need to
be able to disable the pads on the front layer separate from everything
else, to check for things under pads etc.
What I cannot understand is
Yeah, that to adds to the confusion. I think maybe coherency should be
one of the main goal for v6.
On 2018-02-05 13:25, Marco Ciampa wrote:
On Mon, Feb 05, 2018 at 01:10:08PM +0100, kristoffer Ödmark wrote:
Hey!
I just spent some time trying to "debug" a library non-issue
Hey!
I just spent some time trying to "debug" a library non-issue with a EE
switching from Altium for a test. He had added the libraries correctly,
and they showed up. But everytime he tried adding a symbol to the
schematic, no symbols was there. We sent pictures back and forth, and
indeed th
It would be trivial if the "duplicate tool" either generated new unique
identifiers or left the unique identfier value empty.
I honestly dont understand why to have unique identifiers if they are
not unique, so maybe this should be a bug? I know they are referenced as
"timestamps" in the code,
Yeah, just downloaded it and gave it a whirl.
This project really shows some promise! The "pool" idea actually shows
some promise for library management.
I like how they want everything as parts. I will keep an eye on this.
Might be something to learn and integrate into kicad!
- Kristoffer
O
I do see the value of copy pasting between schematics. Its very common
for design reuse.
The way the copy-paste for pcbnew is done is like this:
Copy:
1. checks what items are selected.
2. check what requirements the selected items have( nets, layers etc)
3. this creates a new pcb file in memor
I just tried the patch, I cannot replicate this behaviour in linux at
least. Patch works as advertised for me at least.
Application: kicad
Version: (2018-01-16 revision 5571a76e5)-master, release build
Libraries:
wxWidgets 3.0.3
libcurl/7.57.0 OpenSSL/1.1.0g zlib/1.2.11 libidn2/2.0.4
li
For me it feels more natural with thins flowing from left to right, so
that means moving the import arrow to the left side, and also making it
flowing into the document.
Export also flow from left to right, so making it flowing from inside
the document to out on the right side. These are good
' physical size? Thanks.
On Wed, Jan 10, 2018 at 11:16:46PM +0000, kristoffer Ödmark wrote:
Tried the patch, didnt really notice anything different though, I guess you
need to add some custom scaling for this to take effect?
On 2018-01-10 22:23, Chris Pavlina wrote:
Sure, assign me to it. I shou
' physical size? Thanks.
On Wed, Jan 10, 2018 at 11:16:46PM +0000, kristoffer Ödmark wrote:
Tried the patch, didnt really notice anything different though, I guess you
need to add some custom scaling for this to take effect?
On 2018-01-10 22:23, Chris Pavlina wrote:
Sure, assign me to it. I shou
Tried the patch, didnt really notice anything different though, I guess
you need to add some custom scaling for this to take effect?
On 2018-01-10 22:23, Chris Pavlina wrote:
Sure, assign me to it. I should have time to work on it tonight or
tomorrow.
On Wed, Jan 10, 2018 at 04:20:21PM -0500,
lder in the repo with the patch, basically if
someone wants to create future icons. They could use the same
arrows for any kind of export, import, save, inspect or view.
I have created a set of "common icons" for exactly this purpose :)
On Thu, Jan 11, 2018 at 1:27 AM, Kristoffer Ö
Wow, really nice! Although, the icon for the bitmap2component basically
looks like a screenshot symbol to me, or something related to a webcam.
The old one isnt as polished, but I think it fits better.
Also, would it be too much to ask for getting the arrows, the diskette
and the folder in the
I think trying to replicate what this guy does here would be quite time
saving wouldnt it?
http://scottbezek.blogspot.se/2016/04/automated-kicad-schematic-export.html
Basically scripting keypresses, and then using something like scrot to
take a screenshot of the intended area. This would keep
27;:
kicad/common/geometry/shape_poly_set.cpp:489: undefined reference to
`ClipperLib::Clipper::Clipper(int)'
On 2018-01-09 19:22, Wayne Stambaugh wrote:
Does the patch resolve your issue?
On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:
Yes, I can reproduce this with very thick tracks!
O
I just about to try :) hang on, got some merge conflicts on some local stuff
On 2018-01-09 19:22, Wayne Stambaugh wrote:
Does the patch resolve your issue?
On 1/9/2018 1:21 PM, kristoffer Ödmark wrote:
Yes, I can reproduce this with very thick tracks!
On 2018-01-09 16:55, Jeff Young wrote
change the selection disambiguation is run *before* we know it’s a
drag action on a simple corner, so the selection_tool thinks it needs to know
which of the two segments is to be selected.
Cheers,
Jeff.
On 9 Jan 2018, at 15:37, Kristoffer Ödmark wrote:
If i understand him correctly that
stuck on the
Legacy/GAL stuff in the very beginning, not finding what was where.
-Kristoffer
On 01/09/2018 05:02 PM, Tomasz Wlostowski wrote:
On 09/01/18 16:21, Kristoffer Ödmark wrote:
Oh I was not planning on doing this, I am way to new to do a good job of
sorting the codebase. Just wanted to
If i understand him correctly that would only be when on a corner, I
think it would be the desired behaviour.
Although, when I try it on my build on my laptop, there is no clarify
selection menu popping up when trying do drag ( 'd' ) or such on
corners. Not in opengl anywas. So I dont know.
overview.
Anyway, I just wanted to see what anyone thought about it, if a renaming
was to happen, a good time for something like this might be around the
same time.
-Kristoffer
On 01/09/2018 04:08 PM, Wayne Stambaugh wrote:
On 1/9/2018 10:01 AM, Kristoffer Ödmark wrote:
Quite a bit of files under
Quite a bit of files under the root directory that could benefit from
some sorting as well :) Would be two patches then, one for renaming, and
one for sorting them somehow, both kinda large.
Maybe move classes to a folder called classes?
-Kristoffer
On 01/09/2018 02:59 AM, Wayne Stambaugh wr
the new
icons
>>> are really ambiguous and
>>> kind of useless. Shouldn't have been
merged.
>>>
>>>
>>> This is why I'm pushing for *a* change and not
*my*
>>&g
I was just expecting the net to be highlighted when i filed the report,
I have a memory of being able to do this on a previous nightly, nothing
else.
But after the comments, maybe I remember wrong? Jumping around in the
schematic when highlighting net is not something I want at least. I
rathe
For the record, I like these proposed ones. They
bring back the ability
to recognize them at a glance.
On Sat, Jan 06, 2018 at 05:52:49PM +, kristoffer
Ödmark wrote:
> I would love to see improved icons, I s
when doing this, the DRC doesnt warn if
there are vias that are buried are on the board, but not allowed in the
design rules.
I will file a bug report.
On 2018-01-06 21:51, Wayne Stambaugh wrote:
On 01/06/2018 02:46 PM, Tomasz Wlostowski wrote:
On 06/01/18 20:41, kristoffer Ödmark wrote:
The
:51, Wayne Stambaugh wrote:
On 01/06/2018 02:46 PM, Tomasz Wlostowski wrote:
On 06/01/18 20:41, kristoffer Ödmark wrote:
The menu for the vias have the via type choice disabled, I cannot change
the via type from through via to buried via. It is grey.
Sorry, it's not implemented yet...
Alright! I will have a look at it :)
On 2018-01-06 20:46, Tomasz Wlostowski wrote:
On 06/01/18 20:41, kristoffer Ödmark wrote:
The menu for the vias have the via type choice disabled, I cannot change
the via type from through via to buried via. It is grey.
Sorry, it's not implemente
e you setting the layers correctly for a
buried/blind via?
On 01/06/2018 01:03 PM, kristoffer Ödmark wrote:
Hello!
I just tested changin a via to a buried/blind via but I cannot get it to
work, Is this a bug or am I missing something?. I have enabled the
blind/buried via in the design
Hello!
I just tested changin a via to a buried/blind via but I cannot get it to
work, Is this a bug or am I missing something?. I have enabled the
blind/buried via in the design rules.
- Kristoffer
___
Mailing list: https://launchpad.net/~kicad-de
I would love to see improved icons, I still never get used to them so i
read the tooltip, newer know which one is pcb and which one is module
editor.
Luckily most of the time I only need to double click the kicad_pcb file
anyway :)
On 2018-01-06 15:08, Nick Østergaard wrote:
2018-01-06 14:1
ous
which options will be or were set by the setup dialog
Simon
On 1/01/2018, at 11:08 AM, Kristoffer Ödmark
mailto:kristofferodmar...@gmail.com>>
wrote:
There is still some functionality in it that is missing from what I
gather.
I do like the idea that just having an "enable hw
There is still some functionality in it that is missing from what I gather.
I do like the idea that just having an "enable hw acceleration" button
or switch in the nagdialog, it feels proffessional, and most people will
try it i think.
Also, these problems seems like there could be some benef
My personal preference would be to show the nag-dialog only if the user
has upgraded from a previous version of kicad, and only once.
New users wouldnt have to be informed, and if possible fallback a
fallback to the cairo solution instead of falling back to legacy might
be tempting.
Could ma
The power of defaults ;)
This is also something I have encountered has turned a lot of users
away, because when they try it, they dont really like the setup. So even
if they can change it, they give up before they realize they can.
-Kristoffer
On 12/30/2017 10:30 PM, Chris Pavlina wrote:
On
Honestly I am using the intel driver more often than the built in nvidia
in my ux302 zenbook. Mostly to get better battery time from it. I find
it very stable.
I have a friend who recently got a Xiaomi pro 15.6 inch laptop and runs
linux on it, it comes with both nvidia and intel drivers and a
On 2017-12-20 16:58, Jon Evans wrote:
For user experience, it might be a bit annoying to have to remember to
insert a separator character if you want one to appear.
So I guess one question would be: do we want to support no separator
character at all? Or default to a dot if the user doesn't e
/2017 02:29 PM, kristoffer Ödmark wrote:
Then dont use a underscore? If the dot is not inserted, nothing hinders
you from not putting a underscore there?
On 2017-12-20 13:32, Wayne Stambaugh wrote:
Using an underscore as a replacement for the period will add another
reserved character which will add
require quoting when saving to the file which makes the file format less
readable.
On 12/19/2017 4:52 PM, kristoffer Ödmark wrote:
Why would this be problematic for users like you to be able to chose
whichever character you fancy instead?
On 2017-12-19 22:03, Wayne Stambaugh wrote:
This would be
Why would this be problematic for users like you to be able to chose
whichever character you fancy instead?
On 2017-12-19 22:03, Wayne Stambaugh wrote:
This would be problematic for users like me who use the underscore
character in names for readability.
On 12/19/2017 3:57 PM, kristoffer
Another thing, maybe not force the usage of the dot ".", I would rather
like to force the dot myself, or be able to use "_" or whatever i fancy.
So instead putting CH0.{ADC}, or CH0_{ADC}.
- Kristoffer
On 2017-12-19 21:28, Jon Evans wrote:
Hi Marco,
Thanks a lot for your feedback.
I agree w
Personally I think this feature would be huge boost for readability.
Most people who will review a schematic knows what nets are on a USB
connection, or a SPI connection or similar. I see them as an
abbreviation, just the same as everyone knows what USB is, even though
it stands for Universal S
Hello!
I just went through the ML and the docs. I found some tests in the qa
folder that seemed related to the python scripting interface and some
different documentation regarding testability from tomasz and the thread
"simple C++ tests". Has there been added anything for doing tests in cpp
, so there is nothing preventing you from doing so. I would rather
not impose such constraint on aliases, but I am interested in other
opinions.
Regards,
Orson
On 12/14/2017 01:09 PM, kristoffer Ödmark wrote:
Maybe we could adapt from c++ here? having the notation instead
of {ALIAS}, the same way
Maybe we could adapt from c++ here? having the notation instead
of {ALIAS}, the same way c++ uses templates.
one could do MEMORY{ D[15..0]}. And get MEMORY.OE MEMORY.WE and
MEMORY D15 etc. Just to be more clear that it is an alias and not a
net-name.
- Kristoffer
On 2017-12-14 12:43, Clem
I think that this message is important, and I feel a decision on this
matter features has to be done by the project manager, basically give a
pointer to what should be used to as far extent as possible.
Wayne, this is a package dev that wants to know this and while I do not
know who are packag
spice option
(which apparently on arch linux it is not), setting KICAD_SPICE=ON will
fail during build config. It is up to the system package developer to
determine if kicad should be built with spice support.
On 12/6/2017 9:04 AM, Kristoffer Ödmark wrote:
Are we not in feature freeze, the features
I am still lacking a clear documentation about which options are inte
official releases, or planned to be.
On 2017-12-07 09:27, Maciej Sumiński wrote:
The attached patch lists options that have "KICAD" in their name when
calling CMake:
-- Build configuration:
-- KICAD_BIN=bin
-- KICAD
default build should reflect the ones being run by the less
savvy users.
-Kristoffer
On 12/06/2017 11:31 AM, Simon Richter wrote:
Hi,
On 06.12.2017 11:12, Kristoffer Ödmark wrote:
I do not see why anyone is even objecting to this? Where is the logic at
having a default build that does not
I sent the wrong patch before attached the correct now. Silently
compiling something else then what was expected is much much worse than
failing.
I do not see why anyone is even objecting to this? Where is the logic at
having a default build that does not correspond to any of the official
pac
e to see these options enabled by default.
It
makes it easier for a packager to be convinced what options to
enable...
:)
2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
mailto:kristofferodmar...@gmail.com>>:
I checked the default package in Ubuntu ppa through a friend.
Indeed
all
fault.
It
makes it easier for a packager to be convinced what options to
enable...
:)
2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
mailto:kristofferodmar...@gmail.com>>:
I checked the default package in Ubuntu ppa through a friend.
Indeed
all of this is enabled.
Here
ns to enable... :)
2017-12-05 15:05 GMT+01:00 Kristoffer Ödmark
mailto:kristofferodmar...@gmail.com>>:
I checked the default package in Ubuntu ppa through a friend. Indeed
all of this is enabled.
Here I attach a small patch that changes the default compile-flags
to the
for a novice
will look, maybe it will reduce some initial confusion for someone.
- Kristoffer
On 12/04/2017 10:19 PM, Nick Østergaard wrote:
Den 4. dec. 2017 18.50 skrev "kristoffer Ödmark"
mailto:kristofferodmar...@gmail.com>>:
On 2017-12-04 15:22, Tomasz
Hi!
On 2017-12-04 21:33, Maciej Suminski wrote:
As far as I remember the simulator is enabled in Windows nightlies since
October last year. Does not it work for you?
To be honest, I havent tested the windows version, I dont really run a
windows installation anywhere. I just falsely assumed If i
implement.
Steven
On 13/11/17 23:11, Kristoffer Ödmark wrote:
Hello!
I suspect this has been discussed before in different formats. But
anyway.
What would be the major problems or concerns with allowing a
schematic to have a pcb as file to include? What I mean is that the
same way we let a s
What are the roadblocks besides the huge amount of programming effort
required for this? Im on linux and I would like this as well.
- Kristoffer
On 2017-12-04 19:09, Bernhard Stegmaier wrote:
On 4. Dec 2017, at 18:55, Chris Pavlina wrote:
On Mon, Dec 04, 2017 at 05:53:12PM +, Tomasz Wlo
, kristoffer Ödmark wrote:
Okay, My suggestions:
1. Enable the spice simulator by default and start shipping it with
windows nightlies. This way we will find much more bugs. Because I doubt
everyone is running with the simulator on even on nightlies. Same goes
for the OCE and step stuff. This I see as
On 2017-12-04 15:22, Tomasz Wlostowski wrote:
Kristoffer,
You're very welcome to specify how you'd like to have the Spice-related
fields organized - but remember it's not only the integrated ngspice
simulator that relies on them. People have been exporting PSpice
netlists from Kicad for a whil
Hello!
What is the official status on the simulator part going towards v5? Will
it be included or not. I just tried it and I really like the features in
it, its basically ready to be used as a simulator and compete and
conquer ltspice.
What i do not like is the way it stores information, in
This is very interesting indeed! Would you keep us updated of your
progress? :D
- Kristoffer
On 11/29/2017 10:55 PM, Andreas Buhr wrote:
On 11/29/2017 08:07 PM, Tomasz Wlostowski wrote:
On 29/11/17 19:09, Andreas Buhr wrote:
[snip]
The input which my solver needs would be an array of poly
Heikki, That is not blackmailing, it is the exact same rules everyone
else that is a kicad developer or wants to be is expected to follow.
It makes working on the same project easier.
Tom did not mean to kick you out of the mailing list, he meant that your
code is not going to be put into Kicad
Could not a quick fix for this be to attach the "magnetic" functionality
that exists when routing to the endpoints of a Edge.Cuts line?
On 11/21/2017 04:00 PM, Thomas Pointhuber wrote:
Hi,
as librarian I would also note that an improved Edge:Cuts behaviour
should take in account footprints whi
Hello!
I suspect this has been discussed before in different formats. But anyway.
What would be the major problems or concerns with allowing a schematic
to have a pcb as file to include? What I mean is that the same way we
let a symbol have a footprint in eeschema, we let a schematic point to
Oliver Walters
> wrote:
>>
>> I like 2) or 3) - I think that a major release is a good time to fix such
>> a bug.
>>
>> Would you like me to add a patch implementing one of these options JP?
>>
>> On 9 Nov 2017 23:33, "Kristoffer Ödmark"
&g
Personally I think this is a nice solution
http://1.bp.blogspot.com/-3u-eixTrMbI/VDWb25kPNkI/A-g/0qn7ehRq4Mo/s1600/ReadOnly.PNG
Very helpful, instead of the "Edit document" button, there could be
something such as "Copy to user-library for edit".
- Kristoffer
On 11/09/2017 02:02 AM,
Currently the footprints arent compatible anyway i guess, they support
more than 4.07 footprints do. So option 2 is my preferred solution.
On 11/09/2017 12:51 PM, jp charras wrote:
Le 09/11/2017 à 11:12, Kristoffer Ödmark a écrit :
My 2 cents is that the headaches of storing values in mixed
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
mailto:kristofferodmar...@gmail.com>>:
I think for this to start happen, a decision
My 2 cents is that the headaches of storing values in mixed units,
without indication of which unit they are stored as is a huge drawback
for readability of the saved files and for maintainability.
Also I think the proposed new tag offset is a good idea, since the
libraries can be gradually up
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 o
To be fair, as it stands now, even if it is "only" for the pin headers,
this is close to half of the 3d library size as of now.
The pin headers can now be of an arbitrary size as well. Someone can now
create a 4x6 pin header for example, and the current footprints can be
converted to this arra
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 t
How does the documentation work now? Do we have any standardisation on
how to document?
On 11/01/2017 09:53 AM, Maciej Sumiński wrote:
On 11/01/2017 09:40 AM, Carsten Schoenert wrote:
Hello Wayne,
Am 31.10.2017 um 13:06 schrieb Wayne Stambaugh:
We are very close to a feature freeze and creat
1 - 100 of 244 matches
Mail list logo
