-
Notifications
You must be signed in to change notification settings - Fork 497
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature request: Extra field without affecting grouping #268
Comments
It's super easy to copy that manf# to all caps in eeschema in Tools -> Edit symbol fields dialog. If you copy paste value to a group it will be set on all components in the group. |
That's true, but I still need to remember to copy them again if I, for example, add a new cap or change the part number (happens often at the final stages of editing a schematic), so it's a bit more cumbersome, and a tiny bit more error prone, than to autopropagate using a script as we do now. This is the workflow we've picked up from KiCost, although we're not using that anymore. I can paste here how we implement something similar in our production BOM export script, but I won't have time to dig that up until a bit later. |
Here's the code we're using, it's really nothing but using a custom comparator for the grouping,
...much later....
where
|
I understand how it can be done but it's obviously a special case and won't work for everyone. Which means it needs an option and there are already lots of options in the plugin. I am hesitant to add something for a feature that has easy workaround. |
I get your point, and of course this would need to be optional... how about, one more checkbox under the "Normalize field name case" checkbox, say "Group by extra fields", defaults to checked so the current behavior remains default? That's probably the minimal UI disruption possible? I could even try to make a fork and implement that myself, you can then choose if you want to merge it back to the mainline? |
I won't merge that because it's too specific for a narrow use case. What I would merge is a system where any field can be chosen to be present in bom and affect grouping or not. This ties into #167. |
Agreed on the need for indication. My other though was indeed to add a checkbox for each row in "Extra fields", called "Group by" or something similar, but I actually expected you'd be less enthusiastic about that since it adds more clutter. The most obvious way to extend that to any field would be to change the "Extra fields" list to "Fields", and just show all fields with the usual ones selected by default. Implementing that does seem like a slightly bigger task, I've only taken a quick look at the code but this looks like the needed changes would be to "config.py" to save the selections, then the UI changes to the dialog box, and finally the implementation in "ibom.py"? |
...and the UI case seems to be the most difficult of these, as adding several checkboxes is apparently not possible with |
You can use wxGrid with some columns set to boolean renderer which draws a checkbox.
Yeah that was the intention. In addition to changes you mentioned also likely javascript code will need tweaks as it expects some fields to be there right now. |
Okay, unfortunately that's probably a bit more work, I'm guessing a few days since I'm not an expert in wx or webdevelopment, than I can take on myself right now. If you ever get around to implementing something like you described, I'll be very interested, but in the meantime I already implemented the simple non-grouping (without options, just hardcoded, but with warning for conflicting fields) for myself. Thanks for your time, though! |
No problem, I'll close this in favor of #167 . |
It would be useful to be able to add an extra field without it affecting the grouping.
The problem with the way it currently works:
Of course, we can just not add the manf# to Extra fields, but then we have to double check the actual part number from somewhere else. Most of the time, footprint + value make that possible to deduce uniquely, but in the end that still generates a small extra chance for mistakes.
The text was updated successfully, but these errors were encountered: