Re: [Kicad-developers] Kicad's way of drawing filled zones
Am 2019-05-19 19:27, schrieb Seth Hillbrand: Am 2019-05-19 15:28, schrieb jp charras: It also could be worth to commit the work on Removing segment hard-coding, because zone filled polygons optimization also include circle to segments optimization. I think the consensus was to make the acceptable error size configurable and store it in the kicad_pcb file. I am updating my branch to do this and will e-mail the list for some testing before pushing. Hopefully this week. Hi All- I've pushed the latest code for customizing the approximation level to my branch [1]. Please have a go at testing it. It includes the modification to the kicad_pcb file, removing the legacy segments_per_zone and adding a board-level max_error setting. You can set this value in the Board Setup/Design Rules dialog. I clamp it between 0.1 and 0.001mm. If there are no objections to the approach this week, I'll push it to master this weekend. -Seth [1] https://code.launchpad.net/~sethh/kicad/+git/kicad/+ref/segments ___ 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
[Kicad-developers] 5.1.3 stable release
We are getting a decent set of bug fixes in the 5.1 branch so we should seriously start thinking about a 5.1.3 stable release by the end of June. What I would like to see is push to fix some of the outstanding 5.1 bugs[1] and then do a string freeze in the middle of June. If you see a bug that is code that you are familiar with, please consider fixing it. There will be plenty of time to work on v6. Thanks again everyone for your continued efforts. Cheers, Wayne [1]: https://launchpad.net/kicad/+milestone/5.1.3 ___ 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
Re: [Kicad-developers] Patch set: Display Origin Transforms
Wayne, Thanks for the feedback. Re the header guards: It's common in my experience to define include/exclude type symbols with a non-zero numeric value. This avoids problems when someone writes "#if SYMBOL" rather than the intended "#ifdef SYMBOL", as a preprocessor symbol with no value evaluates to zero in this context. The majority, though certainly not all, of the include files in /usr/include follow this convention for this very reason. I'll get you a patch to address the "const" parameters and your other comments as soon as I get a chance. A patch for "Move Exactly" and Bezier will follow in a few days. -Reece From: "Wayne Stambaugh" To: "KiCad Developers" Sent: Tuesday, May 21, 2019 10:21:10 AM Subject: Re: [Kicad-developers] Patch set: Display Origin Transforms Hey Reece, I tested your patch set and everything seems to work as advertised. I have a few minor comments: The ORIGIN_TRANSFORMS references should be passed as const in all places where they are used internally by another object that doesn't modify them. It's not necessary to add '1' to the header compile guards. AFAIK, none of the other header files do this. I'm fine if these fixes are implemented in a separate patch. I'm fine with merging this patch set as long as there are no objections. I answered some of your questions in-line below. On 5/19/19 10:13 PM, Reece R. Pollack wrote: > I've attached a Zip file containing 11 patches. These implement the > Origin Transforms feature I've been talking about since KiCon. They > should apply cleanly to the master branch at this commit (currently HEAD): > > 9d56102 Prevent unannotated components from driving connectivity > > In summary, this adds Pcbnew user preferences that allow the user to > select the origin from which absolute coordinates are displayed and > entered. The supported origins are the Page Origin, the Auxiliary > Origin, and the Grid Origin. If the user preference has not been set the > default is Page Origin, which looks just like what we have now. > > Additionally, two other Pcbnew user preferences are added to allow the > user to select which way the X and Y axes increase: Left or Right for > the X axis, and Up or Down for the Y axis. If the user preference has > not been set the default is X Right and Y Down, which again looks just > like what we have now. > > I added a new panel to the Pcbnew "Preferences" dialog called "Origins & > Axes" to allow the user to change these options. I did not add any > toolbar icons as I expect these will be "set and forget" options for > most users. > > These patches do not alter the content of the board file, nor do they > change the internal representation of coordinates. The user can change > preferences without causing revision-managed data churn. The only affect > is how the user sees and enters coordinate values. > > My intent has been to implement these transforms only in Pcbnew, but the > changes to common data structures necessarily affect all KiCad > applications. Thus support for display origin and axis shifts is latent > in the Footprint Editor, GerbView, Eeschema, and the Symbol Editor, and > can be implemented with minimal effort. However, at this point there > should be no user-visible changes in any of these applications. > > Some notes: > > 1. The new file "origin_transform.cpp" is currently in common/widgets/ > because that's where unit_binder.cpp was located. It might ought to > be in common/ instead. Should be in common. It's not really a widget object. > 2. I believe I've addressed all user-visible Pcbnew displays and dialog > boxes other than the Move Exactly dialog. If I missed something > else, let me know. > 3. I haven't decided how the "Move Exactly" dialog should work yet; I > think it needs axis orientation support but not origin translation. > I'd be happy to get feedback before I code a patch for this. It probably should be implemented in the move exactly dialog for absolution positions. > 4. I did not touch the Bezier coordinates because it appears this is > not fully implemented in Pcbnew and I couldn't figure out how I > would test such changes. I thought we did go live with this recently so Bezier coordinates will need to be supported unless this was only in the footprint editor. > 5. I'm willing to make a pass through the code to unify the name of the > Auxiliary Origin once there is a consensus on what to call it. By auxiliary origin, I'm assuming you mean the place and drill origin in pcbnew. If so, the latter is more descriptive. Auxiliary origin is not very descriptive. > 6. Patching the file containing the list of developers to add my name > felt kinda presumptuous. I'd be happy if these patches constitutes > cause to do so. I will do that once your patches are merged. > 7. Would someone send Jeff Young on holiday for a week or two? I'm > getting burned out just trying to keep these patches
Re: [Kicad-developers] Launchpad bug tracker guidelines
On 21/05/2019 22:27, Nick Østergaard wrote: I think we should add notes in the kicad dev docs (some md file in the doxygen docs) along the lines of This email is not intended to be a discussion, just a +1 thing if you like it and feedback on where we should document this. +1. Consistent use of the bug tracker is really important, and I know I don't always use it correctly. I have some questions and suggestions, but I'd rather we got this document in first, describing the current status quo. Then we can iterate. So please indicate on the way forward. Should we add it to the dev docs or the website? I think dev docs and link from the website/launchpad. Cheers, John ___ 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
Re: [Kicad-developers] Via stitching
On 20/05/2019 23:48, Frank Severinsen wrote:
When using clang-format on the entire file, it more or less changed
every line in one way or another.
should this be committed as well or is git clutter worse than
codingstyle issues?
You should not commit unrelated formatting clutter in the same commit as
actual code changes. Just format the changed bits. If that's too
inconsistent, either reformat as a separate commit, or match the
existing style in the area, even if it's "wrong".
The trick here is to use git-clang-format. This will only format the
lines you have changed. There are instructions in the developer
documentation[1], a git-hook to report errors when you commit, and a
script to help you fix it.
@Wayne: I have a patch here for the formatting document to add some
aliases to make it easier. It finally dawned on me that we already
distribute aliases for the 'fixes' alias, so let's do it for the
formatting too!
[1]:
http://docs.kicad-pcb.org/doxygen/md_Documentation_development_coding-style-policy.html
>From fb053d8cc27179542320bc3b297087aa28fd440a Mon Sep 17 00:00:00 2001
From: John Beard
Date: Wed, 22 May 2019 10:26:20 +0100
Subject: [PATCH] Format: add some formatting aliases, improve dev docs
The aliases are easier than calling check_coding.sh manually,
and we already provide an alias file for the fixes alias, so
do the same for these.
---
.../development/coding-style-policy.md| 34 +--
helpers/git/format_alias | 10 ++
tools/check_coding.sh | 2 +-
3 files changed, 34 insertions(+), 12 deletions(-)
create mode 100644 helpers/git/format_alias
diff --git a/Documentation/development/coding-style-policy.md b/Documentation/development/coding-style-policy.md
index 420c9041c..46514c536 100644
--- a/Documentation/development/coding-style-policy.md
+++ b/Documentation/development/coding-style-policy.md
@@ -76,25 +76,37 @@ to "true" for the KiCad repo:
git config kicad.check-format true
Without this config, the format checker will not run on commit, but you can
-still check files staged for commit manually:
-
-tools/check_coding.sh --diff
+still check files staged for commit manually (see below).
If the hook is enabled, when you commit a change, you will be told if you
-have caused any style violations (only in your changed code). You can fix your
-staged changes automatically with this tool:
-
-tools/check_coding.sh
+have caused any style violations (only in your changed code). You can then fix
+the errors, either manually, or with the tools below.
-Or you can proceed anyway, if you are sure your style is correct:
+If you are warned about formatting errors, but you are sure your style is correct,
+you can still commit:
git commit --no-verify
-The `check_coding.sh` tool has other modes:
+### Correcting Formatting Errors ## {#correcting-formatting-errors}
-* Make (or see only) changes to files modified in the previous commit:
-* `check_coding.sh --amend [--diff]`
+There is a Git aliases file that provides the right commands to show and correct
+formatting errors. Add to your repository config by running this command from
+the source directory:
+
+git config --add include.path $(pwd)/helpers/git/format_alias
+Then you can use the following aliases:
+
+* `git check-format`: show any formatting warnings (but make no changes)
+* `git fix-format`: correct formatting (you will need to `git add` afterwards)
+
+These aliases use a script, `tools/check-coding.sh`, which takes care of only
+checking the formatting for files that should be formatted. This script has
+other uses:
+
+* Make (or see only) violations in files modified in the previous commit (useful
+when interactive-rebasing):
+* `check_coding.sh --amend [--diff]`
# 2. Naming Conventions # {#naming_conventions}
Before delving into anything as esoteric as indentation and formatting,
diff --git a/helpers/git/format_alias b/helpers/git/format_alias
new file mode 100644
index 0..bac8c5b9a
--- /dev/null
+++ b/helpers/git/format_alias
@@ -0,0 +1,10 @@
+[alias]
+ # Alias to check the formatting since the last commit and show the issues
+ # that are found. No files will be changed. Only lines changed since the
+ # last commit are considered (and only for files that should be reformatted)
+ check-format = "! f() { tools/check_coding.sh --diff; }; f"
+
+ # Alias to check and fix formatting issues in files changed since the last
+ # commit. Only lines changed since the last commit are considered (and only
+ # for files that should be reformatted)
+ fix-format = "! f() { tools/check_coding.sh; }; f"
diff --git a/tools/check_coding.sh b/tools/check_coding.sh
index c5f730dfb..2e6c967f9 100755
--- a/tools/check_coding.sh
+++ b/tools/check_coding.sh
@@ -30,7 +30,7 @@ usage='usage: check_coding.sh [] [--]
--diff Only show proposed changes, do not format files
- --cached
Re: [Kicad-developers] PATCH: exact match of component with sub-units in schematic did not show
Hi Wayne, On 21/05/2019 18:26, Wayne Stambaugh wrote: John, If this is not acceptable, would an option that allows the user to turn this feature on or off be an acceptable solution. In some use cases, I can see the value of the this patch. I'm not saying it's unacceptable, I'm just not sure the attached "expanded" behaviour is what you want to see (by default), because you get so few results on a page (if the symbols in the results have many subunits, it could be only one). It's certainly a judgment call. What would you like to see here? If John, is OK with a user option, would you be OK with making this behavior user configurable? If configuration *is* wanted, something like a checkbox somewhere in that dialog for "expand subunits" would probably be a good place, so it can be changed quickly as needed. But if it's a checkbox "in the clear" in the dialog (as opposed to in a context menu or otherwise hidden), it's a space-function trade-off. Cheers, John ___ 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
