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)
Yes an No…
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
2 Likes
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.
1 Like
How about putting some FPGA stuff in?
[Just trolling]
3 Likes
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.
It’s a balancing act though, it must be unusable for FPGA engineers but still clutter the gui for everyone else.
4 Likes
there are general design rules and devices are divided into complexity classes in each country they differ but the technologies are common for all
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 
1 Like
What do you mean? What are the critical problems which should have been solved?
multi-threading. dependence on outdated libraries and so on… They are all known
Still sweeping generic claims. Can you give details?
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’ve seem the discussion somewhere that it should be lazy loaded(?) in the background after the program is started. Not sure where this was.
But yes, I’m on windows. It takes about 10-20 seconds for me
1 Like
This might be nice but comes with some drawbacks. We’d like to avoid it if we can get acceptable performance on Windows using the other things we’re already planning (single-file and compressed libraries for the official library distribution)
1 Like
Maybe you can give the option to users to choose to load all libraries on startup from the project file. This way you won’t lose time on loading if you just wanted to view the project
1 Like
My opinion is that the pieces and footprints in the library should be divided into two categories, essential and less used.
Essential parts (such as resistors and capacitors) are preloaded and other parts are only loaded from Drive when the user searches.