Highlight groups each assigned unique colors #533
Conversation
…d a different color of the rainbow.
|
Oh, right, I forgot to mention my apologies for editing the wx file directly. I don't know what wxlayouts or whatever it was called is, but my changes are really simple to begin with and so I figured you might be willing to amend whatever that the thing is that is meant to generate that file. I think I only had to add 2 lines to dialogue_base.py. Sorry about that. I hope that it's not too much trouble. Also, feel free to just discard the idea if you aren't a fan. I already have it for my own use, obviously, so I just submitted this in case you found it as useful as me. |
|
I understand the idea behind this but it seems to target a very limited use case. |
|
I'm not claiming anything to the contrary. Of course, there are solutions, and I see where some of them could be. I'd expend the time and effort to address them if you were interested. But ultimately, it might not be a feature that is useful beyond smaller projects. I guess I question how that makes it less useful to have available anyways. There are stages to learning. It was helpful to me. I really appreciate your repository, by the way. I meant to tell you that. It's incredible what you have made. Smaller projects are how everyone gets started. As a person who has seen many walls and came up with ways on my own to climb them, I see the biggest problem in a lot of technical fields to be the "barrier-to-entry." Usually, this is synonymous with "cost-to-entry" as seen with the tools for performing artists. Other times it's a complexity barrier. I understand that beginners can be annoying to have to deal with. I've been a person on both ends of that spectrum and know full well that just having been a beginner does not make dealing with one less annoying. I am not arguing that this feature will serve the majority of users. Because the majority of the users of programs like these are not beginners. Beginners likely find KiCad overwhelming. It took me several years after I first tried to use it before I ever tried to use it again. I can only say that for myself and the people like myself who are at the beginning, features like this might make what was previously quite difficult to stomach a bit easier. Those who don't need that might see it as meaningless. Training wheels are silly for someone who knows how ride a bicycle. And you don't need training wheels to learn how to ride one. I suppose I just feel that sometimes a tool you only need for a brief period before you outgrow it can still be impactful. If you think it needs work but are interested in the idea generally, I'll work to bring it to your standards. Ultimately, I have what I need, if you don't think it's worth the time, I already did what I thought I should, and I accept that I may be delusional as a person lacking real experience. If that is the case, my apologies for wasting your time. Either way, I'm grateful that you made this. I find it incredibly useful. Thank you. |
|
I agree with everything you said and I don't think it's a waste of my or anyone's time to review/prepare such pull requests. Especially if you have solved a real need for yourself - that's great, perfectly shows the power of open source. But as a maintainer I have to consider all use cases and if a feature is not just not useful but can actively lead to mistakes in the common use case (i.e. mistaking different groups to be the same when they have same color) I can not merge it in this state.
I thought about it and none of the options I came up with are good:
Another issue here is that the rainbow colors clash with other existing coloring features: highlight (red), checkbox marks (green/yellow). I personally don't see a good way forward but if you have any ideas I'm all ears. |
|
So, my idea was this: Instead of simply assigning the colors in order of the groups, I made it two separate ranges, inspired by spectroscropes. The range is automatic, the highest and lowest values of resistor (and capacitor, they each get their own 2 color ranges) in your BOM become the floor and ceiling for the range. There's a 2 color "thermometer" for each. Capacitors and resistors are each colored somewhere between the gradient of the floor and ceiling. Of course, this logic might need a bit of adjusting because linear spacing might not be ideal for boards with clusters of similarly valued components but which have a few others that set the floor/ceiling or both too far away and make the majority of the components you'd like to be able to differentiate all smear together. I've got a couple of ideas to solve that issue, different spacing functions (lin/log) or perhaps some form of "difference between nearest valued groups on either side" multiplier. I'll play around with these ideas and see if anything ends up being the clear winner. I appreciate what you said. Thank you for taking your time. I get what you mean about your responsibility as a maintainer. That makes perfect sense. I won't be disappointed if you don't end up incorporating this, I enjoy the work in and of itself and either way, and I get the same personal benefit from doing it. It is a bit difficult to decide what to do. There's lot's of things that could be done, but I am starting to see where every gained centimeter of functionality and configurability adds up to a quickly cumbersome amount of parameters. By the time a feature's usefulness can be realized, the complexity of the additional choices themselves may have grown to be a larger impedance than not presenting these choices at all. Too many choices is a burden to the uninitiated of the highest order. I see the problem better now. I will take all of this into consideration. I'm wondering if an alternative path might be better here. I have no idea how the plugin space of KiCad works. I assume that they all are within the same venv and share a binary, but I have no idea how they might interact with each other. Do they all share a namespace/ can two functions be defined with the same name in two different plugins? What I am getting at is, maybe it would be better, if this is possible, for me to package this as its own additional plugin that can be separately installed so that there's no need to worry about the burden on the main repo. It could just be an opt-in that way and I could go to town with it ;D |
|
KiCad currently has 2 APIs, old style, which this plugin uses at the moment and new, IPC api. Old api will go away at some point, likely kicad v11. Old api plugins all exist within the same system environment, not virtualenv. New ones will have separate venvs. But no matter the API, all plugins need to have distinct python module names. As long as that is true you shouldn't worry about any clashes of names because module names create distinct namespaces. So if you make your fork just name it "RainbowBom" or something else, rename the python module accordingly and you should be good. That said, I should mention some long term plans for InteractiveHtmlBom: in version 3 I would like to switch to typescript and build a modular system where anyone will be able to modify or add their own web template. Users would then be able to chose the web template at bom generation time. When that system is implemented your rainbow bom could just be one of the optional templates among others like "draw one group per page" bom and "draw bom with company logo" etc. |
|
Oh, right on. Thanks for that info. I'd be willing to do some of that work if you want. I know that's probably something you'd rather flesh out yourself a bit first though. Well, regardless, I'm still gonna submit one more pull request once I finish this. I tried everything I described above already... no dice. As soon as situations like 10uF cap + 10pF cap on the same board (which is pretty much every board with an xtal, of course) occur, now the 4.7uF cap is the same color as the 10uF one if spaced logarithmically, for example, but different when linear... but then the 0.1nF cap is the same color as the 10pF cap ;D etc... and even if those things were not true, it was just not going to work, not a even close. However, I had one more idea after that I came up with that I'm going to try. I think this one could work. This has turned out to be pretty interesting problem to work on, more nuanced than I had anticipated. Inspired by the color coded lines of resistors and the float-like numbering system for capacitors. You'll see what I mean in a bit. |
Okay, here it is. I think as far as this idea goes, this is the ideal solution. I don't think I would pull this into the main repo if I was you. But I am at least happy to say I have seen this concept through and I feel like this is the best possible solution, or, the best general route, at least. My goal was to have visually differentiable items. That is achieved, and now it is scalable and entirely literal and the color coding is clear and meaningful as it is now a digital encoding rather than an analog one. 
See: colors_readme.html for details on how the color coding/decoding works. |
2 participants
The purpose of this, for me, was to be able to print of a single page of paper with every line group color coded and each group of components highlighted by the same color. It turns the build process into an almost "paint by color code" sort of experience. It can also a good way to validate you are looking at the correct value/label.
RP2350A QFN-60 Minimal Design Example BOM.pdf
