One of the changes from 4 to 5 was how the libraries are organised. Libraries are hosted on Github and are downloaded as separate repositories for libraries, footprints and models. The workflow is to fork the repositories, an to add your own models to your fork and then put in a pull request on your fork. It is not an immediately obvious work flow and, even if you are familiar with git, is a little tricky at times. If you add a model to the 3dmodels repository , you would also need to fork the footprints repository and add a pull request for the model reference to be added - i.e. double the pain. The devs have made the (sensible) choice that this can be simplified by defining the name & path of the required 3d model in advance, halving the number of pull requests (which obviously have to be applied at the same time). This does make it easier to add models and your experience with Solidworks would be very welcome as you may be in a position to submit some models yourself.
Nobody’s board ever broke because there wasn’t a nice 3d rendered model, so I understand the rationale and priorities here.
Well, for what it’s worth, I think it is. If this hadn’t happened, we wouldn’t be so well aware of the situation. Rene posted the issue in the developers mailing list. I don’t think it would have happened without this thread and the problems which von_Whimhurst faced. And as I said earlier, my overall evaluation of the situation with v4->v5 is that in the current state the installers/packages and KiCad internals KiCad 5 isn’t ready for fluent v4->v5 migration. There’s some documentation coming and now we are better prepared. But sooner or later someone - several people - of the larger user community would have faced these problems. And they will face them unless installers/packages and/or KiCad internals are changed. Documentation is a good thing, very valuable, but the less there’s need for documentation, the better (I don’t believe anyone would argue against that). Personally I would like to see some ready-made creative solutions, like “kicad-5-for-v4-projects” with separated configuration and compatibility libraries which I mentioned some 1000 posts above.
Did you expect someone to read those manuals? Maybe Kicad documentation writers expected you to read the manual.
We cannot blame developers for the lack of documentation of a version that has not been officially released yet.
I agree in one point: there is the need to document how to manage the libraries. Then, we should explain that the official libraries are a particular case of all the possible libraries.
And we should explain that environment variables are very useful but not mandatory.
Some newbies can see a mess with library management of symbols, footprints and 3D models. I’m a newbie with other programs all the time and I usually read the documentation before asking for help or complaining.
I will go ahead, Maui I wrote an explanation in the Spanish forum. I think I will rework and translate it into English.
That’s the point!
In my case, I also use the official libraries only as a starting point to build my own ones. And sometimes with different versions of the same footprint for different clients.
Librarians have made a great job reorganising all the stuff for version 5. And they know there will be more job to do for version 6 with eeschema upgrade.
It is a non-apreciated effort for people who want a program working out of the box.
Hmmm. You are blaming me for taking the advice of someone (Eelik) who seems to speak as a member of the development team (see quote below). Nobody chimed in and said, NO, YOU FOOL—DON’T DO IT!
Note to Eelk: Don’t take this personally! You offered your advice in good faith and lacking any contrary opinions, I took it.
Moreover, you are saying you have more than 30 years of software use and you need to get someone else suggestion to know which is the risk in using developing releases or making a transition to a new release of the sw?
At the end you are blaming again against other people instead of admitting that this is the result of just your own decision.
Nobody forced you not to spend more time at the forum to get the right information for your user case… and you are the only that know your real user case.
And last but not least, as I already told you, many users have switched to v5-pre without big hassle and without blaming anyone.
No, I’m not. I follow the developer’s mailing list, I pull the source code from git and compile it almost on daily basis. I have peeked into the code. I have written some documentation (about the environment variables) and have recently been going through the Getting Started guide, making changes for version 5. I have been an Open Source developer in another project and worked as a programmer. But I’m not a KiCad developer. Not, even though I recently was accidentally granted the developer badge which is visible in the avatar icon of those who are part of the development team.
I also want to remind that I said “For a beginner who has no valuable projects yet, now is good time to start with nightly builds.” That’s still my opinion. If a beginner comes now to KiCad, I think there’s no good reason to start with KiCad 4, even when 5 isn’t ready yet. The story is different if someone thinks about changing to 5 from 4 with existing projects.
Actually you were never asked what kind of projects you have and do you want to migrate them to KiCad 5. And then there came this problem with general update from 4 to 5 which wasn’t anticipated as well as it should have been.
I switched with big hassle, but I didn’t blame anyone because I took the risk and I was the one who was to blame. But things are a bit different now. Considering that KiCad 5 could have even already been released if there wouldn’t have been critical bugs for some weeks, I feel uncomfortable about the fact that such a big problem (the non-compatible fp-lib-tables) was uncovered this late. I just don’t feel it’s fair to blame a newcomer if he doesn’t read all the possible documentation. Such a updating process really should be so much automated that a user didn’t have need to read documentation about it to be able to use the new version with the new libraries.
Yes, of course, but the problem was that, at least right now, when KiCad pre-v5 is installed and it replaces v4, the new footprint libraries are installed, but the global fp-lib-table isn’t updated and there’s not even a warning about it. This may be fixed somehow, considering the developer discussion which is going on, but it’s not a simple or rare issue. It affects everyone who updates KiCad from 4 to 5. Whether they are using the official libraries as starting point or not.
Thanks, Eelik. And thank you for clarifying your status as “not a developer”.
Of course, I agree: newcomers should not be expected to know the entire history of the Forum(s) of KiCad or any other software (which is something I stated previously)
And for the record, although Maui seems to be interpreting that I am “blaming” others, I am not blaming, although perhaps Maui is feels that it’s blame. What I am doing is putting my usage / choices / steps or history, in context.
Eelik is spot-on when he says “really should be so much automated that …”; Again, in my opinion also it is very reasonable to expect a “new” installation to perform all basic functions from the starting gate. That includes Beta versions or ‘nightlies’. A “new installation” should, in my opinion include the situation of performing an Uninstall of one version, and the installation of a new version (i.e., the user shouldn’t have to nuke-and-pave to get a virgin platform on which to build the installation).
Insofar as the sometimes repeated remarks about ‘nobody really needs a 3d version of the board’, well, I guess those who have made such comments have never tried to fit long, skinny boards into tubular pressure housings of geophysical instruments getting plunged several km into a borehole— a task where the overall board layout is often dictated by the component packages, not by the desire to have a simple 1 or 2 layers board and efficient routing. In other words, taller components often have to be placed along the centerline just to make them fit, and the board may have to be >2 layers (with blind vias) just to get the necessary level of routing options.
I have my own libraries and templates; I update the fp-lib-table when I need to add or remove libraries to my personal db…
I updates my libraries when I need to add or change my symbols or footprints… No big issue if the format of the libraries doesn’t change… (that is the only risky part to be aware of)
I don’t see many issue if you know how the sw is working and what to do with it…
And just to remember you, v5 is not even released… after the release there will be a transition period in which all (most of) these glitches will be fixed because many users will spot those … that happened in the past from kicad v3 to v4 and it will happen again from v5 to v6 …
Yes, but it’s better to catch them before the release. And a couple of glitches have been caught here. I don’t see any reason to blame the original poster. He(?) may have made some mistakes in communication, but communication goes in two directions, and even in this discussion there are more than one party who are guilty of imperfect communication… Me included.
Because it really was not all that hard for me to do. And, when considering the feature benefits in the nightlies, even the V4 nightlies, it still seems to me a “no-brainer” to step directly into V5 at this time.
V4 and V5 handle the libraries differently. It does not make sense for me to recommend that a beginner learn V4, only to have to relearn a totally new system in a short period of time in the future.
Standard nightly disclaimers apply. However, I’d bet that those on this forum would be prompt to help find a solution to any issue encountered when respectfully asking for technical help (the 100+ replies already demonstrate this). Another benefit is that other new users will be able to search the forum for a solution in the situation where the documentation may be a bit lacking, which is perfectly normal for open-source software.
@von_Whimhurst Do you have a specific issue that you need technical help with? And, I suggest you create a new thread if it is not OpenGL canvas related.
After having tried many times to tell him why the libraries have the actual structure, the poster said:
and if you go through the thread, you can see that he complained many time about developers and librarians choices and documentation, and he complained of not being heard, but he refused to spend time to go through the forum to understand why the libraries are structured like they are now. And even refused to raise his complaint to the developers mailing list, which is the place, eventually, to ask for changes or report issues.
So: who is blaming who?
In no place did I “refuse” to do anything. The word “refuse” is one highly loaded with negative emotion and I respectfully suggest sticking to the facts:
In the context that we ended up discussing breaking news / revelations about a “nightly” prequel to v5, researching old Forum notes would’ve been an irrational thing to do.
Am I on the developer’s mailing list? No, I am not. That membership is not automatic; it is a closed group that requires invitation. Did anybody invite me to “become a Developer”? No. How am I to post any mail to a closed group before I am invited to join?
And I am sorry that you (and perhaps most…) obviously didn’t appreciate my sense of humour: the *.hal file extension was suggested with allusion to the HAL 9000 computer that ran amok in Kubrick’s 1968 movie classic, 2001: A Space Odyssey
John, thanks for taking the time to write this reply.
I’m not used to using Git so it will take some effort to get used to the routines (work flow). Hopefully, Microsoft takeover of GitHub will not change and complicate any of that!
I’d be happy to contribute any number of models to the KiCad project. At some point, I am sure that I will need some pointers on the workflow that you outlined and, if it’s OK with you, I will just message you directly.
I wrote an explanation in the Spanish forum. I think I will rework and translate it into English.
