There seems to be a major misunderstanding here, there is no need to use hierarchical pins. You can create a flat, multi-sheet schematic, using global labels.The top level sheet can be the container for other sheets.
I think if people are going to request new features, they should at least get to know what can do done currently, instead of jumping to “KiCad is unusable without feature X”. On a practica sidel, it usually takes several years to get major new features so in the meantime you are going to have to get used it.
Yes, you can use global pins, but this is also really just a workaround. This would work fine in a simple case where you have, for example, only one schematic that you want to divide into two or three pages. Where it becomes problematic is if your design is more complex and has desired hierarchy as well. For example, if you have two schematics at the top level of hierarchy because the hierarchy makes sense for them, and each one of those two schematics is itself composed of two schematics that are being used where extra pages would make more sense, then you will have to plan your global signal names very carefully in order to avoid unintended shorts, etc. Again, it’s not impossible, just cumbersome and unnecessary if you could simply enlarge a schematic by adding a “local” second page.
Despite being a new user of KiCad, I have read through the documentation and am aware of global connectors and how they work, but I still view it more as a workaround and not the best ultimate solution. Just my humble opinion, which may well be different than others.
And sure, sometimes new features take a while to implement, or maybe they are lower priority than some other new features. That’s fine, I don’t see anyone insisting that this be done by tomorrow, just that some people feel it is a better long term solution. It would be adding a methodology that works better for some people and designs without taking away any of the existing methodologies.
my 2 x A4 is 2 A4 page horizontally aligned… for me it is much easier to manage when designing
(2x A4 horizontal -> h=210, w=2x297; 2x A4 vertical -> A3 -> h=297, w=420)
I don’t like A4 vertical (I don’t use the monitor rotated vertically, though I could) …
I use mostly A3 unless it’s a simple schematic. A3 printed on A4 is still quite readable but it’s nicer in color on A3. But I can also use A2 and print to A3.
But being able to print A3 to two A4 pages etc. would be a nice feature.
This is even worse than needing careful planning and having accidental shorts. I’ll go back to my server motherboard schematic example again. Consider 4 channels of DDR memory w/ 2DIMM/channel. If you have gone down the path of using global signals, you are left with a single choice: make 4 different hierarchical blocks just so you can rename each net not to short to the other channels. It completely negates the use of hierarchical blocks in the first place.
I’ve suggested a version of this approach in the feature request. I would like to have multiple title blocks and automated handling of this “workaround,” though. I think this is the fastest path to implementing the intent of this feature without ripping up the underlying architecture.
I am getting the sense the developers are not interested in this feature. May be someone with key developers’ ears can respond. I suspect this proposal doesn’t match the developers’ vision of how this application should work. I find that odd; this is a very basic need for a schematic capture application. Again, I accept that I’ve been tainted by the 15 years of using commercial ECAD applications. However, after over a year of discussing this topic, nobody has been able to propose an acceptable and scalable way to use KiCad with a big design. The current implementation can barely capture an RPi hat; it just doesn’t scale well.
Sorry; I’m contributing as an experienced user, not a developer. About option #2: who is taking requests? CERN is understandably not interested in matching donations to projects.
Yes, I find using unsourced numbers always makes me uneasy, even if only used for rhetorical purposes. I don’t know how many KiCad users there are, I think recently the devs started count downloads, I don’t know if those figures have been published anywhere. I guess the number runs into several thousands, let’s say 10,000.
Judging the number of users interested in a particular feature can be gauged from the bug tracker, the number of users saying “this affects me” for this particular feature is 6.
Therefore that would give 0.06%, which is where 0.1% came from. Of course, that is only a rough estimate, it could be quite low/high in either direction.
It’s only possible to guess how many users have looked at KiCad and rejected it as unsuitable, some sort of survey would be needed to get reliable numbers. Anecdotally, I guess the number of posts I have seen by people saying such things is quite low, maybe 10.
It would take you a couple of minutes, and no particular skill.
But that is the funny thing. People are quite happy to discuss what features they want implemented, to the point of empty ultimatums “I won’t use KiCad unless you implement this feature!”. They effectively ask/demand that a developer volunteers many days or weeks of their time, in a quite skilled task, yet when it comes to spending a few minutes of their own time… that is too much to ask.
This “participation inequality” is also known as the 1% rule.
I guess this reflects the two adages, “talk is cheap”, it doesn’t cost anything to ask for free beer, and “time is money” there is a real cost to people’s time (even if just opportunity cost), and people are reluctant to give it away unless highly motivated or subsidized by some other activity.
If registering an account is a sufficient bar to people requesting features, I think their opinions should not be counted in the stats.
