Conversation
Now, we can just run the script itself, and it should run a Generate when clicking OK. We're not too sad if Altium opens the form in non-modal mode. The main point is to detect in which use case we are.
…mat defined by the schema
|
Hey again - just to clarify, I really appreciate your original work here and definitely don’t want to step on any toes... I realize my message might’ve come across a bit blunt - the idea isn’t to hijack the project or anything like that. I’ve just been doing a deep dive and wanted to contribute back before I go off into any custom or incompatible changes. Also, if you have any preferences around licensing, project direction, or how you'd like contributions to happen, I’m very open to aligning with that. I’d love to hear your thoughts. Thanks again for putting this together in the first place - it’s been super helpful! |
|
Wow - give me some time to review :) |
|
Hi! All good — you’ve done a great job. Developing plugins for Altium is a real pain — poor documentation, a terrible IDE, no debugging, and constant crashes. As a result, the code gradually turns into a mess full of endless trial-and-error attempts and heaps of commented-out code “for later” or “just in case.” I’m honestly a bit ashamed of the current state of the code, and you've improved it a lot — thank you. As for the license — I’m not very experienced in that area, but I think it’s best to go with something as permissive as possible, like MIT. I’ll add it to the project ASAP. The direction of the project is simple — to provide people with an open-source iBOM for Altium, and maybe also serve as an example of what Altium scripting can do. There are two main principles: stay compatible with InteractiveHtmlBom and be standalone (i.e., be able to generate HTML even without Python). I even managed to get the project mentioned on the original InteractiveHtmlBom repo, hoping to attract some community — and it looks like it’s working. About the dummy parameters — let me explain why I do it that way. If a function has even one parameter, it doesn’t show up in the “Run Script” list — avoiding that makes the script much easier to use for non-technical users. Since my last pull to the project, I’ve made a number of updates, and I’ve merged them with your pull request — preserving as much of your work as possible. I’ve dropped my custom JSON format and rewrote the JS part so it works with the original JSON schema. This helped remove a lot of duplicate code, plus I added some small improvements — arc, text, drill, nets, first pin, etc. I hope none of that broke anything on your end. Regarding code style — I try to stick with the Delphi code style, since it’s kind of the de facto standard for Pascal. I see you're working on an interesting project — altium-ibom-releaser. Just curious: why are you going with JSON + Python instead of using the HTML output generated by the plugin? P.S. I’ve also been working on a PnP script, since I’m not happy with how Altium’s built-in one works. |
|
@zharovdv Awesome! 🎉 I'll take a closer look at your rewrite tomorrow. Super excited about the missing object types - I was already dreading having to add them next week 😄 And yes, the scripting engine is a total trainwreck, so I completely relate - my first attempts look just as messy as yours used to 😅 Thanks for the clarification with the Dummy variables. I missed that detail where the procedure picker excludes procedures with arguments. Maybe a simple comment somewhere explaining it would be enough to prevent any future overeager refactorer like me to remove them again, haha! MIT sounds great 🙌 Here’s the reasoning behind my hybrid Pascal + Python approach: When I first reviewed your code, I noticed that even though a variant was selected in the Output Job, the generated iBOM didn’t include any components that were actually varied (i.e., alternate parts from our company vault with the same footprint were missing). I tracked this down to the So I concluded that to reliably get complete variant data, I’d have to pull that info from another source. I considered using ODB++, which is probably the most robust option - but due to time constraints and the lack of a good Python parser, I ended up using Altium’s native Pick & Place file instead. That’s why I added the Python transformer as an intermediate step. (That said - maybe I missed something! If your Pascal script can export variants correctly, I’d love to be wrong about this!) Why I plan to use InteractiveHtmlBom as-is: Now that I already have a Python transformer in place, it’s easy to pull in InteractiveHtmlBom as a simple package dependency and call its code directly. Using it unmodified feels like the most sustainable solution in terms of maintenance - especially as it evolves. My thoughts on the HTML/JS files in the Altium project folder: From what I understand, your current approach expects the project to include the HTML/JS template files as part of the repo. That totally works, but it has some drawbacks I’m hoping to solve in
So instead, my plan is for the Pascal script to generate just the generic JSON - with only two files (
In both cases, the goal is to keep the integration minimal and maintainable, so projects can automatically generate iBOMs for all variants without having to trigger a manual update when InteractiveHtmlBom changes. Thanks again for being so open and for merging the changes so cleanly! I’m really glad we found this synergy 🙌 |
|
Yes, maybe it's worth adding a comment in the code about the Dummy parameters. I thought it was a standard practice in the community — or maybe I just convinced myself it was 😄 It's really strange that the variant support didn’t work. I haven’t specifically tested it in this plugin, but I actively use variants in another plugin I wrote for generating PnP and BOM files — and there it works reliably and cleanly. I’ll double-check and fix it if needed. About including HTML/JS in the repository — here's how I usually handle scripts. I have a directory at /home/user/altium/scripts/ where I keep all the scripts I use, each in a single instance. Then I link them to the projects I need. That way, I only have one copy of each script, which makes updates super easy. You might ask: what about collaborative development? There’s a solution — Altium is smart enough to store paths relative to the project file’s location. So if your plugins and projects are placed more or less nearby, and your teammates stick to the same structure, everything transfers smoothly. That said, I’ll think about it — nothing stops us from adding an option to bundle the HTML/JS files inside the plugin itself. That would let us keep everything in one place. |
|
I'll take care of improving the code documentation and will clean up function/variable names a bit more - thanks for pointing me to the Delphi style guide! I'll try to stick to it as best I can. For now, I'll keep working on top of your code and try to stay compatible with the current functionality. I'll also bring my intermediate variant-fixer to a proper release state. And if we find that the Pascal script can indeed handle variants cleanly, I'll be more than happy to throw my workaround away 🫠 A few things that already came up - curious to hear your thoughts:
Let me know what you think - and thanks again for the super open and helpful collaboration! |
P.S. We could also take another look at the Variants — could you describe in more detail what’s not working? What result are you getting, and what are you expecting? |
|
Maybe we should add an option to specify the path to the web directory and the font file? |
|
I just tried Release Manager — and yes, the problem is that it copies the entire project into a new folder, so there's no way to determine the original project path. There are three possible solutions:
|
❤️ Much appreciated!
It's surprisingly useful. Our company uses it to release everything - all docs for all variants - to a mapped network drive. That way, everything is kept together in a nice structure. We don't use release to A365 itself, since we follow a custom version/revision scheme that doesn't integrate well with it.
I can see you've put a lot of effort into generating the HTML directly via Pascal - hats off for getting that working! 🙌
I've actually been working on a fourth option (should be in a previewable state tomorrow) - and I think it could simplify things a lot: I'm building The Pascal script ( Why this could work well:
Curious to hear your thoughts! |
|
I need some time to respond properly. |
|
I've made some updates to bring our approaches closer together.
P.S.:
P.P.S.: The original idea behind my script had three working modes:
P.P.P.S.: Your version is also a valid approach, but I'm still hopeful I can manage with a pure Pascal script, without relying on EXE/Python/etc. I have another complex plugin that heavily uses |
|
Man, you're gold, I'm enjoying this collaboration! Alas, unfortunately, tomorrow is the last day I can work on it. After that, I'm on vacation, won't be working for that company anymore, and won't have access to Altium 🥲. That's why I was in such a rush (sorry for that!). I will review your changes and merge my latest modifications, if time allows! |
|
Maybe we can schedule a brief video call where you show me how you're using it - I'm still not sure if I got 100% the same mental picture. Would love to know. Hit me up at my committer email if you're interested. |
|
I will open a new pull request and add my refactors there, so you get updates on what i'm doing. |
Oh, that's a shame — you gave me a fresh creative spark to get back to working on the plugin again; I had sort of abandoned it. Have a great rest! |
Yeap, I see, on my way. I'm a busy with work at the moment. |
Ok |
2 participants
Hey, I'm working on a rewrite of this project (love your effort by the way!) to eventually support Altium's project releaser with Variants.
In the end, it probably will be a separate project on its own, but on the way - thus far - I have just refactored your code base a lot, and I'd like to contribute this back to you, before I make any incompatible changes.
Work done so far:
Is it okay for you if I make my own project from this point on with your code base as starting point (acknowledging your authorship), because I can't find a license in the project. I suggest releasing it under the MIT license then.
(You will probably see a lot of activity on my end until next week, because I got exactly this time frame to work on it.)
Best, Stefan