-
Notifications
You must be signed in to change notification settings - Fork 8
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
Add footprint Parameter to Kicad Footprint mapping #44
Conversation
@30350n would you be able to prove a working example? And why a JSON field? Also, if we merge this I think this should be an optional which means we would need a switch; and probable another setting which allows you to define which parameter should used as some people might not like 'Package Type' and go rather with something else. Otherwise, I do like the idea. |
Sure! Here's one of my resistors with a Here's the KiCad Category for my Resistors (the bottom two fields are new): And here's what your API returns:
This already exists in the form of your
The JSONField is more or less the part I'm unsure about. It just seemed like the quickest way to add "dictionary" like data to a django model. I'd also prefer something that would be easier to setup and wouldn't require you to write out an actual dictionary in JSON.
It already is optional more or less. If there is not match for a value in the JSON dictionary, it will simply be ignored: footprint = footprint_mapping.get(footprint, footprint) (from here) |
Instead of JSON one could use a new model which holds the template footprints and refer to them from the category using one-to-many rel. This way one could use _contains in an SQL query to find the matching one. Also, takes away the complexity of writing syntax correct JSON. However, I'm unsure if just adding the correct footprint to each part might be less failure prone. @SchrodingersGat any thoughts on that? |
Yeah okay, that's kind of what I figured, but I was unsure how that'd look like in the Admin view, I'll try that, thanks!
Well like I said ... this change doesn't disable that. It just makes it easier for people who already have some kind of footprint parameter setup to use this plugin. Without it, one would have to add "the correct" footprint for all the parts manually. |
If you can implement it so it's easy to use and understand I'm happy to merge it. We should probably also start thinking about some sort of documentation to help people understand what this plugin does. |
This feature in particular is pretty esoteric, so some clear documentation around how it works would be great. |
So let's merge it as is? @30350n would you be able to add a quick description to the README.md file? Once that's done, let's just merge this version. This seems to be the easiest way at the moment, given other ones would require new models. |
Esoteric, but very useful imo 😅
I think I wanna try the other way via an extra model first. If we'd ship this as is and decide to change it later on, migrations are going to be hell. Better to just implement the better solution in the first place ^^ |
@30350n how did you go with the models instead of json? |
Didn't really have time to look into this yet ^^ |
I'm happy to merge this approach. This way we don't have to worry about migrations etc. |
I would really rather not. While it's generally working, it's really not userfriendly at all, especially because you have to manually edit the json everytime you want to make a change. |
Understood |
This is what people want! |
As I mentioned before, I'm happy to merge this version if @30350n is happy with this work. |
Ready for rereview/merging now :) |
Also just added a quick paragraph to the README and fixed it's formatting. |
I'll run it on my dev setup and merge it afterwards if there are no issues. Thanks @30350n |
@30350n I just ran your code and added some suggestions and questions also, would you mind baselining your code so it current. Currently it's not mergeable. |
Uhhh, where exactly? Can't seem to find anything...
Will rebase tomorrow. |
@@ -51,6 +51,35 @@ class Meta: | |||
help_text=_('Default value parameter template for this category, if not specified for an individual part'), | |||
) | |||
|
|||
footprint_parameter_template = models.ForeignKey( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What was your intention with that extra parameter? It confused me a fair bit initially.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's just the existing KICAD_FOOTPRINT_PARAMETER setting, but on a per KiCad category level.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm uncertain about this particular case. We already have the settings parameter in place for that purpose. I can't envision a scenario where the footprint would be stored across multiple parameters instead of just one. It seems like that could become confusing quite rapidly.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Well pretty much exactly for the reason this whole PR exists.
In my case for example, I've got a whole bunch of components in InvenTree already. Some of the (resistors, capacitors, etc.) already have a "Package Type" parameter set, which I can use with the introduced functionality here, to map from said "Package Type" to a KiCad Footprint. But that "Package Type" parameter isn't set for all parts. So for some more specialized parts, like Potentiometers or certain ICs or whatever, I'd prefer to actually just add a "KiCad Footprint" parameter directly, which I can change from the InvenTree UI.
So what I'd do is set the global KICAD_FOOTPRINT_PARAMETER
setting to the "KiCad Footprint" parameter and then override it for certain categories (resistors and capacitors for example) to the "Package Type" parameter.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nothing confusing about that really, it's just a simple override.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah okay that makes sense now.
Would you be able to add a bit more information to the readme about when you would use which way. There are pretty much 3 then now.
Maybe include an example of some sort.
Cheers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
My bad, I didn't press submit. See above! :-) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah, I see, missed that. Why would you need a model for a progress indicator btw? 🤔
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Multiple users import stuff at the same time. Also multi-file upload in the future maybe.
I had crosstalk without it.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Interesting. Still seems like something that should just be stored in a variable, not the database.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes so I thought initially
@@ -51,6 +51,35 @@ class Meta: | |||
help_text=_('Default value parameter template for this category, if not specified for an individual part'), | |||
) | |||
|
|||
footprint_parameter_template = models.ForeignKey( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm uncertain about this particular case. We already have the settings parameter in place for that purpose. I can't envision a scenario where the footprint would be stored across multiple parameters instead of just one. It seems like that could become confusing quite rapidly.
Thanks for merging! :) |
Thanks for taking your time to make this plugin better. |
I just noticed it created an additional migration file on my production server but not in my dev server (_008). Have you seen similar behaviour? |
Did you migrate with a previous version of this PR on it before? |
Addressed in #66 |
Ah! That makes sense, sorry about that ^^ |
No Biggi! It just confused me a lot. |
Okay, here's another feature that probably requires some discussion though 😅
The idea is to add a
footprint_parameter_mapping
field, which acts as a dictionary which maps values from the footprint parameter field to actual KiCad footprint names. I like this, because it enables me to have a"Package Type"
field which is for example set to values like0805
,0603
, etc. (for resistors) which can then be mapped toResistor_SMD:R_0805_2012Metric
,Resistor_SMD:R_0603_1608Metric
, etc.In my case this is even more useful, because I don't have to set the
Package Type
parameter manually, but it gets automatically set by my InvenTree Part Import CLI.What I don't like about this current implementation I have, is the JSONField really ... It's not really that nice to use.