gEDA vs KiCad: Differences, advantages and disadvantages?

[c4757p]

Who said they don't deserve respect?

Okay, if they're offended by testing Gerbers in another package, they don't. I've not met any that stupid.

I am pretty sure KiCad just wraps there stuff around gerbv.

It does not.

[codeboy2k]

Yes you should validate your gerbers. That is why gEDA users call the companion program gerbv after making gerbers in PCB.

... and then validate again with another viewer, for exactly the reasons c4757p says.

The MCN Gerber viewer is decent and cross-platform.

Having never heard of it, I had high hopes for testing a new  linux gerber viewer, but it seems to be Mac only.

Here's an interesting web-based 3d gerber viewer : http://mayhewlabs.com/3dpcb I found that is fun to play with but can't be taken seriously because it has severe drawing anomolies (cracked or crooked drawing, anti-aliasing, high-angle views of the board puts bends in the traces where there are none, and the damn acceleration and deceleration when you move the board.. grrrr)

[timofonic]

Excuse me, I reformatted your message to make a structured reply.

gEDA and KiCAD are two different philosophies about how to solve this problem:

- gEDA uses the unix mentality of multiple single function tools the users decides to combined for different work flows.

I agree about it. That kind of mentality seems obsolete by a major number of people, that's why things like systemd. I'm not sure what one is better than other, but I'm more comfortable with one of them depending on the task.

Anyway, I have been using 20+ Operating Systems as a OCD hobby (I'm usually an apprentice of everything, master of nothing), but I like command line and streamlined GUIs without ribbons on top, maybe a mix would be nice (I like the Eagle cli, despite it's very limited).

Modern GUIs influenced from other Operating Systems are morphing the UNIX world into something different, with a mix of both monolithic and modular approachs.

The big problem of gEDA is stagnation, because different reasons:

- There are highly skilled people in the gEDA community that is able to develop their own forks for their own needs. Unfortunately, most of them don't care at all about merging code to mainline, they are mostly quite conservative.

- The project is considered mature and "good enough". There's little interest in innovation, but fortunately some rebels want to change that.

- They use Lisp a over there (Guile). Despite it can be cool, it's a dead language for mostly all programmers. These days is C, C++, Java (don't enter into this trap owned by Oracle), .NET/C# (another trap), Python, Lua.

- It's practically not multiplatform, Guile has portability issues on Windows at least.

- Instead investing their efforts in development and merging back forks or improve stuff in a constructive way, they just do their own stuff or waste it on massive flamewars.
* They make endless discussions about what to do and unable to make agreements, even resulting in not polite attitudes to others.
* They even critic about other projects such as KiCad.
- Delorie seems to not have a strong leadership in this project to make it progress. I'm not sure why, but he finally wasn't able to manage the situation in a way to have a sane community.

KiCAD is more monolithic for people who want everything in one integrated tool.

You are right, but there are other interesting stuff about this project:

- They are a multiplatform project, so more users and developers could be more interested in it.

- They are a more open project to contributions, novice users and innovation.
* They don't act in an elitist way, despite some past flaws. These days they reply all questions and encourage the submitting of patches and bugfixes.
* The contributions from CERN are revitalizing the project and improved the interest in the project.
* OSHW community, "makers" and students are getting interested in KiCad as an alternative to Eagle.
* Their community is more friendly to novices and new developers,
 - They even have a new and better website.
* I miss a news section on the main page.
- Differential pair, 32 layers support and PNS routing are very interesting stuff that got added.
* They have more stuff they want to improve after the upcoming release:
** User Interface improvements
** File format interoperability.
** Back annotation.
** Better integration between Eeschema and NewPCB, changing many parts of the current application design.
** They plan to use by default their new and better OpenGL/Cairo graphics backend as default (GAL).
*** Currently some features are only available in GAL and others in the "legacy" backbend. They plan to improve this and have the possibility to use a nice Hardware accelerated graphics environment.

 ** Better Python scripting: There's some stuff already done, but they need to improve things.
*** I hope they are able to archive the flexibility and diversity of Eagle's ULP, but providing a centralized scripting repository.


To me, it's a lot more than the UNIX vs Integrated approach:
- One project has better management and a sane community.
- The other project have lots of flamewars and against innovations.


It's a shame the EdaCore initiative didn't get enough momentum: it's a brilliant idea to share source code and component libraries between Open Source EDA tools.

[codeboy2k]

They plan to use by default their new and better OpenGL/Cairo graphics backend as default (GAL).

I like the look of the OpenGL or Cairo renderers more than the default renderer, but on my system the default renderer is about 2 to 3 times faster then either OpenGL or Cairo.  It just gets really slow whenever I switch, so I think that I have some specific 3D graphics issue here with KiCad and it's using emulated OpenGL calls instead of the real hardware.  My graphic card is a AMD ATI HD7870 GHz Edition which is really fast (and does do WebGL and OpenGL demos fine even when KiCad is slow)

[c4757p]

Interesting. There are definitely variants in speed, and it goes both ways. On my machine, the old renderer is unusably slow.

There is a distinct emphasis on speed in the design of the GL renderer, it's rather a priority. Hopefully we can get hold of one of the problem configurations to try to fix that.

[ScribblesOnNapkins]

Excuse me, I reformatted your message to make a structured reply.

gEDA and KiCAD are two different philosophies about how to solve this problem:

- gEDA uses the unix mentality of multiple single function tools the users decides to combined for different work flows.

I agree about it. That kind of mentality seems obsolete by a major number of people, that's why things like systemd. I'm not sure what one is better than other, but I'm more comfortable with one of them depending on the task.

Anyway, I have been using 20+ Operating Systems as a OCD hobby (I'm usually an apprentice of everything, master of nothing), but I like command line and streamlined GUIs without ribbons on top, maybe a mix would be nice (I like the Eagle cli, despite it's very limited).

Modern GUIs influenced from other Operating Systems are morphing the UNIX world into something different, with a mix of both monolithic and modular approachs.

The big problem of gEDA is stagnation, because different reasons:

- There are highly skilled people in the gEDA community that is able to develop their own forks for their own needs. Unfortunately, most of them don't care at all about merging code to mainline, they are mostly quite conservative.

- The project is considered mature and "good enough". There's little interest in innovation, but fortunately some rebels want to change that.

- They use Lisp a over there (Guile). Despite it can be cool, it's a dead language for mostly all programmers. These days is C, C++, Java (don't enter into this trap owned by Oracle), .NET/C# (another trap), Python, Lua.

- It's practically not multiplatform, Guile has portability issues on Windows at least.

- Instead investing their efforts in development and merging back forks or improve stuff in a constructive way, they just do their own stuff or waste it on massive flamewars.
* They make endless discussions about what to do and unable to make agreements, even resulting in not polite attitudes to others.
* They even critic about other projects such as KiCad.
- Delorie seems to not have a strong leadership in this project to make it progress. I'm not sure why, but he finally wasn't able to manage the situation in a way to have a sane community.

KiCAD is more monolithic for people who want everything in one integrated tool.

You are right, but there are other interesting stuff about this project:

- They are a multiplatform project, so more users and developers could be more interested in it.

- They are a more open project to contributions, novice users and innovation.
* They don't act in an elitist way, despite some past flaws. These days they reply all questions and encourage the submitting of patches and bugfixes.
* The contributions from CERN are revitalizing the project and improved the interest in the project.
* OSHW community, "makers" and students are getting interested in KiCad as an alternative to Eagle.
* Their community is more friendly to novices and new developers,
 - They even have a new and better website.
* I miss a news section on the main page.
- Differential pair, 32 layers support and PNS routing are very interesting stuff that got added.
* They have more stuff they want to improve after the upcoming release:
** User Interface improvements
** File format interoperability.
** Back annotation.
** Better integration between Eeschema and NewPCB, changing many parts of the current application design.
** They plan to use by default their new and better OpenGL/Cairo graphics backend as default (GAL).
*** Currently some features are only available in GAL and others in the "legacy" backbend. They plan to improve this and have the possibility to use a nice Hardware accelerated graphics environment.

 ** Better Python scripting: There's some stuff already done, but they need to improve things.
*** I hope they are able to archive the flexibility and diversity of Eagle's ULP, but providing a centralized scripting repository.


To me, it's a lot more than the UNIX vs Integrated approach:
- One project has better management and a sane community.
- The other project have lots of flamewars and against innovations.


It's a shame the EdaCore initiative didn't get enough momentum: it's a brilliant idea to share source code and component libraries between Open Source EDA tools.

PCB/gEDA already has opengl/ cairo rendering with optional other front ends.

One of the things that came after Peter's talk on EDA Core was a push (in no small part driven by me) to do a new release.

Yes gEDA did hit a level of maturity and more or less stop development in some aspects. Unix mentality each program should only have one clearly defined function. Why would your schematic editor be constantly in need of development. The gEDA part of GAF (geda and friends) is solid, stable, tested and all the functions it promises actually work. Yes they only work on Linux, Unix, Solaris and *nix's but these days even Xilinx supports Linux as a development environment so why needs windows? I only use it these days when someone sends me something in orcad or altium.

I pushed people a bit and we are headed too moving away from Lisp and scheme as our primary scripting languages for plugins.

Ok yes we do have some long running debates and there is some hostility mostly directed at one guy. The thing is I think he is right. The other flamewars are just people being silly (my VCS is better than yours, my language is better, vi vs emacs, and etc.) A month ago someone was saying we should all adopt PL/I, you did not think that was serious did you? We are not against innovation, it is just that people keep joining and trying to change one fundamental thing integration. We accomplish the automation part of EDA via scripting (makefiles) that call the tools in an almost infinite number of possible flows. This only works because of the Unix mentality of one function per tool, break that and you break automation. Our most rejected idea is integration because it means bluing the PCB tool into the schematic editor and etc. Everyone who joins will be welcome as long as they don't try to force a change on this or move us off of C.

We have plenty of newbies who join the list and are welcomed. We just don't like folks trying to force us to code what they want. Sorry but part of being new has to be accepting that not every idea you have is gold.

Why is DJ supposed to lead the project? I like him but he is more interested in being an engineer than a leader. Look around the open source world, he has many other things going on. Most of us do.

gEDA's partner project PCB supports n layers by default it only loads with 6.

gEDA's file format was well planned from the start so adding hierarchy and etc have only required one format change in like 10 years. (PCB is mid overhaul and has a different history)

This is not a competition. We are all interested in one thing, building open tools.

[ScribblesOnNapkins]

*for me* the only tool where gEDA is better than KiCad is the Gerber viewer, kicad's one is really basic and nearly useless, gEDA one which is not perfect, provide at least some useful tool, allow layers to be reordered, etc...

http://gerbv.geda-project.org/

gerbv:

vs

Kicad's:
(yes I know it's an old version in this picture, but it haven't changed a lot with the latest changes)

Kicad is at least missing the possibility to change the layer order, do some measurement (if there an option it's absolutely not obvious)
The "rendering" options that gerbv have are really useful (especially the semi transparent one)

Also with kicad you lost the name of the file you used for each layer, some time it's obvious what is what, but sometime it take too much time to understand which layer is what.

It really works better for demos if you turn off fast rendering and go to quality. OpenGL and antialiasing really make everything look pretty.

[ScribblesOnNapkins]

Who said they don't deserve respect?

Okay, if they're offended by testing Gerbers in another package, they don't. I've not met any that stupid.

I am pretty sure KiCad just wraps there stuff around gerbv.

It does not.

Yea I took another look at the code. Foot in mouth.

[c4757p]

It really works better for demos if you turn off fast rendering and go to quality. OpenGL and antialiasing really make everything look pretty.

Indeed. gerbv renders are sexy. I use gerbv whenever I want to make a good-looking render of a PCB.