I noticed that too. Even though I do not like python much *1) it is a pretty platform independent language. Quite a shame people write platform dependent libraries for it in the first place. There are 38 matches for the string “win32” in that 94 line python script.
*1).Two things I especially dislike is it’s whitespace dependency, and that it (most often) just invents a new variable on a simple typo. C compilers catch that instantly. For me that is the difference between 10s of correcting the typo and a recompile, or 10+ minutes of debugging. A third thing is that python seems to attract sloppy people, or at least people who are discouraged by compilers and the many compile time checks they do, while I am the opposite. I make lots of silly mistakes (other topic) and am very glad with a compiler and strict syntax checking that helps me a lot to write correct code.
I think it’s important to bring this conversation back to what @makingdevices did: he identified a missing feature and then built it in the most direct way possible (i.e., manipulate the mouse through Python and grab screens). That illustrates two fundamental qualities of humans: 1) We’re the only things on this planet that can envision something that doesn’t exist and then build it, and 2) We don’t want it to be harder than it has to be.
Notice what he didn’t do:
Download the KiCad source.
Setup a build environment.
Locate the 3D viewer code.
Identify whatever classes, structs, and functions were needed to modify the 3D view.
Create the user interface for specifying the rotations/translations of the PCB.
Even more steps …
A lot of people have probably thought of screen recording the 3D view. Probably at least a few tried to follow the steps to integrate it into KiCad. Obviously none of them made it, possibly because all the obstacles and side issues just make it too costly in time and effort and so they gave up.
But @makingdevices succeeded, maybe because he had a language that hides a lot of details combined with some well-defined interfaces (Python-mouse communication along with the 3D viewer’s rotation and PNG export buttons). It isn’t perfect, but it is accessible so others can look at it and possibly make improvements. How many would do that if they also had to follow the six steps I listed above?
That’s what pains me about the somewhat knee-jerk impulse to integrate every feature into the KiCad monolith: it makes it harder to build new features. And because it’s harder, there are fewer people who can or want to do it. And with fewer people, fewer ideas get built. And with fewer ideas, there will be fewer good ideas because the way to have good ideas is to have a lot of ideas.
Right now, the path for new ideas begins by raising an enhancement issue on Gitlab. Then wait for lightning to strike and maybe one of the developers will take an interest and build it. Or not, and then the idea dies.
So I salute @makingdevices for essentially saying “Imma make this feature using whatever.” We need more of that.
I’m not saying his tool is useless, but unfortunately it is only on win… it is still limited by the ability of 3D viewer to be driven by keys…
I consider this feature an improvement for KiCAD (as a feature included in Altium) and it would be nice to have something natively developed (as I was dreaming in 2017!).
Moreover having some ability to remote the 3D viewer from python would facilitate a way to present a pcb, adding a python plugin.
you know I moved StepUp outside KiCAD because of the lack of internal interest in integrating FreeCAD libs in KiCAD (which would have donate a mechanical kernel to KiCAD)…
But when something is easy to implement internally (as the main developer of the 3D code said) the best approach, IMO, is to build it natively inside the sw.
if we are talking about a professional application, then we need at least 2D integration and a gerber editor without this, displaying pictures does not make sense … if under win64 this is solved by third-party applications, then under Linux they simply do not exist at all … and even if the developers go according to this direction then everything will be limited to win64 …
any add-on for integration is related to the topic … the end-to-end design system tells you what? The world around is much wider, as is electronics design… there are two ways, either you do integration with a third-party application or you do it inside the program itself… in the case of Linux, both of these options are not suitable within kicad… I gave an example for understanding such integration across platforms is not possible
That’s true and it’s obvious to anyone who looks at it. And more people will look at it because they can just pop the code open on Github and scroll through the massive 94-line source file. And the more people who look, the more likely someone will say “I can do that on linux!” Things like that won’t happen if the code is encased in the Monolith and any potential beneficial modifications will have to be done by someone from a much smaller population of core developers.
Yes, you envisioned doing this in 2017. But it never got done, by you or anyone else. It’s worth wondering why we had to wait until 2023 for one lone guy with a handful of Python to do it.
If you’re deep in the guts of something, it always seems easier to do it yourself using all the capabilities you’re already familiar with. And that’s fine, but you then also have to take the sole responsibility for supporting/improving the feature going forward. And that’s the core problem: too many things to do, to few developers. How many feature requests on this forum get replies containing the phrase “… but there are limited developers”. So more developers are needed! Obviously they haven’t been flocking to work on the Monolith, so maybe create more interfaces that give more casual developers an easier/quicker path to feature implementation. But there doesn’t seem to be much enthusiasm for that, so we’re left to rely on guys like @makingdevices who are willing to hack things together.
maybe I didn’t express my idea correctly … just imagine that there was an integration with altim with a solid and, for example, an autocad with an office … what is the use or even an opportunity for Linux users from these functions? And how can developers support these functions inside the program on different platforms? using the altium integration example, there is now a converter, but it is impossible to check the source file for Linux …
If I had acted like you are suggesting, probably the 3d viewer would have less feature than it has now.
Asking as a user is the way to generate a possible solution by an interested developer.
Anyway I quit this debate because now it seems it is centered in what people can say or not
@makingdevices asks for the rotate-and-record feature. He’s told “limited developers but maybe someone will be interested.” He waits, maybe a week, maybe six years, maybe never.
@makingdevices spends a few hours and hacks a solution for himself. Maybe someone else extends it to be more useful. At least there is an imperfect but usable solution.
It’s hard to argue that scenario #1 is better than #2. Since the factors that lead to #1 aren’t getting any better, maybe do something to make #2 easier and more likely. That would also take some pressure off the main developers so they could spend more time fixing problems in the core of KiCad.
I pretty much agree with devbisme.
Having makingdevices’s python script is progress, and maybe he will get a pull request someday from someone who found his script interesting enough to put some time in it and make it platform independent.
It’s the basis of how open source works. You start somewhere, and if anybody else find it interesting for some reason then the code can get modified and / or extended.
Also don’t forget we’re not all code wizards. That script may be his first working program ever that is worth sharing, and then bitching about it that it’s only for windoze is no way to improve his motivation. Note that in my earlier post I blamed the library writers. They should know better and I hold them to higher standards.
open source doesn’t mean working across different platforms, but for developers and users, it’s a pain…even at the plugin level, you can’t parry everything.
Kicad’s 3D-Viewer with Hot-Key setup for Rotation is all I need when working with Kicad. But, I use quite a few STEP files for other projects and when not needing to use FreeCAD, I use OpenSTEPviewer. There are other Viewers… It’s FREE!
I threw it into a Plugin to run from Kicad.
Haven’t yet spent enough time with it but I imagine not having much problem Python coding an efficient One-Click loading section of code - perhaps I’ll make a GUI panel…
Blender allows its own plugins that could work with a 3D format output by KiCad. Blender can also be run as a Python module so you might have a PCBNEW plugin that outputs the 3D file and then calls Blender to do the rotate-and-grab.
For presentation-quality graphics, Blender is and always will be better than KiCad’s internal stuff. That’s Blender’s core competency. Trying to match Blender is a distraction from fixing problems in the core of KiCad.
Thanks to everybody discussing this topic. This is being more interesting that I thought at first sight!.
As I said before, my plan is to improve this ‘alternative solution’ while discussing if this feature is interesting enough to implement as main Kicad software feature. Right now I am on holidays with limited PC access, but the first thing to do is to make some basic documentation and port the code so it will work in Mac, Linux and Windows (Python is cross-platform as you said before), so it should not be hard to do.
Finally, I am afraid that my knowledge in software engineering is not good enough so I can implement this feature into kicad by myself, so having this as a third-party app sound quite reasonable for those who do not have the time or knowledge to use blender or FreeCAD.
Since you mention KiBot, I first thought that the input for Blender was done using a KiBot output, but as far as I can see, PCB2Blender has nothing to do with KiBot.
Also, it’s strange that the creators of PCB2Blender has implemented this as plugins for both KiCad and Blender - normally an easier workflow would be to either add KiCad pcb import to Blender, or add Blender 3d export to KiCad
