Re: [Kicad-developers] Symbol library table merged.

Wayne, That's great news, and a welcome addition. Regarding the decision to include all the libraries by default - is this a sensible solution? No project requires all libraries to be added, and some of the libraries are particularly large. Is it really that difficult for new users to understand

Re: [Kicad-developers] Update of KiCad documentation?

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.

[Kicad-developers] Symbol library table merged.

I finally got the symbol library table changes merged into the development branch of KiCad so be prepared for some pretty significant changes in the way symbol libraries are handled both from a user and a developer perspective. Also be prepared for a massive amount of complaining about the

Re: [Kicad-developers] when to release kicad-5.0

Thank you for the offer. I have to look and see what needs to be done to give you access privileges to the timeline and milestones. I don't know when I have time to do that. We should probably agree on how we are going to use them if at all before we do anything and then nobody follows suite.

Re: [Kicad-developers] [PATCH 00/12] Minor cleanups and improvements

Hi Marvin, On 11/09/2017 08:12 PM, Marvin Schmidt wrote: > Hey Orson, > > I actually didn't skip any patch, #8 ("Remove orphaned code files") > should is there: > https://lists.launchpad.net/kicad-developers/msg31304.html Strange, I have never received this message, but now I am glad that I

Re: [Kicad-developers] [PATCH 0/3] Minor fixes for VECTOR2 and BOX2

Hi Marvin, IIRC, I could not apply some of the patches cleanly, but I decided they were short enough to introduce the changes manually. Apparently even with such short patches there is a place for mistakes, I am sorry about that. Regards, Orson On 11/09/2017 08:07 PM, Marvin Schmidt wrote: >

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

Oliver, historically that was in inches for the 3D viewer... Mario didn't change the file format to avoid breaking any previous releases I think, but managed to calculate correctly offset and displaying in the 3D viewer and exporter... I don't know if aligning these parameters to mm inside

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

Maurice, The error is that the offset is stored (file format) in inches but it should be mm. Now that I know that the issue is in the file, I'm happy that the internals to KiCad were working well, it just didn't make sense for the assumption that units were in mm On 10 Nov 2017 08:39, "easyw"

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

JP, I think that 3) is the better option, because it preservers PCB file compatibility (as long as the offset is zero). Any time the PCB is saved, the (at (xyz 0 0 0)) gets written. You are also correct that none of the official library footprints have a defined offset. This is why i have never

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

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" wrote: > Currently the footprints arent compatible anyway i guess, they

Re: [Kicad-developers] [PATCH 0/3] Minor fixes for VECTOR2 and BOX2

Hey Orson, thanks for pushing those patches! Just wondering: why did you alter them? I intentionally left one of the `#include ` in place because the Rotate function uses sin and cos (which should really be std::{sin,cos} by the way) and ordered the includes alphabetically Best regards, Marvin

Re: [Kicad-developers] Update of KiCad documentation?

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

Re: [Kicad-developers] Update of KiCad documentation?

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

Re: [Kicad-developers] when to release kicad-5.0

There is no need. We already use the series thing. And one can specify milestones to a series. But I don't have the required access rights to edit this. I would be happy to help manage this. Den 9. nov. 2017 16.03 <20%2017%2016%2003> skrev "Wayne Stambaugh" < stambau...@gmail.com>: > Hey Nick, >

Re: [Kicad-developers] [REQUEST] Default library install location

Den 9. nov. 2017 16.09 skrev "Simon Richter" : Hi, On 08.11.2017 08:02, Oliver Walters wrote: > For v5 release, can the default library install path be set to a user > directory rather than program directory that may require administrator > rights? On Windows, there

Re: [Kicad-developers] when to release kicad-5.0

Hey Nick, The last time I looked, milestones could still not be linked to git repos, only bzr repos. This is problematic since we have switched to git. This may have changed recently. I haven't looked. Even if they could be linked to git repos, I'm not sure how much extra work it would be

Re: [Kicad-developers] [REQUEST] Default library install location

Hi, On 08.11.2017 08:02, Oliver Walters wrote: > For v5 release, can the default library install path be set to a user > directory rather than program directory that may require administrator > rights? On Windows, there is a provision in the MSI standard for installing software for the user

Re: [Kicad-developers] [PATCH] fix MANDATORY_FIELDS comparisons

Julius, I cannot git am this patch. Apparently, the extra info added by launchpad is causing an issue. Please resend this patch as an attachment so I can get it merged. Thanks, Wayne On 11/7/2017 4:31 AM, Julius Schmidt wrote: > I found a few places where SCH_FIELD::GetId() is incorrectly

Re: [Kicad-developers] [PATCH] wxWidgets macOS 10.13 Patch

Adam, I pushed your patch to the master branch. I'll keep an eye out for the build doc update patch. Thanks, Wayne On 11/6/2017 9:25 PM, Adam Wolf wrote: > Hi folks, > > Attached is a patch that adds a patch that helps wxWidgets build on > the latest macOS 10.13 High Sierra. > >

Re: [Kicad-developers] when to release kicad-5.0

Hi Wayne It is hard to get any overview on how far from a branchout to a stable v5 release. I propose that we start using the milestones on launchpad. Then we can relate bugs to this and have an easier overview on what we would like to get done before releasing v5. What do you think? Nick

Re: [Kicad-developers] [REQUEST] Default library install location

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,

Re: [Kicad-developers] Update of KiCad documentation?

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.

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

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

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

Le 09/11/2017 à 11:12, Kristoffer Ödmark a écrit : > 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

Re: [Kicad-developers] Update of KiCad documentation?

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.

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

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

Re: [Kicad-developers] Update of KiCad documentation?

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

Re: [Kicad-developers] Update of KiCad documentation?

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

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

> - It appears that the internal units for 3D model offset (mm) were being > multiplied by 25.4 incorrectly In case (as discussed on this email thread) there are no changes in the file format, it would be good just to left a comment in the sourcecode about this issue, so future coders will not

Re: [Kicad-developers] [PATCH] Fix for 3D model offset

In my opinion we should not be afraid to bump that version on master when we already have done it since the branch was branched last time. If this was a fix on a stable branch it would be of a greater concern, but should probably just be noted in the release notes and everything should be honky

Re: [Kicad-developers] [REQUEST] Default library install location

On Thu, November 9, 2017 00:12, easyw wrote: >> I think it's a far more risky that a user makes accidental changes to >> the bundled library. Simple users should not need to touch it, and >> should rather copy or make a new part. > > so if a user wants to add a missing parts to his/her library