EdaCore: What's up about it? Any news?

[timofonic]

Hello.

Any news about EdaCore? Is it alive? Are there short term goals?

edacore is an open source project to fulfill the part library needs of all open source Electronic Design Automation tools, and ideally the rest of the EDA industry. This is an ambitious project with high quality standards and long term goals. The project is still in an early stage.

The project was announced by Peter Stuge in the EDA devroom at FOSDEM 2015. There is a ?video recording of Peter's presentation and the slides are available: for online viewing and for download.

Stay tuned! You can join #edacore on irc.freenode.net as well as follow @edacore on?https://twitter.com/edacore to connect with the community.

EDA File Format Documentation

Ok I am a gEDA user. I have been for over 10 years now. I don't question that kicad might be more user friendly because of how gEDA is designed to have a user defined workflow. This makes it easier to automate, something few EDA packages really do as well IMHO. It was geared around people calling all of it's different utilities from the command line, scripts or makefiles. That said there is a gui just for people who only want to take a schematic and make a board from it. It also has hierarchical design.

Bassman 59 describe the M4 system as a "cluster fuck." Please understand you don't have to use that. The M4 option is there so that you can have programatically defined properties in your footprints. For example some people like being able to change SMT pad lengths for hand assembly on prototypes and then shrink them back down automatically for reflow assembled boards.

For any EDA package you have to track what symbols and footprints you use with model number components.

Looking to see what gEDA library looks like now? It is available here. No need to install anything.
http://www.gedasymbols.org/

Yes CERN has pumped some coding time into kicad that has added some PCB layout features which I am a little jealous of however kicad seems to have more reliability issues. gEDA is *very* reliable. I am currently on both developer mailing lists because both communities are working to create a more common code base. We are all tired of duplicating work.[/b]

I didn't know about it before!

Could you please provide more info about this? Are there some planning about it?

Those are really good news! I'm very happy to know it! Joining in common goals is very needed for OSS projects.

@Dave, as much as I hate to say this compared to altium, orcad or protel all opensource EDA is really a personal play thing because of user base. KiCAD has some disadvantages that to me are kind of glaring but I am more interested in adding things than starting/being in a flame ware. The UI experience of gEDA might feel like a toy if you are new to the *nix way of thinking about things but after you get used to it there are things you realize are possible that would be very hard if no impossible to do in a "modern" integrated GUI. Keep in mind I started out as an electronics hobbyist who took up Linux way later on.

@Circuiteromalaguito there was a meeting this year at FOSDEM in Belgium. The videos are for some reason not posted on their website yet but you can find them here. https://video.fosdem.org/2015/
The project is supposed to be hosted here http://edacore.org/
You can see the gEDA half of the dialogue here http://comments.gmane.org/gmane.comp.cad.geda.user/45312
The KiCAD part is on a mailing list you have to join yahoo us access here https://groups.yahoo.com/neo/groups/kicad-users/info

The folks who do circuit simulation where there (icarus, gnucap, ng-spice and etc) as were the EDA people from QUCS, KiCAD and gEDA. One person proposed EDAcore and started a dialogue that has span both the gEDA, KiCAD and newly minted EDAcore mailing lists. It has ebbed and flowed since then. I get the impression a number of us are quietly hacking away at things but no group work has kicked off so far.

I really like the gEDA devs but they have their ideas of how things should go. They have not included a lot of contributions of the years because they were not in the same language as their other code or did not meet their coding standards. To be fair even some of DJ's stuff never got included. This has limited the functionality of the gEDA suite with out these 3rd party widgets. It has however made the suite run very reliably. The PCB tool has had it's issues but with extensive testing it passes. I am hoping that PCB getting doxygen documentation will help speed things along.

There has been talk of incorporating some of CERN's contributions to KiCAD as they were written to be portable between suites. However most people who have looked at the PCB tool that is paired with gEDA will tell you the source is a mess. gEDA and the PCB tool have different origins and PCB's architecture was never so carefully controlled. The gEDA source code I can read the PCB source just confuses the heck out of me. Eventually DJ or one of the Peters pointed out to me that it has no unified concept of what a PCB is. I get the impression from people that KiCAD's PCB tool has architectural issues of it's own though possibly less seriously. I get the impression that basically both groups want to flush out the mess their current code has them in before combining forces.

My *personal* hope in the short term is that we work on compatibility with non-free software formats because right now.
OrCAD - gEDA has this in a limited way (I have never used it). It should get cleaned up and moved to EDAcore so KiCAD can use it.
EagleCAD - CERN is writing import for this into KiCAD but we could move that to EDAcore and add export which would help entice more of the open hardware community to migrate
Protel - The published their file format spec but no one has written a library to interpret it.
Altium - Unlike the others they keep their format closed so we are all waiting on this I guess. http://hackaday.com/2014/10/15/reverse-engineering-altium-files/

PS: The QUCS talk was really good. Even if you don't care about gEDA or KiCAD you might want to watch it.
PPS: In case you think I am just waiting for others to do the work keep in mind I have been quietly working on something for a little while. I will release it when I feel ready. It should ultimately change openocd, gEDA and KiCAD but in a more minor way.

http://edacore.org

I asked in the IRC channel, but it seems inactive with only three people.

Regards.

[ScribblesOnNapkins]

For some of the reasons I described in the last thread took hold and ground things to a crawl if they are in fact moving at all.

For those who want a quick summery of what killed it.
*Kicad - is trying to clean up the underlying concept of how it handles a schematic in eeschema. I think they are also trying to work out how to do hierarchy and a few other things geda already has. (someone on the kicad side should really say more, I am on their users list but not their internal dev one)

*gEDA and Friends - one of the and friends PCB has the same fundamental problem as eeschema, no clear concept of what a PCB is. We already have hierarchy but our development slowed for a number of reasons and some of us are trying to move it forward again. gEDA and friends started before doxygen existed, we are hoping with added documentation and a few sexy new features we will pull in some added talent. Most of our existing talent got the suite to the feature set that suited them and then settled in on developing a library of symbols and footprints.


(I am still working on my thing but the re-awakening of geda's development is eating more of my free time)

[ScribblesOnNapkins]

I can't fix kicad's eeschema issues but if geda can get pcb in order than we can consider making footprints and later whole layouts portable.

[Bassman59]

For those who want a quick summery of what killed it.
*Kicad - is trying to clean up the underlying concept of how it handles a schematic in eeschema. I think they are also trying to work out how to do hierarchy and a few other things geda already has. (someone on the kicad side should really say more, I am on their users list but not their internal dev one)

Kicad does hierarchy well, actually.

There are, as I can see, (at least) two main tasks set out for eeschema after the upcoming stable is released:

• Moving the schematic symbol libraries over to the "library tables" concept that's in pcbnew.
• Embedding symbols added to the schematic instead of caching them in a separate file. This will make designs easier to share.

[ScribblesOnNapkins]

Apologies Bassman59, I read that it was something on the todo list in kicad's doxygen. What else on that list is not current?

For geda embedding symbols is an optional thing.

The following is what I was basing my comments on. I think I also got the same general picture a few months back from some of the kicad devs.

http://ci.kicad-pcb.org/job/kicad-doxygen/ws/Documentation/doxygen/html/md_Documentation_development_road-map.html

"Coherent SCHEMATIC Object

Goal:

Clean up the code related to the schematic object(s) into a coherent object for managing and manipulating the schematic.

Task:

    Move most if not all of the code from SCH_SCREEN to the new SCHEMATIC object.
    Add any missing functionality to the SCHEMATIC object.

Dependencies:

    None

Status:

    No progress.

Hierarchical Sheet Design

Goal:

Create a more robust sheet instance design rather than recreating them on the fly every time sheet information is required.

Task:

    Choose a data structure to contain the sheet hierarchy.
    Create helper class to manipulate the hierarchy data structure.

Dependencies:

    None

Status:

    No progress."

[ScribblesOnNapkins]

I was asked off list what my ideas on the direction of this would be. I have some but honestly I already spent a while talking to both groups and we got collectively no where. People were receptive and a lot of ideas were shared. If you want to see mine or other peoples please just look at the archives for geda-users (delorie) and kicad users (yahoo). I don't feel like reposting stuff here.

[ScribblesOnNapkins]

EDA Core did get a wiki but I am basically the only one to post anything on it. ( a rundown of documentation of other CAD suites file formats as a reference.)

[timofonic]

Are there some new interest in this?

[ScribblesOnNapkins]

It is stalled.

KiCAD rightfully went back to focusing on their own stuff.

gEDA went through some internal turmoil.

EDAcore will probably resume but when I can't say.

[timofonic]

It is stalled.

KiCAD rightfully went back to focusing on their own stuff.

gEDA went through some internal turmoil.

EDAcore will probably resume but when I can't say.

gEDA situation is totally insane. It's even worse than my crazy teenage days, but with extreme geeks involving. What's happening?

It's a shame, because I like diversity. I would love pragmatic code reusability, so that things would be easier for everyone.

I think EDAcore should focus very strongly on file format parsers, providing it in an application agnostic way. I mean something similar to The Document Liberation Project

Apart of typical propietary schematic and PCB formats (Altium, OrCAD, PADS, MultiSim, Eagle, DipTrace, Zuken ones...), there's ODB++, ODSII, IPC-2581...


Who knows, maybe it's possible.

Maybe a LGPL/MPL set of libraries for this could even attract contributions from even propietary EDA developers.

Maybe EDAcore started with a too wide focus? What about a subproject just about file format liberation?

Electronics File Format Liberation?
Electronics Liberation?
EDA Document Liberation?
(I run out of ideas)


With the own domain, a strong manifesto, working stuff and negotiate again with more EDA software.

And....

blablabla is part of EDAcore Initiative blablabla...

[ScribblesOnNapkins]

I started to write the story of geda from birth to death when I realized how late it was. At the 7th paragraph when I realized that talking now was risking our current quasi stable politics.

gEDA is painfully close to getting a small band of leaders with authority to fix things. (I am a proposed member.)

[ElektroQuark]

I would like to read that.

[timofonic]

I started to write the story of geda from birth to death when I realized how late it was. At the 7th paragraph when I realized that talking now was risking our current quasi stable politics.

gEDA is painfully close to getting a small band of leaders with authority to fix things. (I am a proposed member.)

I want a bilingual giveaway "thesis" to my vocational school and part of that is going to be about gEDA. Are you going to mention Atari days?

Maybe we can collaborate, excuse me for my poor English.


There's these emails I've sent to both KiCad mailing lists:

Hello.

I wrote this as a very early draft in order to understand KiCad better and the planning of the project.

I'm sure it's highly inaccurate, full of mistakes and written in a not so good English.

This is part of my personal project to understand KiCad, some inaccurate research notes and personal ideas I would like to refine.

Any feedback (corrections, suggestions, information sources...) will be very welcomed.

I would like to know opinions about it, inconsistencies and other ideas. I would like to research about KiCad history and involved developers in a detailed way too, if the KiCad Team agree on it.

I plan even to persuade the teachers in my vocational school to make this possible Spanish/English article as homework.

It will be about:

- Software: KiCad, other useful tools such as QUCS.
- FOSS: Importance in society and what can provide to electronics.
- OSHW: Explaining historical roots, such as homebrew computers and the classic hacker culture, plus current trends.
- Advantages in learning electronics by using: Copyleft learning material, FOSS/OSHW communities, forums and mailing lists, videoblogs.
- Active Learning in electronics.

My basic understanding about the development of KiCad:
----------------------------------------------

I see KiCad is manpower limited and needs to complete certain goals and not waste resources.

I think to understand KiCad have very important tasks to be done to be future proof:

- I understand KiCad needs desperately a massive and careful refactoring. 
* Maybe there's still too much cowboy coding and stuff to clean before implementing important but complex features.
* Maybe part of that refactoring could help making the code easier to understand to new developers. 
** This would mean following somewhat strict and defined coding practices, very documented code and other stuff developers are aware of it for sure.

My understanding about potential KiCad sectors
-----------------------------------

- Hackers: People very enthusiastically interested and active in electronics and programming field that just would like to participate in a community project. 
* They can be programmers with interest in electronics, even being very skilled professional programmers donating part of their spare time.
* They can be in the electronics field but interested in programming too as a secondary field to explore.

- Hobbyists/Makers: Some already switched from Eagle to KiCad, but many of them switched to free but vendor lock-in alternatives or may encounter some barriers: Interoperability, UX, performance on low end computers.

- EEs: They are used to many high end solutions such as Cadence Allegro, Altium, OrCad and others.
* They might be very used to certain features and/or workflows, probably more in very complex designs. 
* Reach these goals are very difficult to do, but not impossible if the project grows.

- Companies, educational sector, NGOs:
* Organizations don't wanting to spend big sums of money in EDA software or unable to afford it, even using old versions or illegitimate ones.
* They might have developers in their organization. In other cases like certain countries, they could hire one for less than the license cost.
** This way they may be able to contribute to make KiCad match their needs and even finally reduce costs. And avoid illegitimate practices, too.

Some goals I personally consider important:
----------------------------------------------

* Advanced and reliable file format interoperability: Deal with it, the situation is even worse than Office suites and needing to redo projects might unmotivate many people.
* Usability: People are already extremely used to common practices and features in popular propietary software. 
** I don't see pragmatic to be the small guy in town fighting against the big ones, I believe a different strategy should be done. 
** I think  behaving more like them and not look too different might be better in a logic and comprehensive way by "copying" the good usable stuff and avoid the bad ones. 
*** Maybe it could make transition easier. I think LibreOffice does it in a smart way.

* Very powerful scripting capabilities and a central repository, even trying to surpass capabilities of high end and mid end EDA software.

* Easy collaborative Edition, providing visual diffs and other stuff.

My defense on "Release early, release often"
------------------------------

- Release incremental releases with minor and less bug prone but useful changes could give more sense of activity. 
* This could provide more stimulation to users about the project, having new things to use and explore. 
** You can think about it as giving small gifts to keep interest in following new versions.
* I think this could enhance the community feeling and promote a more active participation.
* People like to see new things, it's something wired in our brains.
* Because of these minor but interesting releases, there could be more media exposure and work as a form of marketing.

- Having two branches: stable and experimental
* This could be done until the refactoring gets done. The stable one would just provide these small updates as minor improvements.
* Would this require too much extra work?
* Can it be done without interrupting the mainline important future proof branch?

Thanks in advance.

Kind regards.

Hi,
nice analysis!



> I think to understand KiCad have very important tasks to be done to be future proof:

> - I understand KiCad needs desperately a massive and careful refactoring.
> * Maybe there's still too much cowboy coding and stuff to clean before implementing important but complex features.
> * Maybe part of that refactoring could help making the code easier to understand to new developers.
> ** This would mean following somewhat strict and defined coding practices, very documented code and other stuff developers are aware of it for sure.

That is all true, but.. it 100% applies to all projects I worked / am working and that is maybe the "rule" unfortunately.
I once read somewhere that we are still in the early stages of software development. The humanity still dont have 100 years of software development so there are still lots of questions how to solve this issue with softwares. That will be the holly grail solution.

I estimate that such type of a task like that in a project like this would need a year or more of work with a team in the same room re-designing and re-writing the software (from scratch?).
During this time, no new support can be added (or it need to be merged or rewrited again in the end... )

That is a problem unfortunately for real companies / products: "we cannot stop to make a refactoring of the software, because we must continue to support and ship the product !".
And this is a nightmare for developers :/

The good thing here, is that KiCad is not a company so there is no problem to stop "shipping the product"
That is a point you can explore in your "thesis" and evaluate the pros/cons etc..

Cheers!
Mario Luzeiro

[ScribblesOnNapkins]

I can not post that right now. Things are just calming down.

gEDA did not start on atari. PCB did. Later on gEDA and PCB developers got together because most of them were users and at the time gEDA was the only open source schematic capture and PCB was the most modern layout tool that was open source.

The trouble with EDA core is not one of file format. People have this idea that we have no good way to represent the data when it is stored. That is not true. The real issue is the layers above it. Look at the number of translation utilities between gEDA and Orcad or geda and kicad. The real issue is how you represent the data after the file is read because you want some kind of data structure that can elegantly be read by functions to do 3 different things.
1. Make a netlist
2. Make a 2D drawing. (for a schematic)
3. Make a BOM

gEDA in it's start embodied the ideas of EDAcore in that it was not distributed as 1 package but as a family of them.
libgeda - library to handle schematics
gschem - program to manipulate schematics graphically
gattrib - program to tweek symbol attributes in a spreadsheet
gnetlist - prgram to make a netlist from a schematic
and etc.

For users this was a pain but the intention was for 3rd parties to use libgeda to write stuff that used our file format and etc. libgeda's functions had a reasonable amount of documentation and example code to let you do this.

In the here and now I am hoping we kind of return to that model. I would like gEDA to have an interface to KiCAD's libraries it can natively support their symbols and vice versa. Then we could collectively move on to doing the same thing for Eagle. Later we could do the footprints.

Schematic support is not really possible as I see it. At least not in a way that would work cleanly. There would always be translation issues.

[timofonic]

I can not post that right now. Things are just calming down.

gEDA did not start on atari. PCB did. Later on gEDA and PCB developers got together because most of them were users and at the time gEDA was the only open source schematic capture and PCB was the most modern layout tool that was open source.

The trouble with EDA core is not one of file format. People have this idea that we have no good way to represent the data when it is stored. That is not true. The real issue is the layers above it. Look at the number of translation utilities between gEDA and Orcad or geda and kicad. The real issue is how you represent the data after the file is read because you want some kind of data structure that can elegantly be read by functions to do 3 different things.
1. Make a netlist
2. Make a 2D drawing. (for a schematic)
3. Make a BOM

gEDA in it's start embodied the ideas of EDAcore in that it was not distributed as 1 package but as a family of them.
libgeda - library to handle schematics
gschem - program to manipulate schematics graphically
gattrib - program to tweek symbol attributes in a spreadsheet
gnetlist - prgram to make a netlist from a schematic
and etc.

For users this was a pain but the intention was for 3rd parties to use libgeda to write stuff that used our file format and etc. libgeda's functions had a reasonable amount of documentation and example code to let you do this.

In the here and now I am hoping we kind of return to that model. I would like gEDA to have an interface to KiCAD's libraries it can natively support their symbols and vice versa. Then we could collectively move on to doing the same thing for Eagle. Later we could do the footprints.

Schematic support is not really possible as I see it. At least not in a way that would work cleanly. There would always be translation issues.

I understand it. There must be a momentum and avoid history to not be repeated again. A constructive critique is necessary for improving the current environment.

FOSS really needs a disruptive change to make FOSS a lot more interesting and avoid oligopolies with very limited focus.

The Document Foundation is ac very good example. There needs to forgive about competition and share all of the possible resources.

- Why just modularize gEDA suite? What about the very best of both KiCad, gEDA other electronics open source projects?
* A common and scripting framework with a good refactoring could be done, making electronics a more collaborative and powerful firm on it too.


There would be separated projects, even the the actual ones. But code would be massively saved, because reusing it . A common format is preferable.

What's so difficult about to read more schematic file formats and convert/parse then incorrectly? I supposed it to be the pcb file, I would like to know it.

I guess C vs C++ could be a lot of controversy between both KiCad and gEDA projects

[ScribblesOnNapkins]

C/C++ is not an issue. Actually DJ and others have long wanted to make the code of PCB more C++ in feel. A larger fight inside of gEDA is Scheme and Python. We have an optional alternative netlister in the next release that adds python as a dependency which has been controversial.

As to your thoughts about the other issues regarding parallels to office suites, file formatting and etc. You are obviously a smart person but you need more experience in the guts of a CAD program to understand the scope of some things. KiCAD took a very different approach on a number of levels that make our codebases very different in architecture. I am not making a judgement here. gEDA's architecture has some things I don't care for too. Blending the two would be a larger project than ether of them individually.

The Document Foundation is a good example *now*. They had a lot of internal struggles early on.

[timofonic]

C/C++ is not an issue. Actually DJ and others have long wanted to make the code of PCB more C++ in feel.

I'm pleased to know they are interested in C++. Many projects are too old-school and hate OOP.

A larger fight inside of gEDA is Scheme and Python. We have an optional alternative netlister in the next release that adds python as a dependency which has been controversial.

I did see that alternative netlister as a very interesting project. Unfortunately, some conservative people attached him.

I don't understand that Python vs Scheme fight. I think Scheme may be a good programming language, but not an easy one. Python is easier and a lot more widely used.

KiCad people have been working about improving Python scripting:
https://github.com/KiCad/kicad-python

[quote author=ScribblesOnNapkins link=topic=50684.msg757233#msg757233 date=14425123EDA
As to your thoughts about the other issues regarding parallels to office suites, file formatting and etc. You are obviously a smart person but you need more experience in the guts of a CAD program to understand the scope of some things.
[/quote]

Despite TDF has a lot more resources than most known FOSS electronics software, they are always blaming about the lack of resources. A reason their mathematical part lacks some stuff send due to that and not being a mainstream demand. Real geeks seem to use LaTeX for that.

I have tons of stuff to understand, not just CAD/CAE/EDA stuff

I fail to understand the scope of too many things, this one too. Are there some article, paper it document explaining it in some way?

KiCAD took a very different approach on a number of levels that make our codebases very different in architecture. I am not making a judgement here. gEDA's architecture has some things I don't care for too. Blending the two would be a larger project than ether of them individually.

I hope this doesn't end in something similar to Linus Vs. Tanenbaum. You know what I mean. Everyone losses at the end.

What are those architecture differences? Are there at least some overall comparison about them?
Are the involved parties so stubborn to be unable to reach a rational and reasonable consensus? That's a big problem of humanity, but I hope ACTIVE people on both parties get able to reach some kind of agreement someday.

I understand it might be a titanical task to do, but I think it would improve the FOSS EDA ecosystem in a very exponential way.

gEDA even uses GNU Triangulation Surface library (GTS), an unmaintained project since years. Someone said the software is "complete, but other said: " Probably not. Triangular meshes are surprisingly tricky and current
version 0.7.6 does not suggest stability. There seems to be a lot more maintained alternatives. I'm not sure about features, but they seem we powerful:

 http://www.cgal.org
http://www.openmesh.org
http://www.salome-platform.org
https://github.com/tpaviot/oce

The Document Foundation is a good example *now*. They had a lot of internal struggles early on.

SUN managed the project in an awful way. Oracle bought it and they did distrust the new owner even not than SUN.

The fight made possible the LibreOffice fork. Oracle responded in an hostile way because they really hate FOSS even more than SUN (do you remember about CDDL controversy).

After the OOo debacle and the fork started to surpass the original, Oracle and IBM " donated" their code to Apache.
 Fortunately SUN used a copyleft license instead their CDDL trap (incompatible with GPL) license in OOpenOffice

They relicensed to the propietary-friendly Apache License clearly as a marketing strategy and probably use it as a cheap coding resource for their property derivatives and promote Java (Apache Foundation? They're more of a Java and BSD-like licenses) but finally LibreOffice won in an extreme way and Apache Office is now just a known zombie just some stubborn users still use.

I'm sure there were a lot more problems than that. But if they succeeded, I have hopes on this.

[ScribblesOnNapkins]

More on C/C++ the code used in geda proper is a lot of gtk+ and glib calls. Those libraries were kind of written by people who wanted to use C++ but in C.

Xorn has it's issues fitting into the rest of the codebase but people are working on that.

The original developers love of scheme is IMHO one of the reasons for the projects floundering. For a few reasons it is more convenient to code netlisting functions in a language other than C but that means added developers need to be bilingual and most hardware people (like me) do not like python. It is hard to find people who actually understand the issues that come with writing a cad program and even harder to find the subgroup of that group who understand scheme. I know the CS people think all programming languages are ultimately progressing into LISP but it is not a very practical language for these purposes.

Python to me feels like Perl did in the early days, it is the start of an idea but not fully thought through. I feel like it is one in a series of languages being developed that are heading in a direction. I see a lot of CS people going from perl (10years ago) to python (last 5 years or sooner) to ruby. Eventually something will replace ruby. We are writing code "for the ages" meaning that it has to be built to last and well C is not an ephemeral language.

gEDA has never blamed anything on a lack of resources as far as I can remember. I mean there are times when we might say "I can't do that right now" but that in truth as a few different meanings. Perhaps one of the most problematic issues for geda devs is the number of users who repeatedly ask (demand) a feature that honestly we *don't* want.

Linus vs Tanenbaum (linux vs minix) was not a bad thing. Some things are settled in architectural discussions others via evolution/competition. This is more like Jazz music, people playing off each other. IMHO having kicad and geda separate is actually good for everyone. Both ideas of how the design should be done are getting explored and questioned. Linux vs Minix was always stupid because it was not really about engineering. People like Linus, he is a hero but the reality is that he and Tanenbaum are frequently abrasive from what I have been told.

gEDA does not use GTS you are thinking about PCB which is a partner project. One thing to know here is that because gEDA and PCB are separate but associated projects there are small feuds between the two. I am on the gEDA side while DJ is on the PCB side. I have a lot of respect for DJ but even he has to admit there are limits on the future growth of both programs because of decisions that were made early on. I have been pushing a documentation project like the one brlcad went through a while back. GTS might be unmaintained but it's bugs have yet to actually effect us. It is used in the DRC which also generates the netlist used for back annotation and ratline stuff. I can't say more because honestly no one (including DJ) actually understands that code any more. gEDA would like the PCB folks to clean house a bit, PCB would like gEDA to accept more new code even if it is not of as high a standard as they would like. There is also a running disagreement about how back annotation should be done which is complicated by the fact that gEDA supports multiple workflows with things other than just PCB, a fact that the PCB people can dismiss too quickly.

gnetlist lets us use drive pcb, allegro, liquidpcb, mathematica, protel, switchcap and generate verilog, vhdl, systemc and..... a lot more.

Yes I know about these I too have google and for work did some multiphysics stuff at one point. Please don't just google stuff and post it. Answering this is not a good use of my time.
Openmesh is used for fluid dynamics and other related work on physics and mechanical problems. Like GMSH. It is intended to do things like let you load, mesh and pass models in 3D into programs like OpenFOAM. The same is true of CGAL I think.
Salom-platform is just someone's stuff to sit on top of opencascade.
Opencascade has it's own issues with it's developer / user communities. That fight caused the creation of it's community edition and later a change in how dassault sys. manage the project. Opencasecade has taken a long time to adopt a true gpl compatible license. Plus it is really a 3D thing for mechanical cad.

You seem to understand a lot more CS than you do EE. The thing about EE CAD is that the key property of things is how they are connected, the mechanical stuff is just attributes of the connected features. Mechanical software is written the other way around and is for the most part not viable.

I knew people who were involved in The Document Foundation. It was bigger than the change over in ownership. Although I was/am a big proponent of what SUN. They were for CS people what HP Labs was to EEs.

[ScribblesOnNapkins]

The best and worst thing to ever happen to gEDA was the creation of KiCAD.

With KiCAD in the picture all the users who were harassing us to make gEDA & PCB more like Eagle had someplace else to go. We lost a few developers I think but they were people who were minor contributors to begin with.

The bad side for gEDA was CERN picking KiCAD and throwing their programmers time at it. The problem here was the blow to the communities moral.

Again this is all IMHO.

[timofonic]

@ScribblesOnNapkins

I'm sorry. Anyway, the massive forking of gEDA and the flaming at geda-users doesn't help too.

They are using languages that aren't popular. These days it's better to use C++ and Python.

Anyway...

Are there hope about something to happen at FOSSDEM?

[ScribblesOnNapkins]

@Circuiteromalaguito

It's ok. Since my last post a few things have happened. C++ is not that popular among people working on Linux or most of the BSD's. Torvalds for example famously declared that the kernel would never move to C++. This is going to sound really elitist but there is a curve between the ease of a language and the average quality of the programmers using it.

The forking is not a bad thing. Igor2's fork IMHO embarrassed a lot of the other developers into behaving productively.

1. There was a whole anti-fork movement to pull viable code into the mainline of PCB.
2. A number of new backends to gnetlist have been written by John Doty which enable you to do things like verify people have not used symbol slots correctly. He also did another one that generates Makefiles to drive the suite via schematics. The idea is for users who want to use the Automation (the A in gEDA) with out opening a text editor and draft a makefile.
3. Igor2 in his own fork
3a) implemented back annotation (notation really) with a cool video.
https://archive.org/details/pcb-rnd-back-annotation
3b) A cool parametric footprint generator.
3c) Minicut which uses an massively better algorithm for finding shorts between nets
3d) GPMI which enables the use of way more languages for plugins in pcb-rnd.
4. We have a new unstable release of geda-gaf with some cleanups, corrections,
5. We have a general consensus that scheme needs an alternative.
6. There is an accepted proposal to have a backend that lets you pull more info from the schematic into the pcb layout. So you would be able to label a trace as needing a specific kind of routing. The idea being that you could label a trace as needing to be a given width/current rating or that it should be done via a matched impedance or as a differential pair.

FOSSDEM mostly depressed me when it was announced again. I can't help but reflect on how incredible our optimism was then vs now. Still

[timofonic]

@ScribblesOnNapkins

What's wrong with FOSSDEM? gEDA can attend and I hope there's mutual code sharing between both projects. I see it as a win-win situation.

[ScribblesOnNapkins]

Oh nothing is wrong with FOSSDEM. I am just sad about the 1 year mark passing and progress of gEDA.

[timofonic]

Any news about this?

[ScribblesOnNapkins]

gEDA has some internal news but to my knowledge EDAcore has no news.