Context: Newbie user of V4.0.7 on Win7 SP1 64-bit platform (100% up to date). AMD FirePro graphics card with full OpenGL support (100% up to date).
I’ve wandered into the OpenGL vs default vs Cairo minefield. As I am still learning to use the various features, I am not sure what behaviour is due to quirks of the “canvas” being used, and what behaviours are due to my ignorance / inexperience with using the tools.
I’ve checked the Forum postings, and postings on the topic of the OpenGL “canvas” are not only 1-3 years old, but were also controversial and meandering.
Would anybody care to post a concise summary of the OpenGL support in V4 and in the soon-to-be-released V5? In particular, should I just stick to one, or another, of the ‘canvases’ during the learning phase for the sake of my own sanity? (I really liked the comment in one post, about a particular behaviour “frying the noodles” of newcomers to KiCad)
I would recommend just sticking the OpenGL canvas. Cairo is just meant as a (slower) fall back for machines where OpenGL is not available and the Legacy canvas will be removed at some point (v6?).
If you are trying to do something in particular and it’s not been implemented in OpenGL then switch to the legacy canvas by all means. I still switch to the legacy canvas for selection even in the nightly/dev version of KiCad.
I don’t know what a concise summary should look like. My opinion is that it wouldn’t be fair to lump together v4 and v5, or even compare them. I would say that v4 was the modest beginning of the “modern toolset”. V5 is what it was meant to be. In v4 many users feel need to switch back and forth. In v5 you never have to switch to the the “legacy toolset” (former “default”). This means that “concise summary of the OpenGL support in the soon-to-be-released V5” for me is: it works.
It talks about features that may or may not be missing, but does not enumerate those features.
Unless you are familiar with all the ‘features’ (operations) and how they are supposed to normally present themselves (that is, you are a newbie or someone with lower experience levels), #1 above means that you have to do a lot of experimenting with both the Default version and the OpenGL versions to discover the differences for each and what works best.
To answer Eelik, I suppose a table such as this would really help to nail things down:
where the symbols mean something like “perfect performance”, “dodgey, erratic…” and “dysfunctional”
If you are new to kicad, just use open gl (or modern) you will not miss anything. Most “missing” features for which people have complained about (on this formum) are either replaced by a different workflow or are specialized tools that you will not miss if you never knew they existed.
That kind of rating wouldn’t make much sense. In the upcoming v5 the old “Default” (which is now “Legacy”, while OpenGL is the default) has been left behind, not updated with new features. In short, it’s not meant to be used. The new GAL canvases are far superior. OpenGL and Cairo should work similarly except for speed. If something is missing from GAL compared to the old canvas, it’s like Rene said, it’s because of different workflows. There’s no “dodgey”, “erratic” or “dysfunctional” features in GAL canvases any more than there are such features in any kind of application. Certainly there are and will be bugs and wishlists for features, but they have nothing to do with Default/OpenGL/Cairo comparison.
OK, thanks to both yourself and Rene for elaborating. I had the distinct impression, from the other Forum discussions, that there were commonly used functions that did not work in one ‘canvas’ and so one had to keep flipping between them to carry out ordinary work flows. If, as Rene says, they’re things that you wouldn’t miss if one didn’t know they existed (like the taste of fricasee’d Dodo), that’ll be good enough for me to carry on using just OpenGL.
One observation (as I had returned to some work using OpenGL)…apparently the Block Edit feature that works within the Default canvas doesn’t work in OpenGL. Am I missing something, or is that an accurate observation?
OK, so there are features that perform properly in one ‘canvas’ but not in another. That was my perception when starting to use OpenGL in v4.0.7 and hence my suggestion of a table that would summarize these problems. My objective in starting this thread was certainly not to suggest that one ‘canvas’ or another is defective overall and should be chucked in the trash-can (see quote below). That would be like throwing-the-baby-out-with-the-bathwater.
Rather, it’d be better to have a ‘cheat sheet’ that serves as a sanity check when the user stumbles across some odd GUI performance. Much better that, than staring at the screen pondering, “Hey, what happened to the […name here…] command?”
I was talking about v5 unless explicitly stated. There probably will be users who are forced to continue with v4 for a while. But I bet that after getting a taste of v5 everyone wants to upgrade. There would be no reason to make a checklist for v5 because you would just check everything for GAL (OpenGL & Cairo), and Legacy isn’t needed at all. Basically Legacy is the same as v4 Default, without changes (I don’t know if something has changed, but as far as I understand the development was ceased after v4).
So there would be only v4 Default vs. v4 GAL, two columns, and v5 should be left out because it does everything anyways, and then some more. I don’t see why anyone would bother doing that for v4 because it will be obsoleted so soon. I can be wrong, of course, and if someone wants to do it, go ahead, maybe someone needs it.
Hello, 'Eelik"
Thanks for clarifying that you were referring to V5. On the other hand, I started out this thread by stating that I was using V4.0.7, and that I was new to KiCad. I have not tried to shift over to the KiCad beta-version (V5 “nightly builds” etc) as that’s a work in progress. Learning new software while that software is undergoing metamorphosis would be like attempting to build a house on a sand dune during a wind storm. I would’ve thought that someone (presumably one of the Developers) has their own cheat-sheet or check-list of issues that they want to / need to address as they migrate from one Build to another. I was hoping that this could be shared.
Right now nightly builds are very close to the final 5.0. Only bugfixes are still added. For a beginner who has no valuable projects yet, now is good time to start with nightly builds.
Alright…I will take your word on this.
As I have V4.0.7 installed currently… I assume I have to do an Uninstall of KiCad 4.0.7 and then download and install the current (nightly) build of KiCad…right? Are there any libraries and files that I have to manually delete?
I am guessing here that the Nightly Build is a complete installation package, and not akin to “windows update” installer.
Also you have to be aware that you have to migrate projects made with v4 to v5 and then you can’t migrate them back. I you are just playing with projects for practice you can do the migration or start new projects. If you have something which you want to get finalized you could do it with v4 or migrate a copy and try to go on with v5.
So, there is a tool within KiCad V5 (i.e., the currently nightly build…!) that migrates old V4 KiCad files? I am assuming here that a big part of the migration process is the automated replacement of all the old footprints (and symbols?) with ones from the new Libraries which are in a different graphics format?
If switching entirely to v5, when uninstalling v4 also remember to wipe out the C:\Users<username>\AppData\Roaming\kicad user settings folder, or at least change the folder name so the new v5 KiCad can’t find it. That should give you the best “starting from square one” experience.
Footprints have been and are embedded in the pcb file and they don’t need migration. You don’t need to update them, the old ones are compatible with v5. You can update them manually if you feel so, but it has to be done one by one and you have to find the corresponding new footprint yourself if the name doesn’t match.
The built-in migration is for the schematic. It has caused some headache for me but it should be automatic if you have correct new configuration and libraries installed (I had some problems because of earlier installs).
Hmmm. Ok, that one should go over to V5 immediately if you are a newbie does seem to be the consensus. My only criticism (now) is that, the kicad.org site’s reference to V4.0.7 as “the stable build” should now come with a caveat / warning aimed at those entirely new to KiCad. Starting new into KiCad, one would not normally (to my mind…) spend much, if any, time reviewing all the various Forum discussions to know that V4.0.7 is really not the best flavour for the Newbie.
Hello, Eelik:
I just un-installed V4.0.7, and installed the latest Nightly (“V5”). Here is what I found…
None of the old footprints in my PcbNew were updated automatically.
The footprints I created and put in a separate folder, were not preserved (not a big surprise) and I had to recreate them (only 2 so far, not a big deal).
I reviewed the schematic, and the schematic seems to have come across (migrated) correctly, with the exception of the custom symbols I had added and their associated footprints (now fixed).
I recreated the Netlist and, when returning to PcbNew, I imported that Netlist. I also ran the “Update all footprints on Board” command. The fact is, none of the 3d models appear in the 3d view.
At least one of the now-missing footprints does not have a *.wrl file in the new Library.
It seems that a significant number of 3d shape files that exist in the previous Library, are no longer in the new (V5, Nightly) release.
