This Post is new, but is related to the post OpenGL Canvas Update, from which it redirects.
Summary here for those coming new to this post:
Original posting at OpenGL Canvas Update was a request for information about the OpenGL canvas and how that works in the stable V4.0.7 release, and how it works in the “nightly” builds of the soon-to-be-released V5.
As I am a newcomer to KiCad, I had originally started in V4.0.7 (running on a Win7 64-bit platform).
As a newcomer, I am not working on imminent, “important projects”. I am on the steep part of the curve, just learning how to use KiCad and its work flow.
It was suggested that, given the imminent release of V5, it didn’t make sense for a newcomer to learn on V4.0.7 if I wasn’t doing time-line sensitive ‘important projects’ ---- that I should just move directly to the ‘nightly build’ of what would soon- (weeks, or possibly days) to-be-released v5.
I un-installed V4.0.7, and took steps to clean up the registry , re-booted several times and only then did I start a fresh installation of the “nightly” prequel to V5.
My newly installed v5 had a significant number of problems. There were problems opening, viewing and editing footprints (here I emphasize: the footprints that were supposedly newly installed with KiCad “nightly”—opened from the Library, directly from KiCad’s Footprint Editor). I also noted that CvPcb didn’t function; it wouldn’t load footprints to associate with the schematic symbols.
Fast forwarding through many contributions to the OpenGL Canvas Update post…it turns out that using the Uninstall function on V4.0.7 doesn’t completely remove the old installation.,
In particular, at least in Windows, a directory is created during a KiCad installation as [drive]:\Users\{username_here}\AppData\Roaming\KiCad
That directory is NOT deleted when running the Uninstall;
That directory is NOT updated during the Installation of a new KiCad version.
Serious problems with the new installation result from the persistence of the file, fp-lib-table, within that directory.
Solution (at least in part):
Shut down KiCad.
Migrate to the directory noted above
Remove the file fp-lib-table (or rename it so that it cannot be found when KiCad goes looking for it)
KiCad will generate a new default-version file fp-lib-table when it is next started.
This solves (most) of the immediate hiccups with the v4 to ‘nightly’ up-versioning
This is an interim solution. A seamless solution may be implemented in v5 when it is released.
At this point, I am still wondering whether there are dangling problems with the files in the AppData\Roaming directory created by the installation of KiCad.
There are files other than (the now corrected) fp-lib-table in that directory, and they look as if they may also cause problems…sym-lib-table is particularly suspect.
I am also / still concerned about how my environment variables and Paths are configured. Does anyone know of any diagnostics that can be used to check these? If there are any diagnostics mentioned in the Forum, it’d be a leap of faith to assume that they’re compatible with the nightlies / proto-v5
That was the heart of the problem. It’s of course normal and even expected from updated programs that they keep the user configuration. However, in this case the global fp-lib-table which defines the footprint libraries which the user can use in pcb projects is handled as part of the configuration, and when the libraries are updated, that file is not updated automatically. There are a couple of solutions:
As von_Whimhurst explained, delete the fp-lib-table from kicad/ configuration directory.
Delete the whole configuration directory and start completely from scratch.
When you open pcbnew for the first time with KiCad v5, open Preferences->Manage Footprint Libraries. Select all global libraries - you can select a cell of the topmost line and use shift+mouse click on the bottom cell to select all, then click “Remove Library”. Now click “Browse Libraries”, find the location of the new libraries, use ctrl+mouse click to select the first .pretty folder, use shift+mouse click to select the last folder, click OK.
We can always hope, but I think that is unlikely. Installing data into KiCad has always been a tricky issue which no one has properly tackled. I wrote a tool to make it easier https://pypi.org/project/kipi/, but that (and others) require the user to run Python scripts, which isn’t trivial for people who want an easy to use tool.
Wayne Stambaugh is writing a document on upgrading to v5, I fear it is written rather from a developers point of view, and the typical user may struggle with it.
It’s not really necessary to delve into the config files in the config dir, the library tables can be managed via KiCad GUI itself. I think there is more likelihood of people messing up their install accessing those files directly.
The files that cause problems are fp-lib-table and sym-lib-table, since those are really user files not KiCad files, but they are neither updated properly by the KiCad installer or if the user downloads official libraries. (kipi takes care of updating those tables, it’s as “seamless” as I can make it).
At the moment it handles practically only migrating old projects, not all problems of updating the software. It’s short and to the point, but from the beginning (when the change was announced in the blog) I didn’t understand almost a word about it. I’m still struggling with it even though I now understand much more.
Yes, it looks like that document will help ( I have only started to read it; the content certainly looks promising). I will revert to you if I have any questions about it.
Old hands may remember the pain of the last major upgrade and be wary, but for the typical user who jumps feet first into v5 after using v4 it’s going to be a bit of a shock. Modern software has advanced to the point where users generally expect a “seamless” experience, rather than spending two weeks setting up a new program install fiddling with text files (config.sys anyone?).
I am thinking that the best thing would be for v5 to install completely separately so v4 is always a fallback. There are plenty of migration features that could be added, but given the timescale and the reluctance to write one-off code I doubt any will be implemented. At least if a user has issues with v5, they can still be productive with v4 until they have worked out the kinks with v5.
ETA: Is this topic better titled “Issues upgrading to v5”?
There’s a good reason for that. The global fp-lib-table isn’t only for the official libraries. The fp-lib-table which is in the user’s configuration directory is meant for all libraries which are used in many projects, so that there would be no need to add each library to the project specific fp-lib-table. Therefore it’s not possible for the software to just blindly overwrite the old fp-lib-table. This is how the system works now. In the future there may come some changes. There have been developer discussion in the mailing list about possibility to use several fp-lib-tables in some way or another, but it’s an open question.
I will ‘float’ a suggestion here. If those reading this (User) forum think it is useful I will try to get it into the Developer’s forum (If I should merit being invited):
Suggestion:
For newcomers to KiCad who have just installed the software, they will obviously have no pre-existing Projects (i.e., in KiCad Lingo “Project” means a collection of schematic, PCB layout and other files in the workflow related to the production of a single PCB board, its fabrication outputs and so forth). A possible exception would be those with colleagues who might share Projects with them as a springboard.
It would be reassuring and gratifying to the KiCad newcomer if they could open one or more example projects (“Example_1.proj” etc). With each of these examples, there could be a short tutorial exercise that would help the new user to use these Example projects to confirm that their installation is 100% functional (eg., open this dialog; you should see this…and this… and this choice should do this…)
There could be too many issues to be handled under one topic. We already saw what happened in the previous thread But eventually they must be gathered together somehow. Maybe one longer document without the usual heated argument format
Since we know what libraries were packaged with previous releases, and where they are installed, then KiCad could in theory remove the official libs leaving the user libs and any the user has modified. This would tkae a bot of coding effort but would probably be regarded as not worth it.
The better method is to tag the library with the source so it can be easily be upgraded, which is what kipi does.
A good idea, there are some demo projects in the …\share\demos folder, easy to miss. There is also the “Getting Started in KiCad” guide https://kicad.org/help/documentation/#_getting_started which walks through a complete project. It’s also available in the main menu under Help->Getting Started in KiCad
Did not know about the demo files (Thanks), as you say they’re easy to miss and didn’t see any pointers to them in the Getting Started guide.
A prepared set of Project files (such as, I assume, the demos you alluded to) would be best for quickly confirming the Installation. The problem with the walk-through tutorials is that you create them yourself, from scratch. So, if the user ends up with different results (visual / GUI or numerical etc) then there’s the possibility of a mistake by the user, while their newly minted installation could be just fine. In medical terms, those unusual results would be called “false positives”.
But eventually they must be gathered together somehow. Maybe one longer document without the usual heated argument format 