Re: [Kicad-developers] What does "when in doubt do it opposite than certain other pcb tool" stand for?
On 2019-11-26 09:05, Tomasz Wlostowski wrote: On 22/11/2019 17:42, Rene Pöschl wrote: I would assume this is referencing version 6 of eagle. The current versions of eagle are actually something that can (in some aspects) be used as a good example. I would therefore assume that this sentence is simply out of date and could be removed or at least reworded. I don't have access to that webpage, but whoever has, feel free to remove it. Tom ___ 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 Which website are we talking about? I followed Rene's link but it just went to the Doxygen site and I don't see that statement there. -S Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Plugin/3rd party content manager
On 2019-11-25 17:46, Andrew Lutsenko wrote: Hi Seth, Yes, I planned to write up my design in google doc and open it to comments. I think that works best for public discussion, even though it requires having a google account. Design I'm thinking about requires 0 custom backend work. It will rely entirely on publicly available infra such as github/gitlab hosting and ci/cd pipelines. Admittedly that imposes some limitations on what we can do (and I will outline them in my doc) but we can always add custom backend system later to complement free infra. Assuming design is accepted I am interested in doing at least a minimally functional implementation. I have a lot of ideas but some of them will have to be implemented later because it's not a trivial task. Ok, I'll start working on it and will hopefully share the doc by end of this week. Andrew Hi Andrew- We need to start with the API definition and file format changes. The API definition should include end points and returns. The file format changes should include the files and specific configuration lines needed. Please do not go down the road of an entirely public infrastructure manager. We can include an option for additional servers that return the API calls, but this needs to be centralized to fit into the KiCad roadmap. Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Who controls gitlab.com/kicad?
On 2019-11-25 13:28, Seth Hillbrand wrote: > On 11/25/19 1:01 PM, Michael Geselbracht wrote: > >> That's me. Someone from Gitlab just contacted me. I totally missed this >> mailing. >> >> I have replied that I was not aware that my private group names may affect >> other users and that I am willing to rename the group. >> >> Is it sufficient to just rename the group name? Or will this only change the >> displayed group name and leave the internal name as it is? >> >> - Michael Thanks to Michael, the KiCad instance is now reachable at https://www.gitlab.com/kicad . Many Thanks! We'll continue testing the migration there and publish a timeline for transition. Please feel free to open any issues at https://gitlab.com/kicad/kicad_migration In the meantime, please log in to GitLab and ensure you have the same e-mail account between GitHub and GitLab as this will assist with user mapping. Otherwise all of the issues. will get mapped to the KiCad-Bot. Best- Seth KiCad Services Corporation Seth Hillbrand LEAD DEVELOPER +1-530-302-5483 [1] Davis, CA www.kipro-pcb.com [2]i...@kipro-pcb.com https://twitter.com/KiProEDA [3] https://www.linkedin.com/company/kicad [4] Links: -- [1] tel:+12126039372 [2] http://www.kipro-pcb.com/ [3] https://twitter.com/KiProEDA [4] https://www.linkedin.com/company/kicad___ 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] Plugin/3rd party content manager
On 11/25/19 3:21 PM, Andrew Lutsenko wrote: Hi all, Is anyone currently working on some sort of plugin manager or 3rd party library manager? https://bugs.launchpad.net/kicad/+bug/1823733 I have some ideas that I want to write down in a form of high level design document and share with the group for discussion. If there is already some work done in that direction I'd like to avoid duplication of efforts. Regards, Andrew ___ 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 Hi Andrew- There are a few ongoing discussions about what needs to be included and the backend server design needed in addition to how the software would interact with the data. I'd be interested to see the design document you come up with. If you are interested in doing the full implementation, it would be good to see your thoughts in the design document. If you do write this up, please include it in a format/locate that allows for content-level suggestions such as Google Documents or markdown document on GitLab/GitHub. Thanks! -Seth -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] Who controls gitlab.com/kicad?
On 11/25/19 1:01 PM, Michael Geselbracht wrote: That's me. Someone from Gitlab just contacted me. I totally missed this mailing. I have replied that I was not aware that my private group names may affect other users and that I am willing to rename the group. Is it sufficient to just rename the group name? Or will this only change the displayed group name and leave the internal name as it is? - Michael Hi Michael- You definite win the first-mover advantage here! Thank you for responding. Yes, I was working with GitLab to find out if you would be willing to help by adjusting the name. I don't think renaming does it, so let's see what the GitLab support folks say about it. I'll ping you off-line to work out the details. Best- Seth -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] GitLab migration
On 2019-11-25 06:08, Wayne Stambaugh wrote: Hi Mark, Do you mean using a GPG key? I see the gitlab supports signed commits so would that be an adequate solution? I'm fine with this, it's probably something we should be doing anyway. Anyone else object to this? 2FA would be using something like Google Authenticator on your phone, a YubiKey or SMS message code to verify your login on a computer in addition to the password. The worry is that SSH keys can be added to a compromised account that would allow an attacker to change the code/website/packages/etc. -S Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Librarians, Doc Devs and Code Devs
Hi All- This is a friendly request for you (yes, you!) to create a user account at GitLab. This can either be signing in with your existing GitHub account over OAuth or creating a new account with the same e-mail as your public GitHub email address. We're not moving over to GitLab yet, but the import process leaves a lot of dangling issue reports and PRs if the user e-mail does not exist in the GitLab system at the time the import is first run. Thanks and we're looking forward to seeing everyone at GitLab. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] GitLab migration
On 2019-11-24 13:13, Mark Roszko wrote: Can the use of 2FA be mandated across the entire group since we have a fresh start? It's been killing me that it's not required for GitHub and it really is a vulnerability to not enforce. KiCad is a decent value target for malicious code placement since it is a desktop app. https://docs.gitlab.com/ee/security/two_factor_authentication.html#enforcing-2fa-for-all-users-in-a-group Hi Mark- Can you open an issue for this in the transition repository[1]? It makes sense to me but it would be good to track that in the transition in case other issues arise from it. Best- Seth [1] https://gitlab.com/kicad_pcb/kicad_migration Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Using OPT types
On 2019-11-24 09:09, Wayne Stambaugh wrote: I also dislike auto, except in the case of stl::’s overly-verbose iterators. Again, they make the code harder to read more often than not. I'm seriously rethinking typedefs as well. I can never seem to remember the type they represent so I have to dig around the source to figure out the actual type. I'm thinking just typing out the full type is easier in the shortened typedefed version which was most likely only created to save some typing. I generally like both of these. But part of that is because my IDE (VS Code and sometimes Eclipse) shows me the underlying type when I mouse hover over the auto variable. Same thing with type aliases. If I needed to dig for them or remember, I would definitely come down in the other camp. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Who controls gitlab.com/kicad?
Hi All-
As you have heard, we are moving from Launchpad to GitLab. However, we
have been unable to secure the https://www.gitlab.com/kicad group name
for the project. The name appears to already be taken. However, this
is not a public group or user, so we don't know who controls the name.
Does anyone on the list control the "kicad" name at GitLab? In the
interim, we've registered https://www.gitlab.com/kicad_pcb but it would
be much better if we could use the shorter name.
Thanks-
Seth
KiCad Services Corporation
Seth Hillbrand
LEAD DEVELOPER
+1-530-302-5483 [1]
Davis, CA
www.kipro-pcb.com [2]i...@kipro-pcb.com
https://twitter.com/KiProEDA [3]
https://www.linkedin.com/company/kicad [4]
Links:
--
[1] tel:+12126039372
[2] http://www.kipro-pcb.com/
[3] https://twitter.com/KiProEDA
[4] https://www.linkedin.com/company/kicad___
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] Selection appearance options
On 11/21/19 8:01 AM, Jonatan Liljedahl wrote: Hi, Here comes two patches regarding the selection appearance. Patch #1: Adds three new options in the settings dialog: - Draw selected text items as box Instead of drawing a stroked shadow behind the text, a rounded rectangle is drawn according to the text boundary box. - Draw selected child items When disabled, only the main selected item is drawn with the selection shadow, not the various fields and pin names etc. Default is enabled (current behaviour) - Fill selected shapes Any selected shapes has their selection shadow filled, instead of just drawing along the lines. See attached screenshots for a demonstration of some various combinations of these settings. Patch #2: Tweaks the amount of zoom-level impact on the selection shadow thickness, to get a more coherent look while zooming. You need to try this in action to know if it's good (I think it is). Cheers ___ 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 Hi Jonatan- Thanks for this patch. I'll give this a test run this weekend. I know that the Mac display of highlight was always a bit different than Linux, so it would be good if one of our Mac devs also tested for issues. Best- Seth -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] eeschema selection appearance
On 11/20/19 7:11 AM, Jonatan Liljedahl wrote: Ok, I'll look into making it configurable. However, I find the current default appearance hard to use, so maybe one could consider changing the defaults in that case? Everyone likes to have their preferences as the default. This is not a useful line of discussion for the project. Once the options are configurable, it shouldn't be an issue. Additionally, I changed the shadow width algo constants as follows, to avoid the feeling of the selection shadow changing size drastically as you zoom: Please move this idea into a separate patch and propose it. The selection highlight width works well at all zoom levels for me but if this idea helps some people without negatively impacting the current situation, there should be no issues. Please keep this distinct from the options patch, however. So now the question is at what granularity all this should be configurable? Perhaps: - selection draw child-items: bool - selection thickness: float - selection color (already there) Those options make sense to me. -Seth -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] eeschema selection appearance
On 2019-11-20 05:48, Jonatan Liljedahl wrote: Hi, I'm tweaking the appearance of the new selection, what do you think? Except a change of color, transparency and width, it also skips drawing the fields and pin labels of components. I think it gives a much cleaner look with less clutter. This will always be a matter of opinion. Right now the color is configurable. If you'd like to add additional configurable parameters to the selection, you should place them in the Eeschema preferences and allow the user to choose them. Then post the patch for review. Otherwise, we'll end up bike shedding on this which would be nice to avoid. Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] OCE vs OCC
On 2019-11-16 11:03, Steven A. Falco wrote: On 11/16/19 1:14 PM, Seth Hillbrand wrote: On 2019-11-16 08:42, Steven A. Falco wrote: It looks like Fedora may be switching from OCE to OCC, so I'm doing a trial build with OCC. How would folks recommend testing the build? I'm not sure what would be necessary. Also, I have a question about CMakeLists.txt. Around line 91, it says: option( KICAD_USE_OCC "Build tools and plugins related to OpenCascade Technology (overrides KICAD_USE_OCE, default OFF)" OFF ) Note the comment that says KICAD_USE_OCC will override KICAD_USE_OCE. Thus, one would think that just setting KICAD_USE_OCC=ON would be sufficient to automatically set KICAD_USE_OCE=OFF Also, the code at line 472 makes it look like setting KICAD_USE_OCC=ON would set KICAD_USE_OCE=OFF. However, in my build, that didn't work, and I had to explicitly set KICAD_USE_OCE=OFF. Steve Thanks Steve! I'm very happy to hear that Fedora is switching. I pushed a fix for the issue you've identified. Thanks Seth - that was fast! I confirm that the fix is good. I can now build with just setting KICAD_USE_OCC=ON. I tried opening a 3-d view of a board, and it loaded correctly. Is that a sufficient test for OCC or is there more that I should try? Steve 3d view will check that we import models correctly. I would suggest the additional tests: - Exporting the demo boards to STEP files. - Importing a mix of STEP and IGES models into a board - Be sure to check exports of boards with cut out holes in the middle - Check boards with arcs on the edge.cuts - Check boards with circles on the edge.cuts -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] OCE vs OCC
On 2019-11-16 08:42, Steven A. Falco wrote: It looks like Fedora may be switching from OCE to OCC, so I'm doing a trial build with OCC. How would folks recommend testing the build? I'm not sure what would be necessary. Also, I have a question about CMakeLists.txt. Around line 91, it says: option( KICAD_USE_OCC "Build tools and plugins related to OpenCascade Technology (overrides KICAD_USE_OCE, default OFF)" OFF ) Note the comment that says KICAD_USE_OCC will override KICAD_USE_OCE. Thus, one would think that just setting KICAD_USE_OCC=ON would be sufficient to automatically set KICAD_USE_OCE=OFF Also, the code at line 472 makes it look like setting KICAD_USE_OCC=ON would set KICAD_USE_OCE=OFF. However, in my build, that didn't work, and I had to explicitly set KICAD_USE_OCE=OFF. Steve Thanks Steve! I'm very happy to hear that Fedora is switching. I pushed a fix for the issue you've identified. Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Pcbnew drill sizes statistics & Project manager multiple selection options
On 2019-11-15 16:54, Mikołaj Wielgus wrote:
- Project manager multiple selection options:
It appears that implementing these enchancements would require
significant changes to the project manager code, since much of the
actions is implemented in TREEPROJECT_ITEM class itself, hence a
significant portion of the actions implementation would have to be
placed somewhere else (most likely to TREE_PROJECT_FRAME class). In
addition, KICAD_MANAGER_CONTROL::Execute would have to be modified to
allow passing several arguments.
Since I'm not very experienced with the codebase yet, and these issues
are minor, and implementing them can potentially cause a lot of issues,
I would like to request pulling the patch as it currently is for the
time being. This will make it easier for me to implement these features
later (in the next patch).
Best regards,
Mikołaj Wielgus
Hi Mikołaj-
Thank you for the patches submitted already. We have an unwritten
policy to not commit code that represents partial features or that we
know will result in bug reports. Because of this, I don't think it is
wise to commit a patch that will prompt for each file being deleted.
There does need to be a single dialog for all files.
JP's second comment about all files being opened in existing editors I
think may not be feasible for the default PDF browser because
wxLaunchDefaultApplication() only takes a single filename. I'll leave
to JP whether he thinks we should adjust this for the other files.
If JP thinks this this should be implemented for the other calls, you
would pass a const std::vector& reference instead of just the
filename. For calls to the same function that are meant to only take a
single filename, you would adjust the call to construct the vector but
enclosing it in braces { filename }.
If you run into issues while developing this, you can push your branch
to a public repository (GitHub, GitLab or Launchpad) and request some
help. These services are useful for starting development as they allow
inline commenting on the code review.
Best-
Seth
Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372
___
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] New border/title blocks?
On 2019-11-13 15:54, Evan Shultz wrote:
> The contributor submitted ISO templates and the librarians have access to
> those standards, thus the review and merge could proceed.
Fair enough
> None of the librarians have access to the ASME standards and thus we could
> not properly review and vet them even if they were contributed. Should ASME
> templates be contributed that can be reviewed, they would be welcomed.
OK, I can handle the ASME template submission. If you run into
standards in the future that the librarians don't have access to, feel
free to ping the dev list. We have a fair cross section of engineers
who can help with reviews although we don't always follow the PRs at
GitHub.
-Seth
KiCad Services Corporation
Seth Hillbrand
LEAD DEVELOPER
+1-530-302-5483 [1]
Davis, CA
www.kipro-pcb.com [2]i...@kipro-pcb.com
https://twitter.com/KiProEDA [3]
https://www.linkedin.com/company/kicad [4]
Links:
--
[1] tel:+12126039372
[2] http://www.kipro-pcb.com/
[3] https://twitter.com/KiProEDA
[4] https://www.linkedin.com/company/kicad___
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] [Discussion] PCB Calculator: Resistor calculator
On 11/13/19 9:54 AM, Dmitry Rezvanov wrote: Hello, everyone. Now I'm working on the resistor/capacitor/inductor calculator. In the attachment - very preliminary version of the design. Upper block - for calculating result from two known values. Lower block - vice versa, for finding the configuration and values of two components for target value. Please, don't hit me too hard, I did this while crossing the Ballmer Peak. I really hope for feedback and opinion. P.S. And sorry for my bad English. English isn't my native language, so I swear, I try to work on it every day. Hi Dmitry- This looks like a good start. I'd prefer if we did not bother with the "Calculate" section. This is light calculation that shouldn't need extra space and maintenance. The Synthesize section is very useful especially if you are planning on giving tolerances in the potential outputs based on the various resistor/capacitor series. The box spacing is not even between your three columns. RCL, Calculate and Formula are at different heights. I'm not sure that we need two windows for the output. I'd remove the "Result" window and put the results in the window on the right. In the synthesis, I think you just want a single input resistance value as the target value. Then, you should have the option for 2x/3x/4x resistors in the calculation result. Thanks for taking this on and I look forward to seeing the code result. Best- Seth -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] New border/title blocks?
On 11/13/19 10:36 AM, Evan Shultz wrote: Thanks Seth! I didn't find the default template when looking at the code base, but I'm sure it's there and I just didn't find it. So if things are left alone hopefully the packager people will automatically include them? Then hopefully this message thread will make the packagers aware of new templates. I could add more wishlist items, but you mentioned some key ones. I believe it would be best to create a launchpad bug for this so it can be tracked and doesn't get buried in the mailing list. The small and large title blocks are both useful, as is having or not having revision history, so that means at least four templates. But because the ISO spec defines variations based on page size, for example the number of subdivisions of the border sides, I do not believe it would be possible to auto-scale and collapse the number of templates while still strictly meeting the ISO standard. The ISO standard only defines A page sizes. I understand your comment about providing US page sizes but they aren't part of the standard. That is a choice that was made for which standards to combine in this set of templates. ISO 7200 is used in combination with ASME Y14.1 frequently for GD in the US. The fact that this PR only made allowances for ISO 7200/ISO 217 is an oversight in the review process that prevents a section of our userbase from being able to use KiCad's features. We don't exclude either European or US users in the codebase. It would be a good idea not to do so in the templates as well. -S -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] New border/title blocks?
On 11/13/19 9:19 AM, Evan Shultz wrote: Seth, Yes, these templates are sized specifically for certain page sizes as defined in the ISO specification. And also for particular sheet orientations. So in Eeschema, the user needs to select the page size and orientation that match the template in order for the scaling to be proper and the template to be rendered such that it meets the ISO specification. Even if manual work is required to properly use these tempates, perhaps it might be useful to still include them? In addition, during the review of the templates we discovered limitations such as what you mentioned above. I can understand if the best solution for now is only a stopgap, and I'm happy to submit a feature request for an enhancement for this area of Eeschema, with the details to be sorted out later as to not derail the main objective of this message. Thank you! The process for inclusion would be managed by the individual distributions. I assume that they pull from the kicad-templates repository by default. Currently, the extra templates are installed at the same directory level as the default template. This is cluttered and mixes all different kinds of templates together. We should definitely address this. Simple subdirectories for page layout options other than the default should be considered in the templates CMake The wishlist items for the code I see are: - Adding the Revisions block as an optional item in the layout format - Adding support for graphical items referenced to page center With these two items, we should be able to collapse these templates into a single, standard (or two if you wanted the basic 180mm and an alternate compressed version for the Title block. For the templates, if we are adding templates per size, it would be good to add standard A/B/C sizes as well. US KiCad users do not have easy access to either A4 paper or (harder) A4 printers. Best- Seth -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] New border/title blocks?
On 11/13/19 8:30 AM, Evan Shultz wrote: There have been very nice border and title blocks following industry-standard guidelines merged into the official KiCad library at https://github.com/KiCad/kicad-templates/pull/25. They now reside at https://github.com/KiCad/kicad-templates/tree/master/Worksheets. Is there a path to get these worksheets added into KiCad so they appear along with the other options in the 'Size' pulldown menu in the Page Settings dialog in Eeschema? I'm not very familiar with the KiCad codebase, but I didn't see where the borders/title blocks are located. If it's helpful and relatively easy, I'd be delighted to get a few pointers and then prepare a patch to include them. Thank you! ___ 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 Hi Evan- These do look interesting for some purposes. The size pulldowns perform some automatic adjustments, they don't select new files. It looks like this commit makes a number of new templates that only work for some sizings. Is that correct? -S -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] Tab handling in text rendering and bbox calculation
On 2019-11-12 03:57, Johannes Sprigode wrote: Howdy guys, hate to burst your bubble. The tab/space issue appears consistent, however the actual character alignment kind of sucks. Lower case a, b etc. are only part of the equation. The big guys still seem to have some sway. Screen shot attached. Cheers The characters are not monospaced. So, you shouldn't expect the line of characters to align with the tab characters. The tab character is meant to align with other tabs. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Tab handling in text rendering and bbox calculation
On 2019-11-11 17:48, Andrew Lutsenko wrote: > Hi Seth, Jeff, > I see you have touched this code recently. I've noticed that tabs are handled > differently for bbox calculation resulting in slightly oversized bbox. > > When rendering tabs we count them as whatever width is needed to align to > multiple of 4 and +1 additional space but when calculating bbox it is align > to 4 spaces + '?' width, which is a bit wider. > > I attached a patch that fixes this particular issue to count tab as align to > 4 spaces + 1 space. > But I think this is confusing in general, why do we still render another > space after aligning width to multiple of 4? > Here is a picture of left-justified text in pcbnew. First line is "ab", > second "<4 spaces>b", third "<5 spaces>b". > > Regards, > Andrew Good catch. I hadn't noticed that. The intention (in the comments) was to align to the 4th column. I pushed a fix as well as yours to the code. Thank you for your contribution to KiCad! Best- Seth KiCad Services Corporation Seth Hillbrand LEAD DEVELOPER +1-530-302-5483 [1] Davis, CA www.kipro-pcb.com [2]i...@kipro-pcb.com https://twitter.com/KiProEDA [3] https://www.linkedin.com/company/kicad [4] Links: -- [1] tel:+12126039372 [2] http://www.kipro-pcb.com/ [3] https://twitter.com/KiProEDA [4] https://www.linkedin.com/company/kicad___ 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] Project save as
On 2019-11-11 11:42, Jeff Young wrote: A... I didn't notice that. We are indeed failing to look for the Protel extensions. Are we renaming generated files? If we stick with base project files, it's easy to explain where the cut-off is. Once we go down into generated files, this gets harder and harder especially as we start implementing more exports (IPC-2581, D-365, XY files, etc) where we don't control the extensions. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] GitLab migration
On 2019-11-10 08:43, Seth Hillbrand wrote: > On 2019-11-10 08:33, Eeli Kaikkonen wrote: > >> OK. Would it be worth re-importing everything even for this test database to >> avoid false impressions? >> >> Eeli Kaikkonen > > What false impression? Is there a report that is listed as being created by > different people in launchpad vs. GitLab? Oops. Disregard. I see a broken report here: https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7367 Looks like the Launchpad API doesn't handle users who have since deleted their accounts nicely and the script is falling back on Fabien's account, probably because his is index 0. -S KiCad Services Corporation Seth Hillbrand LEAD DEVELOPER +1-530-302-5483 [1] Davis, CA www.kipro-pcb.com [2]i...@kipro-pcb.com https://twitter.com/KiProEDA [3] https://www.linkedin.com/company/kicad [4] Links: -- [1] tel:+12126039372 [2] http://www.kipro-pcb.com/ [3] https://twitter.com/KiProEDA [4] https://www.linkedin.com/company/kicad___ 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] GitLab migration
On 2019-11-10 08:33, Eeli Kaikkonen wrote:
> OK. Would it be worth re-importing everything even for this test database to
> avoid false impressions?
>
> Eeli Kaikkonen
What false impression? Is there a report that is listed as being
created by different people in launchpad vs. GitLab?
KiCad Services Corporation
Seth Hillbrand
LEAD DEVELOPER
+1-530-302-5483 [1]
Davis, CA
www.kipro-pcb.com [2]i...@kipro-pcb.com
https://twitter.com/KiProEDA [3]
https://www.linkedin.com/company/kicad [4]
Links:
--
[1] tel:+12126039372
[2] http://www.kipro-pcb.com/
[3] https://twitter.com/KiProEDA
[4] https://www.linkedin.com/company/kicad___
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] GitLab migration
On 2019-11-10 08:17, Eeli Kaikkonen wrote: > Who is this original reporter "Fabien Corona (drinasaur)" who created all the > reports? > > Eeli Kaikkonen Not all of the reports. Just a bunch of the recent ones prior to this import. Here is one you created [1]. Click on the "Original Report" to see the reporter information in launchpad. -Seth KiCad Services Corporation Seth Hillbrand LEAD DEVELOPER +1-530-302-5483 [2] Davis, CA www.kipro-pcb.com [3]i...@kipro-pcb.com https://twitter.com/KiProEDA [4] https://www.linkedin.com/company/kicad [5] Links: -- [1] https://gitlab.com/orsonmmz/kicad-bug-tracker/issues/7100 [2] tel:+12126039372 [3] http://www.kipro-pcb.com/ [4] https://twitter.com/KiProEDA [5] https://www.linkedin.com/company/kicad___ 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] GitLab migration
On 2019-11-09 14:08, Maciej Suminski wrote: I have fixed all issues, taking into account the ones reported on the mailing list and Ian's 'Gitlab Issue Tracker Guidelines' [1]. In my opinion, the bug tracker is ready to be moved to Gitlab. You can check out the latest bug tracker migration in my test project [2]. Cheers, Orson 1. https://docs.google.com/document/d/1GRFO6tIfecpg8tDjIJW8qHxv7cvp13t2GAgQf2zN254/edit?usp=sharing 2. https://gitlab.com/orsonmmz/kicad-bug-tracker/issues Orson, this is fantastic. Thanks for working through all of this. I can't overstate how much better this feels. Images inline, great search options. I have a marked todo list with highlighted issues in the toolbar. No more digging through three layers of clicks and options to find the search features. Amazing. Hopefully we can up with a timeline to move work over to the new system. I didn't see any stoppers with the current setup. I suppose that our next step is to mirror the repository to GitLab under the KiCad account. Did we ever resolve who controls the "KiCad" username on GitLab? Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] LOCALE_IO thread-local
On 2019-11-08 03:49, jp charras wrote: Le 21/06/2019 à 23:25, Seth Hillbrand a écrit : Hi Devs- We currently have an RAII locale switch (LOCALE_IO) that swaps the global locale to allow floating point handling with decimal points instead of a commas. Because it changes the global locale, we need to be very careful about allowing the user interface to update during the time that it is temporarily set. The attached patch moves the locale setting into a thread-local setting, allowing us to use standard threading and UI updates. There are no functionality changes in this patch. This is merely a change in the calling structure that will allow future cleaning of the LOCALE_IO distribution in the code. I'd greatly appreciate any windows testing. Thanks- Seth Hi Seth, What is the status of this change? Hi JP- Looks like that one resides in one of my 10k side branches. :) I had been testing out a few different approaches here. This one (after moving the std::atomic to thread local as well) or using internal conversions with std::imbue/std::num_put/std::num_get. I also considered using wxWidgets' built-in handlers but tying more closely to this library outside of UI is not a great idea. I also considered specialized internal functions copied from ruby or python but don't like the idea of carrying around chunks of untouchable code. Incidentally, C++17 will include std::to_chars/std::from_chars, which always converts in 'C' locale. This seems like the best option for the project long-term. But, of course, we are not yet C++17 and won't be for a few years. For now, I'm speed-testing the num_get routines internally. The basic istringstream is a no-go for performance as loading gets noticeably slower. num_put/num_get seem to work correctly and be approximately equivalent speed, so I hope to send around a patch showing them and removing LOCALE_IO completely. Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] New lead developer announcement
On 11/7/19 12:14 PM, Wayne Stambaugh wrote: I am happy to announce that the KiCad project now has a new member of the lead development team. Ian McInerney has accepted an invitation to become a member of the lead development team. Ian's contributions have earned him this privilege and we are grateful for his efforts. Please join me in congratulating Ian and welcoming in his new role. Cheers, Wayne ___ 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 Congratulations, Ian! And welcome! I'm really looking forward to working with you. Best- Seth -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] Symbol library code changes
On 2019-11-06 12:34, Wayne Stambaugh wrote: I finally finish up the initial attempt at simple inheritance for the symbol library code. The change is non-trivial and will likely have some unexpected side affects that I missed. I pushed the branch to my personal repo[1] and I would like a few pair of extra eyes on it before I merge it into master. If you prefer, I can set up a merge request from this branch in Launchpad. The biggest user facing change is that the concept of aliases is gone which means internally, the LIB_ALIAS object has been removed and all of the information it managed was moved into LIB_PART. This actually simplified some of the UI code but made the LIB_MANAGER and LIB_PART object code more complicated. The symbol library editor works significantly different now. When you select a derived part (formerly a LIB_ALIAS), it will show the parent symbol that it was derived from darkened and all of the edit features disabled. Until the new symbol file format is done and writing to the legacy symbol file format is deprecated, this restriction will have to remain in place. The properties editor no longer has an aliases panel and is limited to what it can change in the derived or parent symbols depending on which symbol is currently being edited. I suspect this will be the biggest stumbling block for existing users so if you can think of a better way to handle this, I'm open to suggestion. The other thing that I am concerned about is symbol library editing. There were a lot of LIB_MANAGER object changes which I am not 100% confident in. Just a couple of other internal changes to be aware of: A flattened copy of the symbol is used in SCH_COMPONENT instead of relying on the weak reference to the library symbol. This way we don't have to worry about the shared pointer disappearing and causing issues. However, this will require that we be diligent about updating modified symbol libraries in the schematic. Otherwise, the schematic could change the next time it is loaded. I'm open to changing this back if we think it's going to be an issue. There is now a compare function for the LIB_PART object which can be rather tricky. I created a new test suite inside the current LIB_PART test file so if you change anything, please run the test to ensure nothing gets broken. I also added a bunch of other new tests for the LIB_PART object. I added code to DIALOG_SHIM to allow the caller to reset the last dialog size when hiding dialog control state changes between dialog instances. We have some dialog windows that are not the correct default size depending on which controls are shown so there is now a convenient way to address this. Please let me know if you find anything so I can get it fixed and merged into master. The next step is to convert the schematic internal units from 1mil to 10nm. Once that step is complete, I will knock out the new symbol library format. Thanks in advance for the help. Cheers, Wayne [1]:https://code.launchpad.net/~stambaughw/kicad/+git/kicad-dev/+ref/lib-alias-merge Hi Wayne- I'm psyched to see this progress! Congrats. I'll have a chance to fully test after next week but I wanted to get you the code read feedback before then. 1) Compare function: - It looks like rhs isn't checked for end() in the loop. While size gets checked ahead of time, we've had a couple cases where code gets added between checks and loops in the past, so it's probably safer to put the check in the loop. - Same with the footprint check. Ideally, these would be the same style (iterators vs. dereference) but that's minor - Do we expect these containers to remain sorted? 2) You have a few C-style casts in Flatten() 3) The LIB_PART() copy constructor should take a const reference rather than the existing one, that should remove the requirement of using const_cast in Flatten() 4) That ternary in GetNextDrawItem() is breaking my brain a bit. 5) In footprint_info.h, if we are returning the wxString itself (instead of the reference), it shouldn't be const. (addendum: Also loadAliases()) 6) sch_view.cpp has a couple c-style casts that can probably be compressed into our dyn_cast routine. 7) DeleteSymbol mixes up it and it1 in the while() loop. I can't wait to test it out! On the usability issue for aliases, I suspect that this is a time limited constraint, so there shouldn't be large issues as people should not be building aliased libraries with the master branch at this point. We may want to clarify that in a list message. Overall, I am very excited for the new formats. Thanks again for taking on this huge job! Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More
Re: [Kicad-developers] Benchmarking kicad compilation on CPUs released 6 years apart
On 11/5/19 9:59 AM, Simon Richter wrote: Hi, I've made another quick run for Release builds: MakeNinja Scripting ON5:19.66 5:03.91 3336% 3565% Scripting OFF 3:33.84 3:08.50 4947% 5684% That is with -j64 on 2 socket T2P9D01. You can see that dependency generation makes about 15 seconds difference (the CMake generator for Makefiles has that as a separate step, while the generator for Ninja knows how to output dependency information during the first build). Wow. I have nowhere near your horsepower but still run a 12-core system and don't see anywhere near this discrepancy.Must be in the extended parallelism. For me, Make Ninja Scripting ON 8:04.92 7:25.43 1043% 1127% Scripting OFF 7:33.23 7:15.09 1090% 1129% That is to say, scripting adds about 10-30 seconds on a full build. Do you see a difference between running '-j64' and '-j ' on the POWER9? -S -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] Learn to Code KiCad at FOSDEM 2020
Hi Folks- Are you looking to write code that improves KiCad? On Friday, Jan 31 (the day before FOSDEM), we'll be hosting a Learn to Code KiCad session in Brussels, BE. I will be there as will Wayne and possibly a few other of the lead development team. We'll help you understand how the various KiCad components fit together and work with you to get your favorite feature from idea to committed code. What you need: 1) An identified bug report (or multiple) that you'd like to address. This can be either a legitimate bug or a wishlist feature that is triaged in our system. 2) A laptop with your development environment 3) A launchpad account 4) A compiling version of KiCad 5) A working knowledge of C++ coding What we'll provide: 1) Space, power outlet, wifi 2) Coffee 3) A short introduction to the structure of KiCad and how the parts work together 4) Up to 8 hours of development time with others who share your interests 5) Clarifying insights to your KiCad coding questions At the end of the day, you should be able to get at least 1 and possibly multiple bug report fixes under your belt and into the code base! If you're coming to FOSDEM 2020 and would like to participate, please e-mail me directly (off-list to preserve people's inboxes). Send me your name/contact info and the list of 1 or more launchpad bugs you'd like to work on during the day. I'll add you to our shared sheet (to deconflict bugs people are addressing) and get you all of the relevant information for the meeting. Best- Seth -- KiCad Services Corporation KiCad Services Corporation Logo Seth Hillbrand *Lead Developer* +1-530-302-5483 Davis, CA www.kipro-pcb.com <https://www.kipro-pcb.com/> i...@kipro-pcb.com <mailto:i...@kipro-pcb.com> https://twitter.com/KiProEDA <https://twitter.com/KiProEDA> https://www.linkedin.com/company/kicad <https://www.linkedin.com/company/kicad> ___ 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] Who did the save-to-board icon?
On 2019-11-03 08:25, Jeff Young wrote: I'd like to update the load-from-board and add-to-board icons (last two below) to match. Thanks, Jeff. ___ 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 Hi Jeff- I was working through the icon licensing a while back and have script that may help. Here's the history of those two icons. That said, it doesn't catch re-names, so JP will have to mention whether he generated the original or not. Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372___ 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] eeschema: Allow hierarchy navigator to stay open
On 2019-11-03 04:28, Franck Jullien wrote: Le jeu. 24 oct. 2019 à 19:29, a écrit : ping Hi Franck- Sorry for the slow response time here. Can you please attach the results of `git format-patch` as an attachment to the e-mail? This will help us to review, comment and apply the patch. Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Benchmarking kicad compilation on CPUs released 6 years apart
On 2019-10-30 08:20, Simon Richter wrote: That is more than 1100% CPU usage, with -j12, so very close to full usage. How is that even possible, don't you have that two minute phase at the end of building pcbnew_kiface where it's just building pcbnew_wrap.cxx.o and everything else is done? Simon Two things can help there. First, using the gold linker (if you are not already) and second, using Ninja. The gold linker is substantially faster than the BFD linker. And Ninja is smarter than make about parallelizing actions. Cmake will happily generate the Ninja files for you with -GNinja. Here are the results for my testing with all scripting enabled (Debian Buster) seth@cpu1 (master) % time ninja 4050.50s user 291.35s system 1137% cpu 6:21.85 total Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Python files still depending on Python2 only due used shebang
On 2019-10-26 10:06, Simon Richter wrote: Hi Wayne, On 26.10.19 19:00, Wayne Stambaugh wrote: None the less, there is currently no wxPhoenix/Python3 support for windows. TBH, I wouldn't like to be dependent on MSVC on Windows -- the compiler is great as an additional source of diagnostics, and some people might like the smaller runtime, but in the end we want to be 100% free software. Simon I also don't like the idea of introducing MSVC-only code. But at the moment, the pthreads implementation of C++ async code is 1-2 orders of magnitude slower under windows than Linux. We have a number of open bugs that directly point back to this. Using MSVC translates the async calls to native threads. If we have an option to improve the user experience while keep our code open and standards-compliant, I hope we'll consider it. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Implement auto annotation on component/symbol placement.
On 2019-10-25 17:57, Zficani Zficani wrote: > Hi, > I'm sorry for the delay but I finally got everything sorted out. I formatted > the code and fixed a few bugs I found. > Regarding `git format-patch`, I used it originally but my commits contain > many TODOs and temporary code so I was told to just squash everything > together and send in a single patch. I will send both this time and let you > see which one you actually want to use. I tried my best to clean up my commit > history but it's still not really perfect. > > Thank you. Hi Zficani- I've been trying out your new patch and it mostly works. The only issue I've seen so far is that duplicating subsheets doesn't seem to annotate all of the duplicated items contained inside. Let me know if you need an example project to test this on. Best- Seth KiCad Services Corporation Seth Hillbrand LEAD DEVELOPER +1-530-302-5483 [1] Davis, CA www.kipro-pcb.com [2]i...@kipro-pcb.com https://twitter.com/KiProEDA [3] https://www.linkedin.com/company/kicad [4] Links: -- [1] tel:+12126039372 [2] http://www.kipro-pcb.com/ [3] https://twitter.com/KiProEDA [4] https://www.linkedin.com/company/kicad___ 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] Python files still depending on Python2 only due used shebang
On 2019-10-26 06:53, Wayne Stambaugh wrote: I'm guessing that fixing the shebangs will not be enough because there is python2 specific code in the script files. I've added [1] so that we make sure to get to it before v6 is released. What is the timeline for the new stable Debian/Fedora? Do we need to accelerate this for 5.1.6? -Seth [1] https://bugs.launchpad.net/kicad/+bug/1849961 Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] SPICE .option confused with .op simulation
On 2019-10-22 23:35, Maciej Suminski wrote: Hi Sylwester, I admit I have not checked your patch in action, but it seems that it will not accept ".op" command, unless it is followed by a space. Since ".op" does not take any parameters, I presume it is a rare case when one adds an extra space after the command. Regards, Orson Thanks Orson! You are right, it was skipping the unpadded .op. I missed this as the .tran command does print the DC operating point and I was checking in a multi-command circuit. Good catch. I've fixed up the command parsing to ensure we pad the command lines. This does bring up, however, that our simulator does not handle .op well. It won't probe the values or print them easily. LTSpice prints the DC Operating Point table for all nets after running in this mode. Not that LTSpice is the model of usability but there may be something to this. -Seth ___ 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] Minimum Boost version
On 2019-10-22 16:06, Ian McInerney wrote: > I dug into the website history and apparently the original intent should have > been to support 16.04 LTS until its standard support ends in 2021 > (https://github.com/KiCad/kicad-website/commit/007fb582a316fa513778a393e2696d17c0031cea#r33487782). > Since we haven't actually used any code from the newer Boost version (that > we weren't already using), we should probably back out the change and also > update the website with the correct Ubuntu LTS support date. It looks like > that will make it so we can't update to 1.59 until 2021 then. Hi Ian- I did write that. In retrospect, I'm not sure that the sentiment is correct. One of the things we are attempting to do is focus our primary efforts where they will have the largest impact for our users. Toward that end, we were attempting (in the post KiCon meeting) to define where that cut off should be. We kind of arbitrary picked "vendor supported" as it seemed reasonable. I now think we should tighten that a bit more for the Linux distributions. Under MSW/Mac, we compile or have rolling updates for most of our own dependencies. This allows us to ensure system compatibility but not worry about library compatibility. The Linux library system is different and holds back updates. So, why would we want to update the boost libraries and what does it gain us? The original bump was to allow unit tests. During v6, I would also like to utilize the UUID library from 1.60 as many of the feature we plan will require GUID at least. This doesn't preclude using KiCad on 16.04. It just requires someone to package a boost ppa. There are a few out there that could be used as baselines for this. -Seth KiCad Services Corporation Seth Hillbrand LEAD DEVELOPER +1-530-302-5483 [1] Davis, CA www.kipro-pcb.com [2]i...@kipro-pcb.com https://twitter.com/KiProEDA [3] https://www.linkedin.com/company/kicad [4] Links: -- [1] tel:+12126039372 [2] http://www.kipro-pcb.com/ [3] https://twitter.com/KiProEDA [4] https://www.linkedin.com/company/kicad___ 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] 5.1.5 release status
On 2019-10-21 22:08, Carsten Schoenert wrote: Hi, Am 21.10.19 um 23:16 schrieb Ian McInerney: We also seem to have assertions enabled in the Debian build (there have been two reports from users [1], [2]). Is this something we control as well, or is the the distribution packaging forcing them on? the Debian build configuration is visible in the GitLab repo for KiCad on Salsa. https://salsa.debian.org/electronics-team/KiCad/kicad https://salsa.debian.org/electronics-team/KiCad/kicad/blob/debian/sid/debian/rules I'm happily taken any patches if provided. Hi Carsten- Why do you have "hardening=+all" enabled? This is likely where the assertions are happening. We might consider "hardening=-all,+format,+fortify" Note, this is different from the mac builds where the debug asserts are happening in the wx code. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] 5.1.5 release status
On 2019-10-21 10:52, Ian McInerney wrote: Seth, Just to clarify, for 5.1.5 (and future 5.1 releases), the H/V/45 is only available during initial zone creation and is not going to be active for editing the lines after creation? If this is the case, I will push the bugs for this into the 6.0 milestone, so they can be addressed there. -Ian That is correct. I've already reset that bug[1]. But if you see others that relate to it, feel free to mark the dupes. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 [1] https://bugs.launchpad.net/kicad/+bug/1833673 ___ 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] SPICE .option confused with .op simulation
On 2019-10-19 12:54, Sylwester Kocjan wrote: Hi all, If user wants to add custom SPICE options on schematic, for example .option TEMP=60 .option TNOM=27 It will get confused with .op simulation and will be included on DIALOG_SIM_SETTINGS in custom simulation directive text field. Eventually simulation will fail. Please find the patch attached, where this issue is prevented. Best regards, Sylwester Good catch. I've pushed the patch to master and 5.1. Thank you for you for your contribution to KiCad. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Three new source types added to DIALOG_SPICE_MODEL
On 2019-10-20 08:36, Sylwester Kocjan wrote: Hi, Here is a patch with three additional source models implemented: SFFM, AM and Random. I hope this looks ok, cause I had troubles with configuring clang-format on Windows. If no, I can correct. Best regards, Sylwester ___ 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 Hi Sylwester- There is something odd with your patch. See the attached screenshot. I cannot apply this to test as there are a number of unknown characters at the end of lines and the end of the file. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372___ 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] 5.1.5 release status
Hi Wayne- These should be fixed. I've pushed the reload issue off to v6 as the setting isn't available in the current file format as Ian mentioned, so I've reset the associated bug with a new milestone. We should be clear for these reports now. It's safe to tag 5.1.5RC1 from my perspective and we'll get some testing of the fixes. It might be good to get a 5.1.6 milestone in launchpad at the same time and I will move all unaddressed items to that milestone so that we are only fixing issues with 5.1.5 commits during the RC phase. Thoughts? -Seth On 2019-10-20 07:38, Wayne Stambaugh wrote: Thanks Seth, There is also this[1] bug and this[2] bug and this[3] bug related to the zone constraint changes. I probably wont hold up the 5.1.5 release for them but they are behavioral changes which users will not expect. The most annoying one is lp:1846028. Cheers, Wayne [1]: https://bugs.launchpad.net/kicad/+bug/1842195 [2]: https://bugs.launchpad.net/kicad/+bug/1846028 [3]: https://bugs.launchpad.net/kicad/+bug/1846029 On 10/20/19 10:13 AM, Seth Hillbrand wrote: On 2019-10-20 06:41, Wayne Stambaugh wrote: Where are we on the 5.1.5 release? I took a look at the bug tacker and the only serious bug I saw was the glib assertion bug[1]. How close are we to getting this fixed? There is still some unexpected behavior with the constrained zone drawing and editing changes that should be fixed before we release. I would like to tag -rc1 and start the string freeze by the end of October. Odd, I didn't see that one come through. I'll fix that this weekend. -S Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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 Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] 5.1.5 release status
On 2019-10-20 08:40, Ian McInerney wrote: There is also this H/V/45 issue [1]. It is more of a gray area though, since it will probably involve touching the file format due to what is happening (the H/V/45 is being saved as a global board setting rather than a per-zone setting as the GUI would seem to make it). -Ian [1] https://bugs.launchpad.net/kicad/+bug/1847722 Ugh. You are right Ian. We definitely need to fix that one. Since I'm in the area, I'll deal with it. I'm going to disable the H/V/45 during edits. The setting will then only affect the newly created zone. Since we don't have a place to store the information, keeping it with the zone info doesn't make sense because it will change based on opening/closing the file. For v6, I think we add the parameter to the zone unless people object. -Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] 5.1.5 release status
On 2019-10-20 06:41, Wayne Stambaugh wrote: Where are we on the 5.1.5 release? I took a look at the bug tacker and the only serious bug I saw was the glib assertion bug[1]. How close are we to getting this fixed? There is still some unexpected behavior with the constrained zone drawing and editing changes that should be fixed before we release. I would like to tag -rc1 and start the string freeze by the end of October. Odd, I didn't see that one come through. I'll fix that this weekend. -S Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] KICAD_USE_FONT_REDUCED_SET question
On 2019-10-09 02:26, jp charras wrote: Hi Seth, Here is a test showing the memory used by pcbnew, with and without CJK font (I used the Windows monitor resources): Initial state: Available memory: 2280 Mb Kicad is compiled in Release version. pcbnew loaded, without CJK: Available memory: 2153 Mb pcbnew + fp viewer loaded, without CJK: Available memory: 2139 Mb Pcbnew+Eeschema, without CJK: Available memory: 2060 Mb pcbnew loaded, with CJK: Available memory: 1590 Mb pcbnew + fp viewer loaded, without CJK: Available memory: 1537 Mb Pcbnew+Eeschema, with CJK: Available memory: 1176 Mb So, the CJK font takes roughly 900Mb at run time when runnning Eeschema + Pcbnew. It explains why I am running out of memory. There is certainly room for optimization. Hi JP- I pushed an optimization for this. Can you let me know if it helps the memory usage for you? Best- Seth Seth Hillbrand KiCad Services Corporation https://www.kipro-pcb.com +1 530 302 5483 | +1 212 603 9372 ___ 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] Implement auto annotation on component/symbol placement.
On 2019-10-15 11:57, Moses McKnight wrote:
On 10/15/19 1:41 PM, Seth Hillbrand wrote:
4) Single-line statements after if/else don't get brackets {}
Is that actually part of the kicad code standard?!? Every standard
and recommendation I've ever seen recommends/requires the opposite to
prevent future errors (see for instance:
https://barrgroup.com/Embedded-Systems/Books/Embedded-C-Coding-Standard/General-Rules/Braces)
Moses
I should have expounded a bit more. Braces are optional[1]. They
should be used to help to clarify code, intent or structure. In the
patch submitted, braces were not consistently used for single-line
statements. The ones that were used were not needed and added extra
vertical space making reading the small function more difficult. This
was the root of comment (4)
Best-
Seth
Seth Hillbrand
KiCad Services Corporation
https://www.kipro-pcb.com
+1 530 302 5483 | +1 212 603 9372
[1]
https://kicad-source-mirror.readthedocs.io/en/stable/Documentation/development/coding-style-policy/#47-braces-braces
___
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] Implement auto annotation on component/symbol placement.
On 2019-10-15 11:41, Seth Hillbrand wrote:
On 2019-10-14 14:42, Zficani Zficani wrote:
Hi,
No problem, I just wanted to make sure I sent the message properly.
Here's a single squashed patch with all previous changes and these
comments about copying selection.
Thank you so much for your review.
Hi Zficani-
The functionality feels correct and I really like it. Here are a few
comments on the current patch:
1) I would prefer that the disabled options in the Annotation page are
grey (disabled) and not hidden when the option is unchecked. This
reserves the correct space for them when we add options in the future.
2) Please double-check your code formatting. Spaces inside the
parentheses are missing in a few spots.
3) Don't use C-style casts. C++ static_cast() is preferred.
4) Single-line statements after if/else don't get brackets {}
5) I think that pasting Unit B of a component should paste as the
first missing Unit B in the schematic and not the next open annotation
number. See the attached image for the result of duplicating a quad
op-amp for an example of this problem.
This will be a great addition to KiCad. Thank you for taking this one
on!
Best-
Seth
Seth Hillbrand
KiCad Services Corporation
+1 530 302 5483 | +1 212 603 9372
www.kipro-pcb.com
Davis, CA
One more thing: Please use `git format-patch` to submit the patches.
This will include your commit message and make it easier for us to apply
and test.
Best-
Seth
Seth Hillbrand
KiCad Services Corporation
+1 530 302 5483 | +1 212 603 9372
www.kipro-pcb.com
Davis, CA
___
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] GitLab migration
On 2019-10-14 16:09, Ian McInerney wrote:
Orson,
Great work so far.
I was noticing as you were testing migrating the issues that our @names
in the text seem to not transfer well. In one of the issues just now
(the pcbnew segfault issue #228 [2]) it pulls in a different user for
Seth whenever @seth is mentioned, and also for my name. Do you think it
would be possible to do two things with the message text:
1) Replace the @name usage for the most common people with their GitLab
user (this would require us to know all of them and have a map between
name and user). This should also be case insensitive, since we don't
always seem to capitalize names.
2) Escape the @name usage in other cases (maybe add a space between the
@ and the name?).
At the very least we should probably escape them so we don't randomly
mention unrelated people in all our issues.
On the topic of labels, I was doing some research and if we can get the
OSS license for GitLab I think we can turn the Launchpad status and
priority into scoped labels [1]. The nice thing about those is only one
label per scope can be applied to an issue at a time, and adding a new
label to an issue automatically removes the old one. I think we could
define scopes such as
priority::{wishlist, low, medium, etc...}
status::{new, confirmed, in progress, as designed, fix committed,
etc...}
By doing this I think it is nice and obvious what the open/close status
of the bug is (instead of just having open/close).
I'll second Ian's suggestion that the priorities and status both get
labels. I'd like to see Heat map to GitLab's weight. You can't really
search much with weight in GitLab (no range operators that I can find),
so it seems mostly useful for sorting after you get the results.
I think we'll need to figure out how to deal with our version
information in KiCad not being nicely formatted for markdown. The
blockquote for variable indents is readable but distracting. Maybe we
can get it into a block like:
KiCad Version Info
All the details here
Overall, this is great! Looking forward to the move.
-Seth
___
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] KICAD_USE_FONT_REDUCED_SET question
On 2019-10-09 02:26, jp charras wrote: Le 07/10/2019 à 20:07, Seth Hillbrand a écrit : Hi Seth, Here is a test showing the memory used by pcbnew, with and without CJK font (I used the Windows monitor resources): Initial state: Available memory: 2280 Mb Kicad is compiled in Release version. pcbnew loaded, without CJK: Available memory: 2153 Mb pcbnew + fp viewer loaded, without CJK: Available memory: 2139 Mb Pcbnew+Eeschema, without CJK: Available memory: 2060 Mb pcbnew loaded, with CJK: Available memory: 1590 Mb pcbnew + fp viewer loaded, without CJK: Available memory: 1537 Mb Pcbnew+Eeschema, with CJK: Available memory: 1176 Mb So, the CJK font takes roughly 900Mb at run time when runnning Eeschema + Pcbnew. It explains why I am running out of memory. There is certainly room for optimization. Thanks JP! I can look into that. I see the same difference in total size under Linux but interestingly not in malloc allocations, so I'll need to dig a bit deeper into that usage. Best- Seth Seth Hillbrand Chief Technologist KiCad Services Corporation +1 530 302 5483 | +1 212 603 9372 www.kipro-pcb.com Davis, CA ___ 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] Implement auto annotation on component/symbol placement.
On 2019-10-09 17:08, Zficani Zficani wrote: > Hi, > it's been about 10 days since my message so I just want to make sure I sent > it properly and you noticed it because I'm not sure as I'd want to be able to > actually use this feature soon because it's very useful for me. > > Thank you. > > On Sun, Sep 29, 2019 at 11:55 PM Zficani Zficani wrote: > >> Hi, >> I reviewed your remarks and made appropriate changes but I have a few >> questions. >> Regarding your first remark, I had to make them non-reference because >> the selection is sorted inplace which means that the original selection >> will be modified which in turn make unhighlight hang/enter and infinite >> loop when copying/duplicating or just unhighlighting multiple objects. >> I'm not sure why exactly this is happening but it obviously has >> something to do with the fact that selection is now sorted by >> reference. >> >> I did change the code according to the second and third remark though >> and will send in the patches later (it's currently available on >> https://github.com/Nufflee/kicad-source-mirror/tree/1335616-annotate-on-placement >> if anyone wants to take a look). Hi Zficani- I can't speak for others but I was waiting for either a patch with the revised code or a merge request on launchpad. I like the idea of your feature and look forward to helping get it into merge shape. I agree with Ian's comments and was hoping to see how you address them. Best- Seth Seth Hillbrand Chief Technologist KiCad Services Corporation Twitter [1] LinkedIn [2] +1 530 302 5483 [3] | +1 212 603 9372 [4] www.kipro-pcb.com [5] Davis, CA Links: -- [1] https://twitter.com/KiProEDA [2] https://www.linkedin.com/company/kicad/about [3] tel:+15303025483 [4] tel:+12126039372 [5] https://www.kipro-pcb.com/___ 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] KICAD_USE_FONT_REDUCED_SET question
Hi JP- I noticed that you added an option to disable the CJK ideographs in 34b26a0ac because you were seeing out of memory issues under OpenGL. The stroke fonts should only be loading on the system heap (4.5MB for the current CJK set), so if it's leaking into the video memory, I'd like to address that. Can you provide additional information about the symptoms you are seeing and I can see about fixing this? Thanks! Seth Seth Hillbrand Chief Technologist KiCad Services Corporation Twitter [1] LinkedIn [2] +1 530 302 5483 [3] | +1 212 603 9372 [4] www.kipro-pcb.com [5] Davis, CA Links: -- [1] https://twitter.com/KiProEDA [2] https://www.linkedin.com/company/kicad/about [3] tel:+15303025483 [4] tel:+12126039372 [5] https://www.kipro-pcb.com/___ 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] Grid Control: Cells selecting fix.
Patch pushed.
Thank you for your contribution to KiCad!
-Seth
On 2019-09-25 23:35, Константин Барановский wrote:
> Hi Seth.
>
> The problem is illustrated on the gif bellow:
>
> Please notice, no modifier keys are used.
> The patch is attached.
>
> ср, 25 сент. 2019 г. в 23:27, Seth Hillbrand :
>
>> Hi Konstantin-
>>
>> This makes sense. Can you send as a patch?
>>
>> -Seth
>>
>> On 2019-09-24 10:38, Konstantin Baranovskiy wrote:
>>> If *editable* cells had been selected by holding and dragging the
>>> mouse's left
>>> button, the previous selection were not clearing.
>>> ---
>>> common/grid_tricks.cpp | 3 +++
>>> 1 file changed, 3 insertions(+)
>>>
>>> diff --git a/common/grid_tricks.cpp b/common/grid_tricks.cpp
>>> index 832b704db..509cdbcc8 100644
>>> --- a/common/grid_tricks.cpp
>>> +++ b/common/grid_tricks.cpp
>>> @@ -63,6 +63,7 @@ bool GRID_TRICKS::toggleCell( int aRow, int aCol )
>>>
>>> if( isCheckbox )
>>> {
>>> +m_grid->ClearSelection();
>>> m_grid->SetGridCursor( aRow, aCol );
>>>
>>> wxGridTableBase* model = m_grid->GetTable();
>>> @@ -102,6 +103,8 @@ bool GRID_TRICKS::showEditor( int aRow, int aCol )
>>>
>>> if( m_grid->IsEditable() && !m_grid->IsReadOnly( aRow, aCol ) )
>>> {
>>> +m_grid->ClearSelection();
>>> +
>>> if( m_grid->GetSelectionMode() == wxGrid::wxGridSelectRows )
>>> {
>>> wxArrayInt rows = m_grid->GetSelectedRows();From 8532a7bffdd44efb36b32c519bec69c1717f51ab Mon Sep 17 00:00:00 2001
From: Konstantin Baranovskiy
Date: Tue, 24 Sep 2019 20:11:19 +0300
Subject: [PATCH] Grid Control: Cells selecting fix.
If *editable* cells had been selected by holding and dragging the mouse's left
button, the previous selection were not clearing.
---
common/grid_tricks.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/common/grid_tricks.cpp b/common/grid_tricks.cpp
index 832b704db..509cdbcc8 100644
--- a/common/grid_tricks.cpp
+++ b/common/grid_tricks.cpp
@@ -63,6 +63,7 @@ bool GRID_TRICKS::toggleCell( int aRow, int aCol )
if( isCheckbox )
{
+m_grid->ClearSelection();
m_grid->SetGridCursor( aRow, aCol );
wxGridTableBase* model = m_grid->GetTable();
@@ -102,6 +103,8 @@ bool GRID_TRICKS::showEditor( int aRow, int aCol )
if( m_grid->IsEditable() && !m_grid->IsReadOnly( aRow, aCol ) )
{
+m_grid->ClearSelection();
+
if( m_grid->GetSelectionMode() == wxGrid::wxGridSelectRows )
{
wxArrayInt rows = m_grid->GetSelectedRows();
--
2.23.0
___
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] Grid Control: Cells selecting fix.
Hi Konstantin-
This makes sense. Can you send as a patch?
-Seth
On 2019-09-24 10:38, Konstantin Baranovskiy wrote:
If *editable* cells had been selected by holding and dragging the
mouse's left
button, the previous selection were not clearing.
---
common/grid_tricks.cpp | 3 +++
1 file changed, 3 insertions(+)
diff --git a/common/grid_tricks.cpp b/common/grid_tricks.cpp
index 832b704db..509cdbcc8 100644
--- a/common/grid_tricks.cpp
+++ b/common/grid_tricks.cpp
@@ -63,6 +63,7 @@ bool GRID_TRICKS::toggleCell( int aRow, int aCol )
if( isCheckbox )
{
+m_grid->ClearSelection();
m_grid->SetGridCursor( aRow, aCol );
wxGridTableBase* model = m_grid->GetTable();
@@ -102,6 +103,8 @@ bool GRID_TRICKS::showEditor( int aRow, int aCol )
if( m_grid->IsEditable() && !m_grid->IsReadOnly( aRow, aCol ) )
{
+m_grid->ClearSelection();
+
if( m_grid->GetSelectionMode() == wxGrid::wxGridSelectRows )
{
wxArrayInt rows = m_grid->GetSelectedRows();
___
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] KiCad Services Corporation
Hi KiCad Folks- I wanted to publicly give people a heads up about the formation of the KiCad Services Corporation (KiPro), a Kicad-specific support company. We started in June with a soft-launch and have found a significant level of interest (hooray!). We're now fully operational and looking forward to contributing more to KiCad going forward. We've had a few questions from people in our community and I'd like to openly address them here. Q: What does KiPro do? A: We provide support contracts for companies that rely on KiCad. These are non-public bug reports and support tickets for companies and professionals working on proprietary designs or who need guaranteed support levels. Companies can get their questions answered and bugs fixed without needing to publicly disclose their designs. We also offer dedicated feature development. Q: Any relation to WIT (the company that employs Wayne Stambaugh)? A: Not at this time except that we are both working toward the same goal of open-source hardware development models. Q: Does KiPro share resources with KiCad? A: We do not take donations from KiCad or CERN. We look forward to providing funding to support KiCad activities in the future. Q: Will KiPro divert resources from the KiCad community? A: While some businesses may choose to purchase a KiPro support subscription instead of donating through CERN, this is likely to be a minority as the KiPro subscriptions and contracts are payment in return for services and not donations. Additionally, the KiCad Services Corporation is chartered to support the free and open development of KiCad, so funds in excess of operating expenses are used to support full-time developers, testers and documentation writers. It is our goal for the additional KiCad awareness and activity we provide to increase the total level of charitable contributions KiCad receives through CERN. Q: Does KiPro or its clients direct KiCad development? A: No. All bug-fixes and documentation developed by KiPro employees will be submitted as patches to the appropriate mailing lists for public discussion. Any feature development will be proposed and outlined on the kicad-developers list and be agreed to by the lead developer team prior to our work. We serve as an intermediary and accelerant to businesses looking for specific KiCad features, ensuring that features are both inline with long-term KiCad development as well as incorporating feedback from the broader community. Q: Is this a non-profit (501(c)3) organization? A: No. KiCad Services Corporation is a California Corporation with the mission to advance the development and uptake of the KiCad software package as an open source system. Please feel free to raise any additional questions or concerns you might have and I'll do my best to address them. Regards- Seth Hillbrand Chief Technologist KiCad Services Corporation Twitter [1] LinkedIn [2] +1 530 302 5483 [3] | +1 212 603 9372 [4] www.kipro-pcb.com [5] Davis, CA Links: -- [1] https://twitter.com/KiProEDA [2] https://www.linkedin.com/company/kicad/about [3] tel:+15303025483 [4] tel:+12126039372 [5] https://www.kipro-pcb.com/___ 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] Ctrl-click to highlight in pcbnew missing?
On 2019-09-10 14:35, Tomasz Wlostowski wrote: On 10/09/2019 18:49, Seth Hillbrand wrote: One of our goals for v6 is to standardize the user interface to expected UX norms. There will be a number of large changes to accomplish this and it will modify some workflows. Moving the whole system to a selection-based interface (eeschema, pl editor as well as pcbnew) is good for long-term uptake of the system as well as making it easier to maintain. Well, Ctrl-click to highlight was added by me during early development of the GAL, because some other tools I'm quite used to have this shortcut and the legacy highlight tool was a bit awkward for me. Concerning the UX norms, it's not obvious that Ctrl is the standard way of adding/removing items from the current selection. A quick test showed that: - MS office selection mode (sort of standard for Windows UX), Ctrl and Shift have the same behaviour. - LibreOffice ignores Ctrl modifier when selecting, only Shift works - Same in case of Corel programs. I know these keys have different function for selection lists (i.e. the explorer window with folder/file icons), but this is not our case. IMHO modifier keys (Shift, Alt, Ctrl) in a CAD tool should each have different frequently used function. If nobody opposes, I'll add an option in pcbnew preferences to select between Ctrl-Click and a keyboard-only shortcut for net highlight. Cheers, Tom There's a bug report somewhere for allowing modifier keys to be customized for mouse actions. I suspect that this change would fit in there (probably a panel in pcbnew options?) -S ___ 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] Ctrl-click to highlight in pcbnew missing?
One of our goals for v6 is to standardize the user interface to expected UX norms. There will be a number of large changes to accomplish this and it will modify some workflows. Moving the whole system to a selection-based interface (eeschema, pl editor as well as pcbnew) is good for long-term uptake of the system as well as making it easier to maintain. -S On 2019-09-10 12:29, José Ignacio wrote: That's a big change. Are you sure it is a good idea to do without asking users about it? (from my part it would annoy me quite a bit if i was using master). On Tue, Sep 10, 2019 at 8:09 AM Jeff Young wrote: Ctrl-click was made consistent with Pcbnew (and platform standards) for toggle selection. ` is now hooked up to highlight net. Cheers, Jeff. On 10 Sep 2019, at 13:30, Tomasz Wlostowski wrote: Hi, Am I missing something or did Ctrl-click to highlight a net suddenly stopped working in pcbnew? Cheers, Tom ___ 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 ___ 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 ___ 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 ___ 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][WIP] Polygons edititng tool
On 2019-09-09 08:21, Alexander Shuklin wrote: Hi! There's one thing I always missed - ability to change polygons coordinates. I prepared a patch for that. First of all there's the linechain editing widget and I used it for some pcbnew dialogs. But there's few points in which I'm not so sure. First of all, I added SHAPE_LINE_CHAIN property to ZONE_SETTINGS I see, that ZONE_SETTINGS holds geometry in SHAPE_POLY_SET. But is it some equal SHAPE_LINE_CHAIN's? Is it ok to hold just SHAPE_LINE_CHAIN to understand zone geometry? Anyway, that's what i've done: auto outline = aSource.Outline(); if( outline->OutlineCount() ) m_shape = outline->COutline( 0 ); to get geometry auto outline = aTarget.Outline(); for( int i = 0; i < outline->OutlineCount(); ++i ) outline->Outline( i ) = m_shape; to set geometry That's work, but if that's bad I can switch to use SHAPE_POLY_SET And basically some of dialogs look a bit weird. It's probably good idea to rearrange some, but I would need your advices. I tested as I can zone features, and everything looks ok with that patch. Hi Alexander- We cannot assume that the Zone is merely a SHAPE_LINE_CHAIN. Holes in the zone also live in the SHAPE_POLY_SET and should be addressed by a point-editing patch. Unfortunately, I don't see a patch attached to this e-mail (or the other one that was attached to CERN Open Days). You can also make a merge request on launchpad or create a bug report for the feature and attach the patch there. Best- Seth ___ 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 0/2] Remove useless casts
On 2019-09-06 18:36, Simon Richter wrote: Hi, I have two patches that remove useless casts. The first covers cases where it is quite obvious that the cast can be removed with no adverse effects, the second contains the cases where that is less clear. In theory, both can be applied and should not cause code changes, but the second needs review to see if something else was originally intended by that code. Simon Hi Simon- I'm in favor of cleaning the casts as we code or if there's a specific instance where the cast creates a problem (perhaps causing an unneeded class instantiation). The large size of these patches without a clear problem they are solving makes me leery that we will introduce a new issue and I'd prefer to avoid this if possible. Best- Seth ___ 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] Another hotkey processing fix
Wow, this bug has been a real annoyance for some time. Thank you for tracking down the origin. I've tested Ian's patch and it works correctly. Allows the 'P' hotkey to correctly trigger the Place Power action in eeschema and the Create Pin action in LibEdit. Tested with individual applications as well as with both applications running at the same time. Note, however, that when we edit the hotkeys in preferences, no such testing of whether a hotkey is handled takes place and we simply show a warning that the 'P' hotkey is bound to two separate actions. I'm not sure what the course of action here could be other than to separate testing of the hotkey overlap between applications. -Seth On 2019-09-05 17:21, Ian McInerney wrote: This somehow got lost in my email, but I have now found a case where this is needed in the "wild" (the master branch). For bug https://bugs.launchpad.net/kicad/+bug/1834547, it appears that on Linux the hotkey architecture is trying to run the action for place symbol pin instead of the place power action. These two actions are never active on the same editing session, so it is a valid configuration. Applying this patch fixes the behavior, and the place power symbol action is actually called. -Ian On Mon, Aug 12, 2019 at 9:02 PM Wayne Stambaugh wrote: What is the status of this patch? Cheers, Wayne On 8/8/19 7:16 PM, Ian McInerney wrote: > In the current framework, if more than one global actions share the same > hotkey (even if they are not all active in the current tool manager), > the dispatcher will only choose the final action (in what seems to be > alphabetical order) to run. I think that the correct behavior should > instead be to loop through all global actions that have the hotkey until > one handles it. > > The attached patch implements this change. > > -Ian > > ___ > 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 > ___ 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 ___ 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 ___ 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] Selection highlighting changes.
Hi Wayne-Have a look at the new default gtk color. I think it shows up well but we can always adjust.-SethOn Sep 5, 2019 5:07 AM, Wayne Stambaugh wrote:I would prefer that we pick a more obvious color out of the box. Under certain zoom conditions it's difficult to tell if anything is even selected on gtk3. Users could make it more subtle if they find it too obnoxious. I think that would be better than a bug report about selection highlighting not working. Wayne On 9/4/19 7:24 PM, Seth Hillbrand wrote: > Oh, that's right. We had been taking the color from system preferences > but this did not show up correctly on schematic sheets that were not the > system window color. Allowing for customization fixes this but the > coloring is very light. It apparently looks correct on Mac but is very > washed out under GTK3. I've added a conditional for the defaults that > sets GTK/MSW values to the ones that seem appropriate on GTK3. We may > want an additional default value for MSW if it similarly appears off. > > -S > > On 2019-09-04 18:12, Jeff Young wrote: >> The colour is in Preferences now; see if it’s just too washed out on >> your monitor. >> >>> On 4 Sep 2019, at 22:35, Seth Hillbrand wrote: >>> >>> I'm working on one (slowly) but it hasn't been pushed. GTK3 in the >>> master branch looks normal for me. >>> >>> Does it look the same in OpenGL and Cairo? >>> >>> _Seth >>> >>> On 2019-09-04 15:36, Wayne Stambaugh wrote: >>>> Was there a change recently to the selection highlighting in Eeschema? >>>> I can barely see any difference between the selected and unselected >>>> objects. If there has not been changes then something needs to be done >>>> about the highlighting on gtk3 builds on linux. I thought I would >>>> check >>>> before I filed a bug report. >>>> Cheers, >>>> Wayne >>>> ___ >>>> 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 >>> >>> ___ >>> 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 ___ 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] Selection highlighting changes.
Oh, that's right. We had been taking the color from system preferences but this did not show up correctly on schematic sheets that were not the system window color. Allowing for customization fixes this but the coloring is very light. It apparently looks correct on Mac but is very washed out under GTK3. I've added a conditional for the defaults that sets GTK/MSW values to the ones that seem appropriate on GTK3. We may want an additional default value for MSW if it similarly appears off. -S On 2019-09-04 18:12, Jeff Young wrote: The colour is in Preferences now; see if it’s just too washed out on your monitor. On 4 Sep 2019, at 22:35, Seth Hillbrand wrote: I'm working on one (slowly) but it hasn't been pushed. GTK3 in the master branch looks normal for me. Does it look the same in OpenGL and Cairo? _Seth On 2019-09-04 15:36, Wayne Stambaugh wrote: Was there a change recently to the selection highlighting in Eeschema? I can barely see any difference between the selected and unselected objects. If there has not been changes then something needs to be done about the highlighting on gtk3 builds on linux. I thought I would check before I filed a bug report. Cheers, Wayne ___ 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 ___ 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 ___ 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] Update common preview items
All good from what I see. I appreciate the cleanup here to drop down to base classes where possible! -Seth On 2019-09-04 15:31, Wayne Stambaugh wrote: This patch looks good to me. Anyone else have any objections? On 8/31/19 10:42 AM, Ian McInerney wrote: Some preview items were still static casting into PCB_RENDER_SETTINGS while others were using the base class version to get the layer colors. This patch updates it so all calls are to the base class version, this also removes the need to have pcb_painter (and any pcbnew includes) in these files. -Ian ___ 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 ___ 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 ___ 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] Selection highlighting changes.
I'm working on one (slowly) but it hasn't been pushed. GTK3 in the master branch looks normal for me. Does it look the same in OpenGL and Cairo? _Seth On 2019-09-04 15:36, Wayne Stambaugh wrote: Was there a change recently to the selection highlighting in Eeschema? I can barely see any difference between the selected and unselected objects. If there has not been changes then something needs to be done about the highlighting on gtk3 builds on linux. I thought I would check before I filed a bug report. Cheers, Wayne ___ 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 ___ 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] Commit c8a6878 breaks compilation on msys2
Whoops. Thanks JP. Fix incoming. -S On 2019-09-04 12:35, jp charras wrote: common.h does not compile with msys2/gcc 9.1.0 Here is the error message: In file included from D:/wxWidgets-3.1.1/include/wx/defs.h:851, from D:/wxWidgets-3.1.1/include/wx/wx.h:14, from E:/kicad-launchpad/gerber_dev/include/common.h:37, from E:/kicad-launchpad/gerber_dev/polygon/math_for_graphics.cpp:8: E:/kicad-launchpad/gerber_dev/include/common.h: In function 'constexpr ret_type KiROUND(fp_type)': E:/kicad-launchpad/gerber_dev/include/common.h:118:5: error: 'asm' in 'constexpr' function 118 | wxASSERT( ret <= std::numeric_limits::max() Looks to me using wxASSERT here creates this issue. (I replaced wxASSERT by a printf controlled by the same condition to compile Kicad) ___ 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] Selection Highlighting
Hi Jeff (and others interested)- I pushed a proposal for blurring the eeschema selection highlighting to my personal repo at [1]. Currently, I'm only blurring the Cairo selections, so don't run this branch with OpenGL yet. I really like the new eeschema halo-for-selection paradigm but it does suffer for legibility issues on small text. The blur of the halo fixes this somewhat and gives the selection a smoother feel (imo). If folks like it, I'll write up some shaders for OpenGL to do the same. The performance doesn't seem bad on my machine, but I'd love additional opinions/comments Best- Seth [1] https://code.launchpad.net/~sethh/kicad/+git/kicad/+ref/blur_highlight ___ 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] Multiple delete in dialog_spice_model.cpp
On 2019-08-30 15:49, Sylwester Kocjan wrote:
m_schfields->erase( std::remove_if(
m_schfields->begin(), m_schfields->end(),
[&]( const SCH_FIELD& f ) { return f.GetName()
== spiceField; } ), m_schfields->end() );
My question is, why deletion is repeated: at first there is called
remove_if(), and later erase(), which will delete
all the fields behind the removed one. From my point of view it looks
like remove_if() only should be enough.
remove_if() re-orders the container and returns the iterator that points
to the first matching element. erase() removes all elements from this
iterator through the end of the container.
See https://en.wikipedia.org/wiki/Erase%E2%80%93remove_idiom
___
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] MacOS ngspice version
Note: Changing thread to avoid hijacking. On 2019-08-28 08:05, Jonatan Liljedahl wrote: It would be great if you could roll back to ngspice-26 in 5.1.5, at least for macOS, since it seems completely broken (can't simulate op-amps, etc). Cheers /Jonatan Hi Jonatan- Please see bug tracker[1] for information on this. [1] https://bugs.launchpad.net/kicad/+bug/1836104 ___ 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.5 RC?
Hi All- I know 5.1.4 is still in its infancy but I am hoping that we can plan for a 5.1.5 during September (fixing at least 2 critical bugs). We've been a bit rocky with the point updates, so I'd like to propose a sequence: 1) Sometime around September 15: Tag 5.1.5-rc1 and announce string freeze to give give translations a chance to update and tag 5.1.5 2) At this point, we don't push anything to 5.1 unless it is fix for a critical bug. No other fixes until after 5.1.5. 3) If there is a fix for a critical bug, we tag 5.1.5-rc2 after. 4) 7 days after the last rc2 is tagged, we tag 5.1.5 What do folks think about this scheme? Maybe a way to avoid the 5.1.3 (and 5.1.1 and 5.0.1 before it) situation? -Seth ___ 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] Opinions on eeschema selection highlighting?
On 2019-08-23 13:19, Jeff Young wrote: While I wasn’t too happy with it at first, the new selection highlighting has really grown on me. How do others feel about it? Hi Jeff- I pushed a small patch to address configuring the highlight color along with the rest of the KiCad color themes. Let me know if you see any issues. -S ___ 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: Fixing a compile error on Power PC
On 2019-08-26 16:05, Tomasz Wlostowski wrote: On 26/08/2019 17:24, Seth Hillbrand wrote: Agreed. That looks like it may be have been a rebase issue as the commit was for MSVC and shouldn't affect PPC. @Tom, shout if you see an issue here. I've pushed the patch to master in the meantime. I don't see a technical issue, but rather a practical one: why Linux distributions dictate us what architectures we should support? I've never seen a machine with a little-endian PPC. Tom The LE variant is the PPC future starting with POWER8[1][2]. [1] https://www.phoronix.com/scan.php?page=news_item=POWER-PPC64-Discontinue-Fedora [2] https://developer.ibm.com/articles/l-power-little-endian-faq-trs/ ___ 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: Fixing a compile error on Power PC
Agreed. That looks like it may be have been a rebase issue as the commit was for MSVC and shouldn't affect PPC. @Tom, shout if you see an issue here. I've pushed the patch to master in the meantime. Best- Seth On 2019-08-24 18:00, Steven A. Falco wrote: I have enabled compilation for PPC64LE, because that was requested by a Fedora user. KiCAD builds fine for 5.1, but the PPC64 compilation is broken on master. The attached patch fixes that by reverting a small portion of commit 6cab769f41f. Basically, on a 64-bit PPC machine, gcc defines both _ARCH_PPC and _ARCH_PPC64, thus commit 6cab769f41f resulted in trying to compile 32-bit PPC assembly code on PPC64. Also, assuming the assembly worked, we would have wound up with multiple copies of the context code. Steve ___ 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 ___ 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] Opinions on eeschema selection highlighting?
On 2019-08-23 13:19, Jeff Young wrote: While I wasn’t too happy with it at first, the new selection highlighting has really grown on me. How do others feel about it? I find it clear and useful. No complaints -Seth ___ 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] Fedora reported bug 1742898
On 2019-08-17 09:31, Steven A. Falco wrote:
I just noticed the following bug report on Kicad 5.1.2, reported for
Fedora 30:
https://bugzilla.redhat.com/show_bug.cgi?id=1742898
According to the report, a crash happened in poll_for_event, and the
bug author added some text about what he thought he was doing at the
time of the crash.
There is a backtrace in the report.
Would one of the developers please take a look at the bug report to
see if the cause of the crash can be identified?
Unfortunately there's not much in this report. It's another assert but
there's no information in the backtrace that ties this to something
KiCad does ("!xcb_xlib_threads_sequence_lost"). The only KiCad calls
are "main" and "APP_KICAD::OnRun"
I'd put it into the KiCad bug tracker in case we see something like this
again. But I don't see anything we can do with the report.
-Seth
___
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] [RFC] Comments for a Layer Stack Manager in Pcbnew
Hi JP- This looks like a good addition. I'm happy to see it being developed. A few notes: - "dielectric_constrains" maybe could be "dielectric_constraints" - It would be nice to see this replace the "Layers" panel in Board setup. We also set pcb thickness there as well as have our add/remove layer feature, which would be nice to integrate with your dialog. - Units (mm/mil/in) would be good to have in the header instead of in the text box - If you decide to move this to the Board setup, the options like "Impedance control, plated edges, etc" could fit in a separate panel giving more room for the primary table. - I'd love it if the rows had alternating background colors that coded for the type of material all the way across. That would make viewing much easier. Overall, I really like where this is headed. It will make some of the 2581-work much easier, thank you! Best- Seth On 2019-08-10 07:18, jp charras wrote: Since a long time, I started (slowly...) a layer stack manager. The purpose is to allow users to define (for board fabrication) some important parameters like: - tech, copper and dielectric thickness - color of some tech layers - dielectric material - board constraints. All of these parameters are in the .gbrjob file generated when plotting gbr files. Note also these parameters are not used in the board editor, only used to fabricate the board. the dialog is available from the "Tools" menu. The ultimate purpose is to have something like a CAM tool to manage info about the board fabrication and to create files needed to fabricate the board all in once. This is mandatory to ensure all files (gbr files, gbrjob files, placement files and some others) are created at the same time, and use the same settings. The first step is this layer Stack Manager. Please test and comment. Note also the dialog is not very good, but it is good enough (i hope) to test the feature. The main result of these settings is in the .gbrjob file. Thanks. ___ 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 ___ 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] Fix some memory leaks
On 2019-08-13 10:50, Wayne Stambaugh wrote: On 8/13/19 2:13 AM, jp charras wrote: Le 12/08/2019 à 21:54, Wayne Stambaugh a écrit : Sounds like a plan. If there are not bug reports against this over the next month, I'll will cherry-pick it into 5.1. Wayne I am not sure this issue exists in 5.1. AFAIK it comes from moving code from our DLIST to std::deque, only in master branch. Our DLIST dtor manages (when it has the ownership) the items deletion. But std::deque does not delete the items, so the code using std::deque has to delete these items. Maybe we should have used boost::ptr_deque instead. You get heap allocation cleanup for free. We can adjust between containers now if desired as long as they obey the std::random_access_iterator constraints. The major work in moving from DLIST was removing all the places where we assumed the element was itself a list. For now, I prefer keeping the single list cleanup in the board dtor until we have a standardized python interface that doesn't expose our internals. After we abstract the python interface, I see no reason why we wouldn't utilize std::unique_ptr as Simon suggested. -Seth ___ 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] Coding style question
+1 for typing out the first definition. In functions, I'd be in favor of using 'auto' and 'decltype' when declaring local variables that need to match the class variable. Best- Seth On 2019-08-08 02:43, Jeff Young wrote: When I worked at Frame a colleague advised me not to create Framegol. (That was back in the day when Pascal and C were considered Algol family languages.) I’ve always taken that to heart and so prefer std::shared_ptr, ugly as it is. Cheers, Jeff. On 7 Aug 2019, at 23:18, Tomasz Wlostowski wrote: Hi Fellow Devs, I'm fixing some memory management issues in the P by introducing smart pointers here and there. Do we have any coding policy on typedefing shared_ptrs/unique_ptrs? Should I: - always use std::shared_ptr explicitly? - or am I allowed to typedef std::shared_ptr TYPE_SP (or something alike)? Cheers, Tom ___ 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 ___ 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 ___ 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] C++14 (redux)
Hi Wayne-
Sounds good. I've removed the libglm hold. This will make building on
Buster easier going forward.
-Seth
On 2019-08-06 16:28, Wayne Stambaugh wrote:
Ian,
We have had our own make_unique implementation for quite some time (see
include/make_unique.h) so even without c++14, you can use make_unique.
This includes the 5.1 branch. The master branch is c++14 where the 5.1
branch is c++11 so as long as you are not fixing anything that would
need cherry picked to the 5.1 branch, then c++14 is acceptable.
Cheers,
Wayne
On 8/6/19 4:21 PM, Ian McInerney wrote:
Is the master branch now open for C++14-based code submissions, or are
we still waiting some before allowing them? (I have a change that
would
benefit greatly from make_unique, but I can hold off on it until we
are
open).
-Ian
On Fri, Jul 12, 2019 at 4:16 PM Nick Østergaard mailto:oe.n...@gmail.com>> wrote:
Yes, using gnu+14 on windows
fre. 12. jul. 2019 15.34 skrev Seth Hillbrand mailto:s...@hillbrand.org>>:
Thanks Nick! I pushed the patch to the master branch on
Wednesday.
Ubunutu, Mac and Windows all appear to have built their
nightlies
without problem. I was going to check in on Fedora this
weekend
but
this seems like a quiet transition so far. :)
-Seth
On 2019-07-12 05:00, Nick Østergaard wrote:
> Just for the record, I did build test it on msys2/mingw on
windows, I
> added these args to cmake.
>
> -DCMAKE_CXX_STANDARD=14 \
> -DCMAKE_CXX_STANDARD_REQUIRED=ON \
> -DCMAKE_CXX_EXTENSIONS=OFF \
> -DCMAKE_CXX_FLAGS=-U__STRICT_ANSI__ \
>
> The __STRICT_ANSI__ is required because of using wx 3.0 as
far
as I
> understand it, Simon shared below patch to me.
>
> http://psi5.com/~geier/extensions.diff
>
> I did not runtime test it, but it built just fine for x86_64
at least.
>
> On Wed, 10 Jul 2019 at 21:03, Wayne Stambaugh
mailto:stambau...@gmail.com>>
> wrote:
>>
>> Seth,
>>
>> That's fine but we might want to give it more than a week
or
two. I
>> was
>> thinking more like a month or two.
>>
>> Wayne
>>
>> On 7/10/19 2:06 PM, Seth Hillbrand wrote:
>> > Hi Wayne-
>> >
>> > No worries!
>> >
>> > How about this: We bump the C++ version in cmake but not
put any C++14
>> > code into the codebase for a week or two to see if there
are any issues
>> > with supported platform packagers. If there are issues
with supported
>> > platforms, we revert and wait for v7. If not, we start
allow C++14 code.
>> >
>> > -Seth
>> >
>> >
>> > On 2019-07-10 13:00, Wayne Stambaugh wrote:
>> >> Hey Seth,
>> >>
>> >> Sorry for the delayed response, this got lost in my
inbox. I'm on the
>> >> fence about this. My gut says push it v7 development
given the amount
>> >> of work we have to do for v6 but I'm not opposed to it
as
long as we can
>> >> build it on all of our supported platforms.
>> >>
>> >> Cheers,
>> >>
>> >> Wayne
>> >>
>> >> On 7/5/19 3:52 PM, Seth Hillbrand wrote:
>> >>> Hi Wayne-
>> >>>
>> >>> This shouldn't affect users, only developers. Once the
binary is built,
>> >>> there are no differences in requirements for running
KiCad.
>> >>>
>> >>> I would only push this to master and not 5.1, so that
5.1.3+ bug fixes
>> >>> will still build for 14.04 (which was supported when
5.1
was released).
>> >>>
>> >>> -Seth
>> >>>
>> >>>
>> >>> On 2019-07-05 14:30, Wayne Stambaugh wrote:
>> >>>> Hey Seth,
>> >>>>
>> >>>> Sorry about the delay. I've been wrestling (and
loosing) with
>> >>>> restoring
>> >>>> a broken boot manager on my desktop after a bios
update
stepped all
>> >>>> over
>> >&g
Re: [Kicad-developers] How to make single-plane .cpp from .png?
On 2019-08-05 15:22, Jeff Young wrote: Our PNG2cpp.cmake script makes a 3 or 4 plane (ie: colour) char array. wxWidgets’ wxBitmap() constructor needs a single plane char array. John Beard created a couple for the SPICE cursors, but I’m not sure how he did it. I'm pretty sure that John just moved the cursors that Orson built. The PNG2cpp puts raw PNG data into cpp arrays. Are you looking to build a new cursor library? If you want to generate binary (white or black) cursors, you can save the icon as an XBM file from gimp. Then 0=white and 1=black. You can use the same PNG2cpp script to convert the file from XBM to a cpp array. -Seth ___ 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] Fix initialization order for COLOR4D statics
Thanks Ian. This looks good. Patch merged. -Seth On 2019-08-05 10:39, Ian McInerney wrote: The updated patch using constexpr (which now only affects the color4d files) is attached. Simon, thanks for the suggestion to use constexpr. It ended up working by just declaring the variables constexpr and also making one of the constructors constexpr. Definitely much simpler. -Ian On Mon, Aug 5, 2019 at 2:10 PM Wayne Stambaugh wrote: On 8/5/19 5:03 AM, Simon Richter wrote: Hi, On Mon, Aug 05, 2019 at 10:58:44AM +0200, Ian McInerney wrote: I tracked it down to the fact that COLOR4D has some static colors that were being used to initialize some other static variables in pcbnew's layer widgets. I have moved all the static colors to an initialize on first use paradigm (so now we just call them like a function, e.g. COLOR4D::UNSPECIFIED() ) to fix it. Can that be solved by constexpr? Simon I would prefer the constexpr solution if it resolves the issue. It certainly would be a much simpler patch. Wayne ___ 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 ___ 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 ___ 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] Eeschema - Bus definitions: make hints translatable.
On 2019-08-02 13:58, Konstantin Baranovskiy wrote: From: Baranovskiy Konstantin --- eeschema/dialogs/dialog_bus_manager.cpp | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/eeschema/dialogs/dialog_bus_manager.cpp b/eeschema/dialogs/dialog_bus_manager.cpp index 4144d1bc3..608b34178 100644 --- a/eeschema/dialogs/dialog_bus_manager.cpp +++ b/eeschema/dialogs/dialog_bus_manager.cpp @@ -175,8 +175,8 @@ DIALOG_BUS_MANAGER::DIALOG_BUS_MANAGER( SCH_EDIT_FRAME* aParent ) m_btn_rename_signal->Disable(); m_btn_remove_signal->Disable(); -m_bus_edit->SetHint( _T( "Bus Alias Name" ) ); -m_signal_edit->SetHint( _T( "Net or Bus Name" ) ); +m_bus_edit->SetHint( _( "Bus Alias Name" ) ); +m_signal_edit->SetHint( _( "Net or Bus Name" ) ); FinishDialogSettings(); } Hi Konstantin- Thank you for the patch. It looks like JP already took care of this in 120637bd9bdc1d1d836d3c8172a88a47e2f12e1d Best- Seth ___ 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] repetitive string...
On 2019-07-30 10:40, Marco Ciampa wrote: Hi devs, a (possible, as usual) silly question... Is it possible to parameterize this string? pcb_actions.cpp ... TOOL_ACTION PCB_ACTIONS::layerInner28( "pcbnew.Control.layerInner28", AS_GLOBAL, 0, "", _( "Switch to Inner layer 28" ), "", nullptr, AF_NONE, (void*) In28_Cu ); ... to avoid to have translate some 32 completely similar strings X all languages just for the inner layer number? If the answer is "no", please just delete this message... Hi Marco- Sorry for the delay in response. In the current setup, we can't parameterize these. But we're going to be implementing a sequence-based hotkey structure during v6. I imagine that this set of actions will be prime candidates, so the hotkey string will only be something like "Switch to layer number..." and the second key in the sequence will represent the layer number and not need a translation. Best- Seth ___ 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] Anyone know where the sources to the simulation cursors are?
Maybe Orson has the answer here? On 2019-08-05 12:06, Jeff Young wrote: ___ 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 ___ 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] 5.1.3 release
On 2019-08-03 11:12, Wayne Stambaugh wrote: On 8/2/19 5:18 PM, Steven A. Falco wrote: On 8/2/19 3:05 PM, Wayne Stambaugh wrote: Looks like we will be forgoing a 5.1.3 release and jumping to 5.1.4. This bug is a definite show stopper. We need to do a better job of testing fixes before we merge them into the 5.1 branch. Maybe we need to start doing release candidates on the stable branch before releasing buggy bug fixes? For those packagers who are providing 5.1.3 for distos, I would avoid releasing it. I'm attempting to stop 5.1.3 from moving into Fedora. I may need a Fedora admin to grant me additional privileges to do so, since the build has already entered the package queue. I'll wait for 5.1.4 to be tagged and then I'll start up a new build. As to Wayne having to delay his announcement because of insufficient Fedora karma, I'll request that people on this list test and give karma for future builds. Just three positive votes will be sufficient to expedite release. As to the discussion from https://bugs.launchpad.net/kicad/+bug/1838448 I've now had two folks working for RedHat advise me not to circumvent the _GLIBCXX_ASSERTIONS, because of security concerns related to buffer overflows. So I think in the interest of safety, I need to leave those asserts in place. Steve I think I found a solution. I can tag commit 090073cc3b79f4f646f3c82390eb02a253e488d8 as 5.1.4. No translations are required so we should be able to tag the translations, libs, and docs at the same commit as the 5.1.3 tag. This would only require updating the builds and stable release announcement. Unfortunately this doesn't solve the assertion issue on Fedora. If I include the commits that fix the Fedora issue, we will have to wait for the translations because there are a bunch of string changes after commit cf949609b25a43b66b985baab8ae5354ad8510ae so including them would push back the release significantly. If there are no objections, I will tag 5.1.4 today so we can get moving on a new stable release. Cheers, Wayne Hi Wayne- We could revert the commits post 090073cc3b79f4f646f3c82390eb02a253e488d8 that changed strings and then tag 5.1.4 and re-commit the reverts. Not pretty but it for a one-off, it might not be so bad. -Seth ___ 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] PCBNew Find and "match words"
On 2019-07-26 14:39, Jeff Young wrote: PCBNew’s current Find does a match against the whole string. I think it would be more intuitive with a ‘*’ in front and back of the search string (so that it finds partial matches). Any other opinions? ___ 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 Hi Jeff- Here's a mockup of something I was poking at a while ago. Different processing for different purposes. As long as we remember the checkboxes between uses, people's search preferences are allowed/respected. -Seth___ 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] Eeschema selection
On 2019-07-19 19:03, Jeff Young wrote: I’ve been thinking of using the magenta colour for both net highlighting and cross-probing, and then using the bright red we use today for cross-probing for selection. This does mean that selections would no longer have differentiated colours within (between components, wires, etc.), but I think might work better than the not-very-noticeable state we have today. I toyed with this a bit and I'm not a huge fan. Turns out I actually use the color differences for context when working. What do you think about darkening + bold (say width * 1.2)? -Seth ___ 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] fp-info-cache question
On 2019-07-24 13:58, Andy Peters wrote: On Jul 23, 2019, at 2:46 PM, Jeff Young wrote: Hi Kevin, No this is just a cache of footprint library properties so that we can index and search footprints without loading them all into memory. It’s entirely for performance. User question: Should the project-level cache file be included in the SCC respository, or is it rebuilt as necessary? Currently the cache file holds both project and global libraries. Thus it leaks your system setup information and should be in your .gitignore file for the project. It is rebuilt when missing. -S ___ 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] fp-info-cache question
On 2019-07-23 13:38, jp charras wrote: Le 23/07/2019 à 19:22, Jeff Young a écrit : Hi Seth, I think that would work. And you’re right — there probably aren’t enough project libs to require a cache for them. I am not sure to understand. The cache is by lib table, or by library file? This is very different: if it is by lib table, I am thinking lib table projects require a cache. The cache uses the combined global + project lib tables right now and stores in the project directory. I am proposing making the cache only for the global lib table and store it next to the global library table and not cache the project library files at all. Alternatively, we could merge the cache and the table files. Global library table file gets the global cache, project library table file gets the project-specific cache. Thoughts? -Seth ___ 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] fp-info-cache question
No worries, I got this one. -S On 2019-07-23 13:22, Jeff Young wrote: Hi Seth, I think that would work. And you’re right — there probably aren’t enough project libs to require a cache for them. I’m knee-deep in the router right now, though, so someone else would have to do it. Cheers, Jeff. On 23 Jul 2019, at 09:47, Seth Hillbrand wrote: Could we write the global cache in the user's config directory next to where we write fp-lib-table? If we cache global, we might not need project-based caching. -Seth On 2019-07-23 11:39, Jeff Young wrote: Hi Rene, Separate global and local caches would certainly be a refinement. It’s not free, though, as platforms differ on where an appropriate place to write a global cache is. And the code has to be able to combine the two (that might be easy or it might not — it’s been too long since I’ve been in that area to remember). Cheers, Jeff. On 23 Jul 2019, at 09:33, Rene Pöschl wrote: Is there a reason why this file is even part of the project directory? I kind of assume it holds the info of all footprints. (If i am misinformed about that then ignore my inquiry.) Meaning for most users will most likely be mostly system libs that can easily change while one does not work on the project for a longer time. Might it be better to have a global cache for the global libs and a local one for the local ones? On 23/07/19 01:03, Seth Hillbrand wrote: Hi Folks, Odd question here but why do we have fp-info-cache? Was there a bug report for these or just speed improvements? On my system, it is the difference between 1 second vs. 3 seconds during the first footprint list load (full standard + personal libraries). Does it make a bigger difference on other systems? I assume so but I was wondering if we have some data here? I'd like to make storing it an option. I've been working on templates recently and keep needing to delete the extra files from the directory (caches should not be valid for templates). Thanks- Seth ___ 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 ___ 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 ___ 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 ___ 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] fp-info-cache question
Could we write the global cache in the user's config directory next to where we write fp-lib-table? If we cache global, we might not need project-based caching. -Seth On 2019-07-23 11:39, Jeff Young wrote: Hi Rene, Separate global and local caches would certainly be a refinement. It’s not free, though, as platforms differ on where an appropriate place to write a global cache is. And the code has to be able to combine the two (that might be easy or it might not — it’s been too long since I’ve been in that area to remember). Cheers, Jeff. On 23 Jul 2019, at 09:33, Rene Pöschl wrote: Is there a reason why this file is even part of the project directory? I kind of assume it holds the info of all footprints. (If i am misinformed about that then ignore my inquiry.) Meaning for most users will most likely be mostly system libs that can easily change while one does not work on the project for a longer time. Might it be better to have a global cache for the global libs and a local one for the local ones? On 23/07/19 01:03, Seth Hillbrand wrote: Hi Folks, Odd question here but why do we have fp-info-cache? Was there a bug report for these or just speed improvements? On my system, it is the difference between 1 second vs. 3 seconds during the first footprint list load (full standard + personal libraries). Does it make a bigger difference on other systems? I assume so but I was wondering if we have some data here? I'd like to make storing it an option. I've been working on templates recently and keep needing to delete the extra files from the directory (caches should not be valid for templates). Thanks- Seth ___ 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 ___ 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 ___ 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 ___ 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] fp-info-cache question
Hi Folks, Odd question here but why do we have fp-info-cache? Was there a bug report for these or just speed improvements? On my system, it is the difference between 1 second vs. 3 seconds during the first footprint list load (full standard + personal libraries). Does it make a bigger difference on other systems? I assume so but I was wondering if we have some data here? I'd like to make storing it an option. I've been working on templates recently and keep needing to delete the extra files from the directory (caches should not be valid for templates). Thanks- Seth ___ 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] MOD_VIRTUAL flag
Hmm... I was thinking that section would not have any reserved values with special meaning to KiCad. That way users can add any data they want there and we don't have to check it for validity before allowing. Is there any reason not to put the flag with the other component-specific flags? On 2019-07-22 15:10, Jeff Young wrote: I was thinking we’d handle it under: https://bugs.launchpad.net/kicad/+bug/980919 On 22 Jul 2019, at 12:53, Seth Hillbrand wrote: Hi Jeff and JP- Should we consider a new flag for board-only items? These would be items that exist on the board but not the schematic. Would be useful for NTPH mounting holes, logos, etc, that get added in pcbnew and shouldn't be removed when updating, even if they are not locked. This could help to separate the locked flag into flags that mean "don't move without warning" and don't delete automatically (as part of [1]) Best- Seth [1] https://bugs.launchpad.net/kicad/+bug/1745627 On 2019-07-22 10:27, Jeff Young wrote: And just to add one more (which was the instance that prompted my question): Logos, certifications, etc.: symbol: no, footprint: yes, virtual: yes. But I see now that we can’t use virtual as a proxy for “don’t treat as ‘extra’ when deleting extra footprints” because if you delete a symbol in one of the symbol:yes cases, then you _do_ want the footprint deleted. Cheers, Jeff. On 22 Jul 2019, at 01:53, Dino Ghilardi wrote: Just few examples (expanding jp's answer): having a schematic symbol, being virtual, having 3d model are not related (you can have any combination of them). As examples: First: a virtual footprint that has a schematic symbol (the answer to your main question). Edge connector: schematic symbol: yes, footprint: yes, virtual: yes (the connector is implemented only with tracks on pcb, without the need of additional components so no need to have it in the BOM). "regular" component, as a Resistor 0805: has schematic symbol, Has a footprint and we want it in BOM. (virtual: no.) Hole without screw (yes, I'm copying jp's example): No schemaitc symbol (or sometimes yes, depending on user's habits: someone likes to have on schematics anything that will be on PCB, including holes): Has a footprint but no items in BOM: (virtual: yes) Hole with screw: Has a footprint but you want a corresponging item in BOM to have the list of screws you need to buy (virtual: no). P.S. (little bit off-topic): Sometimes also virtual components can have 3d shapes (it is not common but it is a way to quick-workaround a 3d view of a more-than-one board assembly: export a step file of the board 1 and assign that as a 3D shape to a connector or a mounting hole of board 2. -very useful to check for mechanical collisions-). Cheers, Dino. - On 22/07/19 09:02, jp charras wrote: Le 22/07/2019 à 06:03, Jeff Young a écrit : This flag tells us that there’s no physical object for a pick-n-place machine. But is it also true that there’s no corresponding symbol in the schematic, or are there some virtual footprints that would have a symbol? What about some microwave elements, for instance? Do they have symbols? "Virtual" footprint means the physical "component" is made only by the drawings on the board. Therefore: - These fp have (usually) no 3D shapes, and the component should be not in BOM. - They of course have a symbol in schematic. In fact any footprint connected to a at least one net *should* have its corresponding symbol in schematic. (I am thinking all footprints should have a corresponding symbol because in many cases these fp need a unique refdes: for instance to import them to a .dsn file) Microwave elements, and edge connector cards are often virtual, if only a drawing is enough to create them. Net ties are virtual and *need* a symbol. However, Microwave elements and Net ties connecting 2 or more different nets are not easy to use in Pcbnew: See this thread https://lists.launchpad.net/kicad-developers/msg24455.html to know what is missing in Pcbnew (the Tomasz's proposal is exactly what is needed in Eeschema/Pcbnew). Mechanical holes can be virtual or not: A mechanical hole with a screw inserted inside it should be not virtual. ___ 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 ___ 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 ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.n
Re: [Kicad-developers] MOD_VIRTUAL flag
Hi Jeff and JP- Should we consider a new flag for board-only items? These would be items that exist on the board but not the schematic. Would be useful for NTPH mounting holes, logos, etc, that get added in pcbnew and shouldn't be removed when updating, even if they are not locked. This could help to separate the locked flag into flags that mean "don't move without warning" and don't delete automatically (as part of [1]) Best- Seth [1] https://bugs.launchpad.net/kicad/+bug/1745627 On 2019-07-22 10:27, Jeff Young wrote: And just to add one more (which was the instance that prompted my question): Logos, certifications, etc.: symbol: no, footprint: yes, virtual: yes. But I see now that we can’t use virtual as a proxy for “don’t treat as ‘extra’ when deleting extra footprints” because if you delete a symbol in one of the symbol:yes cases, then you _do_ want the footprint deleted. Cheers, Jeff. On 22 Jul 2019, at 01:53, Dino Ghilardi wrote: Just few examples (expanding jp's answer): having a schematic symbol, being virtual, having 3d model are not related (you can have any combination of them). As examples: First: a virtual footprint that has a schematic symbol (the answer to your main question). Edge connector: schematic symbol: yes, footprint: yes, virtual: yes (the connector is implemented only with tracks on pcb, without the need of additional components so no need to have it in the BOM). "regular" component, as a Resistor 0805: has schematic symbol, Has a footprint and we want it in BOM. (virtual: no.) Hole without screw (yes, I'm copying jp's example): No schemaitc symbol (or sometimes yes, depending on user's habits: someone likes to have on schematics anything that will be on PCB, including holes): Has a footprint but no items in BOM: (virtual: yes) Hole with screw: Has a footprint but you want a corresponging item in BOM to have the list of screws you need to buy (virtual: no). P.S. (little bit off-topic): Sometimes also virtual components can have 3d shapes (it is not common but it is a way to quick-workaround a 3d view of a more-than-one board assembly: export a step file of the board 1 and assign that as a 3D shape to a connector or a mounting hole of board 2. -very useful to check for mechanical collisions-). Cheers, Dino. - On 22/07/19 09:02, jp charras wrote: Le 22/07/2019 à 06:03, Jeff Young a écrit : This flag tells us that there’s no physical object for a pick-n-place machine. But is it also true that there’s no corresponding symbol in the schematic, or are there some virtual footprints that would have a symbol? What about some microwave elements, for instance? Do they have symbols? "Virtual" footprint means the physical "component" is made only by the drawings on the board. Therefore: - These fp have (usually) no 3D shapes, and the component should be not in BOM. - They of course have a symbol in schematic. In fact any footprint connected to a at least one net *should* have its corresponding symbol in schematic. (I am thinking all footprints should have a corresponding symbol because in many cases these fp need a unique refdes: for instance to import them to a .dsn file) Microwave elements, and edge connector cards are often virtual, if only a drawing is enough to create them. Net ties are virtual and *need* a symbol. However, Microwave elements and Net ties connecting 2 or more different nets are not easy to use in Pcbnew: See this thread https://lists.launchpad.net/kicad-developers/msg24455.html to know what is missing in Pcbnew (the Tomasz's proposal is exactly what is needed in Eeschema/Pcbnew). Mechanical holes can be virtual or not: A mechanical hole with a screw inserted inside it should be not virtual. ___ 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 ___ 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 ___ 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] Adapt CMake 3.0 compatibility code for C++14
On 2019-07-17 13:53, Simon Richter wrote: Hi, On Wed, Jul 17, 2019 at 01:24:26PM -0400, Seth Hillbrand wrote: Any reason to be using the gnu++14 extensions? I thought we were trying to stay with the vanilla c++14. I went for consistency. This code is pretty much unused anyway, since it only handles the very old CMake versions that don't know the properties -- that's why there is a version check in front that causes a fatal error if someone bumps the minimum CMake version without removing the compatibility code. We currently have the respective compiler extensions enabled (both GNU and Visual Studio), because we don't have set( CMAKE_CXX_EXTENSIONS OFF ) The problem is that doing that breaks msys2 builds with wx 3.0, because gcc provides a POSIX-compliant strlen implementation as an extension that becomes unavailable in standards-compliant mode. A wx header decides to redirect missing functions to replacements in the DLL, but building the DLL with extensions enabled means that the function is missing -- so builds with -std=c++14 fail to link with a missing symbol. I dimly remember that this is fixed in wx 3.1 (just provide the CRT functions unconditionally), but I can't find the bug report anymore. Simon Got it. Thanks Simon! Patch is pushed. Best- Seth ___ 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] Adapt CMake 3.0 compatibility code for C++14
Thanks Simon! Not sure how I missed that one. Any reason to be using the gnu++14 extensions? I thought we were trying to stay with the vanilla c++14. -Seth On 2019-07-17 13:11, Simon Richter wrote: --- CMakeLists.txt | 8 1 file changed, 4 insertions(+), 4 deletions(-) ___ 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 ___ 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] Rounded rectangles
Replying to myself here... :) I found the issue. The polygon rounding default was changed for inflate/deflate parameters. This changes many, many things in pcbnew from clearance to gerbers. I've reset the default to rounding as it was before. The option for changing individual calls remains, so we should evaluate each changed call for its requirement before adjusting. Keeping the previous default is probably the safest path for now. Best- Seth On 2019-07-16 12:41, Seth Hillbrand wrote: One of the recent changes seems to have broken the rectangle rounding. Currently, all rounded rectangles are 90° corners for all operations Launchpad bug tracker is down (again), so no bug report atm. -S ___ 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 ___ 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] Failing test: common.holeyPolySet.Collide( VECTOR2I( 11, 11 ), 5 )
Thanks Simon. I pushed a fix for this that partially reverts the commit 1a7cef2950a89959e76dc7b5de259b3b022a7f2e to fix the issue. -Seth On 2019-07-15 06:55, Simon Richter wrote: Hi, we have a failing test, consistent on all tested platforms: [Error] - check common.holeyPolySet.Collide( VECTOR2I( 11, 11 ), 5 ) has failed == [File] - /var/lib/jenkins/workspace/linux-kicad-head/src/qa/common/geometry/test_shape_poly_set_collision.cpp == [Line] - 160 The first build[1] this appeared on has the following changes: Cleanup and commenting. Allow thermal spokes to be same width as minimum width. Add preference for flip axis. Fix a bug in tool activation/deactivation and another illegal Update position before first mouse-move-event. Improve performance, commenting and API of some polygon classes. Simon [1] https://jenkins.simonrichter.eu/job/linux-kicad-head/3325/ ___ 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 ___ 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
