Re: [Kicad-developers] 6.0 Zone filling differences
Memory is the second thing to go as one ages. I can't remember what the first one is. From: "Jeff Young" To: "jp charras" Cc: "KiCad Developers" Sent: Thursday, June 20, 2019 2:46:58 PM Subject: Re: [Kicad-developers] 6.0 Zone filling differences Wow. That’s sobering. I wrote the board outline clearance changes…. Age sucks. On 20 Jun 2019, at 19:04, jp charras < [ mailto:jp.char...@wanadoo.fr | jp.char...@wanadoo.fr ] > wrote: Le 20/06/2019 à 19:24, Jeff Young a écrit : BQ_BEGIN I believe we now have a warning, but I can’t remember what change it was for. I thought it was for the outline changes, but from what I can find on the mailing list archive it looks like we were satisfied that one wouldn’t change anything. So remind me what the warning is for? AFAIK, it is for board outline clearance change (taking in accounf or not the edge cut graphic items thickness, if I correctly remember). Zone outline changes (only activated if the kicad_advanced "ForceThickZones=0" option enables it), do not need any warning. BQ_BEGIN The reason behind this request is that I have a new fill algorithm which fixes a long-standing bug regarding one pad’s thermal ring knocking out another pad’s thermal spoke. It also allows thermal spokes on custom pad shapes (and would allow us to support custom number of spokes if we wished). While this should only change zone fills which would have been considered errors in the past, it nevertheless changes them. What’s the prescription for that? Cheers, Jeff. BQ_END -- Jean-Pierre CHARRAS ___ Mailing list: [ https://launchpad.net/~kicad-developers | https://launchpad.net/~kicad-developers ] Post to : [ mailto:kicad-developers@lists.launchpad.net | kicad-developers@lists.launchpad.net ] Unsubscribe : [ https://launchpad.net/~kicad-developers | https://launchpad.net/~kicad-developers ] More help : [ https://help.launchpad.net/ListHelp | https://help.launchpad.net/ListHelp ] BQ_END ___ 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] Ratsnest options
For myself, I see no value to having the Ratsnest on/off in the View menu or in Preferences. Having it in the left toolbar as well as the Layers widget is duplicative but convenient. What would seriously reduce my use of the Ratsnest show/hide function is the ability to limit what nets appear in the ratsnest. I'd guess about 1/4th to 1/3rd of the ratsnest in my designs is GND. These eventually get connected to internal planes through vias, and seeing these airwires all over the place is just visual noise. Other big offenders are the various power nets (+3V3, +1V2, etc.) which I'd often prefer to hide. Eagle supports showing/hiding nets by name via the command line, and KiCad needs a similar capability. I seem to recall this being on the roadmap though I could be mistaken. Thinking it through a bit more, it might be more valuable to allow hiding/showing by net class rather than by name. This would make it easier to navigate in a GUI as there would be fewer net classes than nets, and this would group similar nets together. -Reece From: "Jeff Young" To: "Wayne Stambaugh" Cc: "KiCad Developers" Sent: Thursday, June 13, 2019 10:26:38 AM Subject: Re: [Kicad-developers] Ratsnest options So I’ll be the contrary one. First, I do agree with getting the number of access points down. However, I find myself turning the ratsnest on and off a lot. And the toolbar is /much/ easier than the layers palette for that. As far as Preferences, I agree that it’s the right place for curved/straight (well, actually I’d be inclined to just offer curved, but I already lost that fight). But why have shown/not shown in preferences? And for that matter units and coordinates. These aren’t really set-and-forget types of things, and the options toolbar is both easier to access and more visible for inspection. So how about removing in/mm and polar/cartesian from Preferences (and leaving them and ratsnest on/off in the options toolbar), rather than moving ratsnest on/off to Preferences? Cheers, Jeff. On 13 Jun 2019, at 14:47, Wayne Stambaugh < [ mailto:stambau...@gmail.com | stambau...@gmail.com ] > wrote: On 6/13/19 9:35 AM, Seth Hillbrand wrote: BQ_BEGIN On 2019-06-12 22:50, Jon Evans wrote: BQ_BEGIN I like that set of options. It fits in to my plan of absorbing as much as possible from the left toolbar into the layer widget as part of my overhaul of that part of the UI. I also think it would be totally fine to have it *only* in the layer widget, because we don't duplicate the other object visibility controls in Preferences. I like this even better. Single location, placed with all view options. Anyone have objections to this idea? BQ_BEGIN The "Show ratsnest with curved lines" checkbox fits in to Preferences (and not the left toolbar) in my mind, because it seems like a "set and forget" kind of setting, not one that I would toggle on and off all the time while I'm working on a board (but maybe others disagree??) BQ_END I tend to agree with this as well. I've placed it in the preferences for now and I think removing it from the View menu and the left toolbar is a good idea. Any objections to this idea? -S BQ_END I don't have an issue with either of these. Wayne ___ Mailing list: [ https://launchpad.net/~kicad-developers | https://launchpad.net/~kicad-developers ] Post to : [ mailto:kicad-developers@lists.launchpad.net | kicad-developers@lists.launchpad.net ] Unsubscribe : [ https://launchpad.net/~kicad-developers | https://launchpad.net/~kicad-developers ] More help : [ https://help.launchpad.net/ListHelp | https://help.launchpad.net/ListHelp ] BQ_END ___ 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 set: Display Origin Transforms rebase
- On May 26, 2019, at 10:53 AM, Seth Hillbrand wrote: > Hi Reece- > Apologies for the double-tap here. I see I miss-read your intention in > a couple of places! Sorry about that. I'll try to clean up my comments > below. > I also noticed a few other bits and knobs that would be good to clean in > the final patchset. Let me know if you'd like a hand with any of the > suggestions! Suggestions are always good. The more eyes on this now, the fewer complaints we'll have when end-users get it. > 1) I see that this is intended to only be pcbnew. I was thrown by the > changes to GetSelectMenuText() in the other applications but if I'm > reading it correctly, that is groundwork for future patches, correct? I'd originally intended to limit the changes to pcbnew. Then it was suggested that the Footprint editor really should get the same treatment, followed by people such as yourself saying "what about eeschema?" And some things are common across different apps in ways I did not expect; some of the pcbnew DRC code is used by the eeschema ERC. GetMsgPanelInfo() and GetSelectMenuText() are declared in EDA_ITEM. To ensure consistency across all uses I changed the declarations in EDA_ITEM, which required the change to ripple throughout all applications. I've already started promising follow-up patches to the Footprint editor. GerbView needs them too. If we can agree on look-and-feel, I suspect eeschema and the symbol editor will follow. I do NOT want to hold up these patches waiting on other apps or we'll never break the continuous rebase cycle. > 2) The headers in your new files in 0004 seem to keep the copyrights > from the original files. The copyright on the file itself should not > extend backwards from the creation date, so any files you create should > just be (C) 2019. > 3) Patch 0011 has tabs instead of spaces in a couple places. Oh frell. If Wayne doesn't chime in saying he's about to merge this patch set I'll probably squash these fixes and issue yet another full patch set. > 4) In UNIT_BINDER (not UNIT_HELPER -- my mistake below), you pass the > transform as the last parameter but the data is stored in > PCB_BASE_FRAME, which is also passed as the first parameter in pcbnew. > I think we should get this in a similar manner to m_eval in the > UNIT_BINDER constructor. This would require moving the base definition > of the origin transform class to EDA_DRAW_FRAME from PCB_BASE_FRAME. > But I don't think that there's anything pcb-specific about offset/sign > transform, so moving it to the shared class should not be problematic. I think I addressed in my previous email why each instantiation of UNIT_BINDER needs to be given a parameter identifying the required transform. Originally, the origin transform classes had specific knowledge of how to fetch the user-selected origin. I expected this to be different for eeschema than for pcbnew, as the eeschema implementation might need to calculate the coordinates of the user-selected origin corner, while the pcbnew implementation chooses from page, aux, or grid origins. Much later I factored out this code and put it in PCB_BASE_FRAME. With that done what remains as pcbnew-specific in PCB_ORIGIN_TRANSFORMS is the axis inversion selections. It's still handy in certain circumstances to have null origin transform objects. Specifically, there are places in the code where diagnostic data is reported in millimeters, not subject to user-selected units conversion. I've intentionally chosen to use null origin transforms in these places so the diagnostic data isn't subject to user-selected origin transforms either. -Reece ___ Mailing list: https://launchpad.net/~kicad-developers Post to : kicad-developers@lists.launchpad.net Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
Re: [Kicad-developers] Patch set: Display Origin Transforms rebase
> Hi Reece- > I've had a chance to test this a bit. It works really nicely. Thanks > for the good idea here. Thanks! Just a classic case of "This annoys me so much that I'm going to fix it". > I only noticed one spot where it wasn't transformed so far: the > Measurement tool. When used, it displays a sign with the distance, > which doesn't match the increasing/decreasing convention. Thanks. I'm not surprised that I've missed a couple of things. I'll put it on my list of things to fix. I'm an electronics hobbyist and I've only done a limited amount with KiCad. I've learned a lot about KiCad features just trying to chase down how to activate code I've changed and I'm still finding stuff I didn't know about. > The second part is mostly a question. Where do I set this in Eeschema > and page layout? The setting is in the panel under pcbnew, so I would > assume it is a per-application process. However, there is no other > application that has that panel for setting. Right now the answer is "you don't." I wanted to fix pcbnew because I needed to place components and features in specific locations and having the coordinate origin at the corner of an arbitrary paper drawing made this difficult. My initial patch for v4 changed only the cursor position display in the status bar to be relative to the Grid origin, and later the Aux origin when that became a problem. This was hard-coded and didn't flip the sign of the Y axis. The patches I've submitted are the logical outgrowth of that. Schematic entry, however, doesn't really depend on having symbols in specific locations, as long as the representation is clear to the user. Having a page-oriented coordinate display origin was acceptable to me, and the negative Y axis didn't bother me enough to make me change it. From a code perspective, while eeschema has Grid and Aux origins internally I'm not aware of any means in the UI to set them. > I don't have a strong opinion on whether this should be a KiCad-wide > preference or not. I can't imagine someone wanting to set it one way in > Eeschema and another in pcbnew. If that was your intention, the panel > should be at the top level rather than under pcbnew. If it wasn't, can > you give some more insight into why it would be good to split between > the applications? I have pondered what extending origin transforms to eeschema would look like. I'm not sure I see the value in allowing the setting of arbitrary origins on a schematic. One thought I had was to give the user the option of setting the display origin to one of the four page corners. Selecting upper-left would give the current behavior. Selecting either lower corner would invert the Y axis, and selecting either right corner would invert the X axis. While this could be easily implemented using the framework my current patch set provides, it's quite different from the options needed in pcbnew. Just this week I discovered the Page Layout editor has a selection box for page corners. I haven't had time to look at what this does yet. > Lastly, and this is a bit fundamental, I have reservations about passing > this parameter around when it is not needed. This is more of a C-style > convention. Where functions inherit the frame with the preference, that > should be used by a Get() method rather than passing down in a parameter > chain. Trust me, I'm not excited about passing the ORIGIN_TRANSFORMS reference as a parameter. The patch files that do nothing except add this parameter to the GetMsgPanelInfo() and GetSelectMenuText() methods are the two biggest in the set, at 1673 and 1488 lines respectively. The patch files that contain code to actually use this parameter are far smaller, at 96 and 214 lines, and I kept these patches separated intentionally. I was hoping to maintain the same separation for DRC-related changes but that just got too messy. The problem is that the classes that perform the display formatting are part of the hierarchy that implement the board or schematic, which is separate from the class hierarchy that implements the board and schematic editors. The board editor has a pointer to the board but there's no link the other way, and the ORIGIN_TRANSFORMS classes are instantiated in the editor. There used to be a global variable called "g_UserUnit" that indicated the user's preferred display units, but about this time last year Jeff Young replaced it with a parameter passed into the formatting methods. After spending several evenings trying to figure out a better way I decided he might know something I didn't about the structure of KiCad and decided to follow suit. If you want to suggest a better way to do it, I'm all ears. > In some cases (UNIT_HELPER), this should either be incorporated into > UNIT_HELPER or written as a class that inherits UNIT_HELPER. The class > then gets the current setting (as Unit helper does with the units) and > applies it in one place only. The specific problem
Re: [Kicad-developers] Patch set: Display Origin Transforms
Wayne, Thanks for the feedback. Re the header guards: It's common in my experience to define include/exclude type symbols with a non-zero numeric value. This avoids problems when someone writes "#if SYMBOL" rather than the intended "#ifdef SYMBOL", as a preprocessor symbol with no value evaluates to zero in this context. The majority, though certainly not all, of the include files in /usr/include follow this convention for this very reason. I'll get you a patch to address the "const" parameters and your other comments as soon as I get a chance. A patch for "Move Exactly" and Bezier will follow in a few days. -Reece From: "Wayne Stambaugh" To: "KiCad Developers" Sent: Tuesday, May 21, 2019 10:21:10 AM Subject: Re: [Kicad-developers] Patch set: Display Origin Transforms Hey Reece, I tested your patch set and everything seems to work as advertised. I have a few minor comments: The ORIGIN_TRANSFORMS references should be passed as const in all places where they are used internally by another object that doesn't modify them. It's not necessary to add '1' to the header compile guards. AFAIK, none of the other header files do this. I'm fine if these fixes are implemented in a separate patch. I'm fine with merging this patch set as long as there are no objections. I answered some of your questions in-line below. On 5/19/19 10:13 PM, Reece R. Pollack wrote: > I've attached a Zip file containing 11 patches. These implement the > Origin Transforms feature I've been talking about since KiCon. They > should apply cleanly to the master branch at this commit (currently HEAD): > > 9d56102 Prevent unannotated components from driving connectivity > > In summary, this adds Pcbnew user preferences that allow the user to > select the origin from which absolute coordinates are displayed and > entered. The supported origins are the Page Origin, the Auxiliary > Origin, and the Grid Origin. If the user preference has not been set the > default is Page Origin, which looks just like what we have now. > > Additionally, two other Pcbnew user preferences are added to allow the > user to select which way the X and Y axes increase: Left or Right for > the X axis, and Up or Down for the Y axis. If the user preference has > not been set the default is X Right and Y Down, which again looks just > like what we have now. > > I added a new panel to the Pcbnew "Preferences" dialog called "Origins & > Axes" to allow the user to change these options. I did not add any > toolbar icons as I expect these will be "set and forget" options for > most users. > > These patches do not alter the content of the board file, nor do they > change the internal representation of coordinates. The user can change > preferences without causing revision-managed data churn. The only affect > is how the user sees and enters coordinate values. > > My intent has been to implement these transforms only in Pcbnew, but the > changes to common data structures necessarily affect all KiCad > applications. Thus support for display origin and axis shifts is latent > in the Footprint Editor, GerbView, Eeschema, and the Symbol Editor, and > can be implemented with minimal effort. However, at this point there > should be no user-visible changes in any of these applications. > > Some notes: > > 1. The new file "origin_transform.cpp" is currently in common/widgets/ > because that's where unit_binder.cpp was located. It might ought to > be in common/ instead. Should be in common. It's not really a widget object. > 2. I believe I've addressed all user-visible Pcbnew displays and dialog > boxes other than the Move Exactly dialog. If I missed something > else, let me know. > 3. I haven't decided how the "Move Exactly" dialog should work yet; I > think it needs axis orientation support but not origin translation. > I'd be happy to get feedback before I code a patch for this. It probably should be implemented in the move exactly dialog for absolution positions. > 4. I did not touch the Bezier coordinates because it appears this is > not fully implemented in Pcbnew and I couldn't figure out how I > would test such changes. I thought we did go live with this recently so Bezier coordinates will need to be supported unless this was only in the footprint editor. > 5. I'm willing to make a pass through the code to unify the name of the > Auxiliary Origin once there is a consensus on what to call it. By auxiliary origin, I'm assuming you mean the place and drill origin in pcbnew. If so, the latter is more descriptive. Auxiliary origin is not very descriptive. > 6. Patching the file containing the list of developers to add my name > felt kinda presumptuous. I'd be happy if these patches constitutes > cause to do so. I will do that once your patches are merged. > 7. Would someone send Jeff Young on holiday for a week or two? I'm > getting burned out just trying to keep these patches
[Kicad-developers] A consistent name for the Aux Origin?
I just posted this in the KiCad "Software" forum for comment, but ultimately this is a dev question. In Pcbnew, you can place what is known internally as the “Aux Origin”. Thus far the only use for this has been to set the origin for generating Gerber files. The user interface doesn’t name this point consistently: * The Pcbnew docs call this the “auxillary origin”, and describes setting the “coordinates origin” * The toolbar icon tooltip calls it the “auxillary axis origin” * The “Generate Drill Files” dialog calls it the “auxillary axis” * The “Place” menu calls it the “Drill and Place Offset” * The “Move Item” dialog calls it the “Drill/Place Origin” * The (new, unmerged) v6 preferences dialog currently calls it the “Aux Origin” With the changes in Pcbnew for v6, we’ll be able to make this the origin for displayed coordinates when doing layout. “Drill and Place” doesn’t seem like a good description for this point. I’d lean toward calling it the “Coordinate Origin” everywhere, except for one thing: the v6 preferences dialog allows the user to choose the origin for displayed coordinates as one of the Page Origin, the Aux Origin, or the Grid Origin. Suggestions? Thoughts? ___ 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] ERC / DRC user survey
My biggest gripe is the inability to import a DRC configuration from a PCB fab company. Many fabs provide Eagle DRC files customized to their various offerings. With KiCad I either have to customize each project or create template files before I start a project. If I want to run a DRC using another fab's specs I have to change the board manually and then potentially change it back. I should be able to load a DRC spec by clicking a "Load" button and giving a file name. I should be able to save a customized DRC spec just as easily. -Reece From: "Jon Evans" To: "KiCad Developers" Sent: Thursday, May 2, 2019 12:54:47 PM Subject: [Kicad-developers] ERC / DRC user survey Hi all, The development team would like feedback from users on the ERC and DRC functionality of KiCad. We'd like to know what KiCad gets right, and what features are missing that you need. The data from this anonymous survey will help us prioritize development efforts related to ERC and DRC. While we make no promises about whether or when any particular feature will be implemented, we will make our best effort to include user feedback in our specifications for the ERC and DRC upgrades that are planned for KiCad 6.0 Here's the survey link: [ https://forms.gle/RgrSwvgfGZGr2zJH9 | https://forms.gle/RgrSwvgfGZGr2zJH9 ] Thanks for your help, Jon ___ 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
