What gives you that idea? I’m opposed to spending a long time doing things in a complicated way, and then not having them work out I have no problem with scripting, nor config files, nor with GUIs, nor with CLIs – whatever tool gets the job done for you, is the right one…
However, I think that most people (including me) would just find it easier to position panels in a GUI using a mouse rather than to first draw them out on paper, input coordinates into a script, and then run it to see what happens…
And since KiKit went from just CLI/Scripting to adding a GUI plugin, and looking at the hm-panelizer or gerber-panelizer GUIs, I think that their vision isn’t too divergent from my own.
Be that as it may, I sense that there won’t be a native panelisation tool in KiCad anytime soon, which seems like a shame to me, but I accept that there are a majority of other people with other priorities.
In the end, all I want is a way to make my own panels out of KiCad designs, using free or inexpensive and preferably open source software, and with reasonable effort. If I wanted to pay for Altium it would be possible, but with KiCad I currently don’t have a way that works for all my designs. It’s what the OP was asking about, and it’s my answer.
It depends on one’s interpretation. If the comparison is made with the objective of improving kicad by add features that Altium already has implemented (or talking about planning KiCad’s direction as you say), I think it is fine and very constructive. But if it is just based on determining which software have more or less limitations, is better or worst, preferred or not,… it doesn’t seem fair to me because in one case you don’t have to pay a commercial license and in the other case you do.
I believe that the majority of post correspond to the first one.
I started to make panels with KiKit and I like it very much. However I end up contacting the PCB factory and within a couple of iterations I have the panel solved (*)
For me it is not necessary to integrate the panelization in KiCad at all and I agree to leave this task to dedicated software or to the manufacturing companies as I’ve said.
(*) Just to clarify: I only do this with local representatives of the PCB factory. I have never contacted the mainstream manufacturers (JLC, WAY, etc) directly for this task. I have a hard time getting along with them…
This girl is talking about what was already known 10 years ago. And she says nothing about panelization, for example, of thin boards or flexible boards or boards made of other materials other than fr4. There are many nuances that can damage your equipment or make it impossible to view the technology at all. Such concepts as technological fields or reference marks or the minimum gap between the component and the edge of the board. This is to assert that here is everything you need to know) For a home-based hobbyist who is trying to save on a piece of testolite, this video is probably sufficient)
The question should be… What does Kicad need to succeed, not “but altium does x, why doesn’t kicad”
Likewise that doesn’t mean a capability should be implemented EXACTLY like an alternative eCAD “just because” they do it that way, especially if there is a better way.
When Kicad 1st introduced the declarative constraints engine I knew immediately that was something special because I had suffered through the Cadence/Mentor/Altium waterfall method, a method that /really/ doesn’t scale when you have multiple reference zones where each zone has mixed capabilities… There were naysayers here saying why it isn’t like how Altium does it…
Now if only I could sort out slotting on Gentoo so that I can have v8 and v9.rc0 installed concurrently I could try out Post-V8 New Features and Development News - #62 by Drinausaur and Post-V8 New Features and Development News - #58 by Drinausaur as these will be gamechanging for managing HV routing
I don’t think that’s a totally fair description, some people just expected a nice simple GUI and didn’t understand how powerful the KiCad’s system is and how it also enables a GUI on top of it. Although, if someone doesn’t really want to or can’t learn this system, the KiCad system isn’t usable for them and it’s as good as nothing because no GUI has been made on top of it.
A Gerber viewer is essential to verify that your production Gerber plots make sense before committing to an expensive and time consuming production step. Back in V4 times, bugs and human error were quite common.
Calculator tools are awkward. The best PCB tool is Saturn PCBs, but this is freeware and not shareable.
The transmission line and others have online options of varying accuracy, but online is not always an option.
I’m not questioning the necessity of either kind of tool, just pointing out that these functions are well covered by existing external tools, and KiCad would not need to develop or maintain their own.
This was as an answer to the “prioritization argument” against the panelization tool, but @craftyjon has already answered that point to say that these tools are existing code and don’t cause much maintenance effort.
I understand that to also mean that if these tools did not already exist, the KiCad devs might not choose to develop them again at this point.
Until the problems of 4-5 years ago are fully solved, there is no particular sense in discussing the functions. The problems exist, they are known, any solution without this solution in the form of a plugin or, for example, erasing a piece of code will be a crutch. The crutch is inconvenient with an unclear result. For this reason, the main functionality should be implemented in the main code with minimal dependencies on third-party unstable libraries. This is a fact that is not denied, but also not solved within a reasonable time frame.
Some people complained that our schematics editor relies on coordinates of lines/pins for resolving net connectivity. I see an opportunity to take inspiration from Vivado here
One thing mentioned often here is that symbols and footprints take ages to load and block the main thread. Also if you remember the recent post about the history of KiCad it lists quite a few things in the backend that are still legacy code that have to be reworked.
Additionally things such as no flat hierarchy are hindering other features like the altium importer
I won’t deny that – right after I read this post I opened v9rc to test another thing, and opening the Add Symbol dialog for an empty schematic took 1 minute 20 seconds! This has really annoyed me for several years, especially when I have been more active with KiCad, testing nightly builds and different setups, making changes to library libraries etc. Sometimes about every opening has caused this infuriating lag.
But what would be the solution is a different thing. Multithreading? It has already been said that it’s not as simple as it sounds (and I know that firsthand because I have tried using multithreading, with embarrasing results in publicly released software). Now some modern programmers could say “change to Rust”… Yeah, I also tell everybody to change to Qt instead of Wx… What a simple update…
The loading is already multithreaded. I’m guessing you are on Windows – it has a slower time with this than the other platforms. It will be helped by moving to single-file and compressed libraries.
I have no problem with scripting, nor config files, nor with GUIs, nor with CLIs – whatever tool gets the job done for you, is the right one…
Yeah, I also tell everybody to change to Qt instead of Wx… 
What a simple update…