As mentioned before, I come from Eagle, where this was possible and very simple (2 small files for any project, one “.sch” and one “.brd” – that’s all). As a user I can’t care so much about all the technical details/what’s under the hood/programming problems/it should just work on a daily basis…
It’s not so much that I dislike the idea, it’s that your idea breaks a supported workflow without providing much benefit (to me) 
without any particular reason
As has been explained, there is a good reason. It doesn’t align with your usecase, but the reason exists all the same.
“As has been explained, there is a good reason. It doesn’t align with your usecase, but the reason exists all the same.”
As has been explained from me also, see this as “we have a possibility to use it”, not “we’re all forced to use it”. Your old flow, your old fashioned way from the 90’s, can still continue 
…
@TheSwede
Just to give you some personal backup:
I came from eagle too, I fully understand your POV, your are not alone!
1 Like
Thanks, and yes it’s possible to get used of almost any software behaviour, but when opinions comes up why not say it. It’s not impossible some opinions could be good, maybe someone else never just thought about it that way…
In Eagle is it not possible to have multiple schematic sheets, or to share these sheets between multiple projects?
jon, I don’t think I understand the question.
You say that in Eagle this is “very simple (2 small files for any project, one “.sch” and one “.brd” – that’s all)”
The complexity in KiCad comes from the fact that you can easily have multiple schematic files, and reference them from multiple projects. Does Eagle not have this functionality?
In Eagle you do whatever you want, add how many sheets as you want, then save the project – at any time … (.sch & .brd) file with whatever name you want – boom! – All sheets (1 x .sch file) & the PCB file (1 x .brd file) included in that project get the same name. If you don’t like that name, either without opening the project again, rename the 2 files (.sch & .brd) with explorer/ or finder outside Eagle or open Eagle and save the project again with your preferred name. Still only 2 files, hooked together, like a well sharpened scissors, or hand in hand like 2 immortal Aliens.
OK, so in Eagle, multi-sheet projects are all stored inside a single file (the sch file). This likely means that it is not possible to reference a subsheet from multiple projects.
In KiCad, the design decision from ages ago was that each schematic sheet would be in its own file. Multi-sheet schematics are not compacted together into a single schematic file as you describe in Eagle. This has the advantage that it is very easy to re-use sheets in multiple places, but means that they are standalone files and as such, it’s not practical to automatically rename them as described above.
1 Like
Eagle has all sheets in one file.
We (there are two parties here) seem to talk past to each other. The reason I gave reasons for KiCad not having the perfect Save As function is technical. TheSwede said for example “This is such a fundamental function, a system wide “basic function” which must work” and “I would like this simple thing to work “legal”/sophisticated, built into KiCad as it’s so basic, something that almost every other computer software has…” which make it sound like there’s something wrong with KiCad because it doesn’t have such a basic feature.
We understand very well that’s an end user’s point of view and it’s valid. I agree that it’s needed. But the fact is that KiCad project implementation is much more complex than an average one document software. For KiCad it’s not a basic function. It requires much work to get it right for all situations. That’s the technical viewpoint which explains why it doesn’t work, it doesn’t tell that the end user viewpoint is wrong.
It could also be possible to implement this as a python script, and with v6 it would even be easy for end users because there will be a content manager. It could either replicate the in-built functionality and add something to it or be a post-save-as action which would do the rest of the renaming, asking the user if the libraries and subsheets should be renamed, and possibly other files.
In any case I still wonder how much is actually achieved by renaming everything. Is it only a feeling, being annoyed seeing non-renamed files? Or is the current behavior actually confusing even after knowing what it does and what is doesn’t do? Does it really make someone’s life more difficult? Would perfect renaming remove some sources of errors?
I don’t agree that it’s needed.
KiCad has a certain paradigm where subsheets of a schematic are distinct files that may (optionally, if the user desires) be referenced from multiple projects.
Because of this paradigm, I don’t agree that KiCad needs any mechanism to automatically rename subsheets when a project is renamed. The subsheets do not exclusively belong to a single project under the KiCad model, and therefore implementing a feature that makes this assumption is not only technically challenging but also it goes against the established paradigm.
I’m not saying that this is the only valid paradigm in the world of EDA software. Some software takes this paradigm also (e.g. Altium Designer), and some software does not (e.g. Eagle). I am saying that this is not a bug, just a design decision that has some pros and some cons.
Many users still don’t share subsheets between schematics, let alone schematic files from other project folders which would only create non-obvious dependencies between projects and can cause other problems. I don’t say KiCad needs to automatically rename subsheets. But the user who wants to rename should be able to do so easily (also the project libraries; it’s possible to share even project specific libraries). Whether this should be implemented in C++ as part of KiCad can be discussed. There are many things which could be implemented in KiCad itself but could also be implemented as plugins. This may belong to the latter category.
The user who wants to rename can do so through their file manager or terminal today.
Implementing such a feature as a part of KiCad is what I object to, because it breaks the model we have today. It doesn’t really matter how many users make use of this model.
Yes, this could be done as a third-party Python plugin. I just don’t think the KiCad core functionality can support it, because it is a bad idea to have core functionality that is in conflict: allowing you to share subsheets and libraries between projects, and allowing you to easily break that sharing by renaming subsheets/libraries when you rename a project.
There are a number of reasons to trade off making something a core feature of KiCad vs. leaving it open as something that can be written as a third-party Python plugin if desired. For many features, either path would be acceptable and it comes down to “who has time to spend on the feature”. For some desired features (in my opinion, including this one), the feature is in conflict with KiCad’s core feature set, and therefore would only be implemented as a third-party plugin.
2 Likes
Wow, this got complex, as it usually does when it comes to KiCad. Thanks for sharing your thoughts guys, no matter what your idea/opinion is…
… and not to be forgotten in this – KiCad is still remarkably good in many aspects!
… except from why not include some simple, good & working presets for “Board Setup/import settings from another board” (a coming method which actually does something/works) and “Fabrication Outputs/Gerber” generation (presets) as in the end all we want by using Kicad is most of the times to to make a physical PCB…
It’s not that easy as using the file manager or terminal, one has to then edit by hand the main .sch file afterward to point to the new files.
I think it is important to point out that there are (mainly) two types of use cases.
- One has schematic subsheets in one project that are “generic” and can be shared among different projects. In this case, it makes no sense to rename them when renaming the project.
- One splits his big project into several subsheets because they do not fit all in one. Every subsheet is named MySheet_1, MySheet_2, MySheet_3, MySheet_4. If I want to rename my project to some new name that makes more sense than the one I initially thought of, I have to click on SaveAs, then use the terminal or file browser to rename the remaining, finally edit with a text editor the main sheet file to update the links to the sheets.
In my opinion, there should be a better solution for use-case 2), even if it’s against the way KiCad was designed / thought to be used for. Of course, it is not urgent. And I agree that a third-party plugin would be sufficient.
A Python plugin or script can handle both cases. Save As the old sheets under new names, remembering the conversion. Look in all the affected .sch files for filenames that need to be converted. If the filename is one of those changed, edit it, otherwise leave the filename alone.
Of course if you called the subsheet MySheet_1 and also used it in another project, then you get everything you deserve.
Thanks for your help ferdymercury! Here’s a 3.42 minutes summary what might be currently the only option; not impossible to do like this when you know how to do it but it’s still a bit over-the-top-complicated for such a “common” task, for what reason?: https://youtu.be/3RP9bbcU4HI
An edit has been made at the video link: “Note: This way the schematics library links crashes/does not work. More work must be made, which I’m not able to manage at this stage…”
1 Like