At the moment I would like to have a high level description of Eeschema’s software architecture. The idea is to see a bird’s eye view, so to be able to understand it on a high level first, so it will be easier to know where to look in the source code.
If someone can tell me how to get started on this, I would appreciate it a lot.
Thanks!
Cmos
P.S. The link under CONTRIBUTE->DEVELOPERS in kicad.org is broken
First things first: make sure you register on thw mailing list and if you plan on writing any new features: discuss these plans before you write any new code. The last thing you want is to write loads of code and then find out that your approach goes against the vision of the project.
The “high-level” view in itself would be a large thing to write as there are a lot of complex interacting elements and nobody has time to maintain such a complex document that changes continually. Basically, this is handled via doxygen documentation. My opinion is that the best way to learn the code is to read it and use it.
My suggestion is that you should first try to get KiCad building on your machine. This can be a bit tricky if you’ve not done it before.
After that try fixing some “simple” bugs to start with. There are some with the “starter” tag in Gitlab which have been assessed to be suitable for a new comer - i.e. not many interacting elements at play.
After you’ve fixed a few bugs you’ll start to get an intuition for how things are generally organised, making it easier to find your way around the code.
If you have more specific questions, feel free to ask!
if this dude is not asking, I will! After taking care of a few starter bugs I did build up some knowledge about the architecture of KiCad though. But currently my PC can’t really handle its building process
How is the PCB canvas rendered?
That specific question breaks down into:
If I added new PCB_ITEM where do I write paint/plot/3d viewer polygon building routines?
Is it possible to change the render pipeline(we now have grids, crosshair and PCB elements I think, and now assume I add other kind of grids that are independent from the main grid)
I’m not actively fixing bugs in KiCad since I have little time working on it but I’m still pretty interested in understanding it and getting involved.
I’d start then with getting a PC that can handle that… Old 3rd or 4th gen i7 with 16 GB RAM and an entry-level (say, GTX780 series) GPU is more than enough.
From the top to the bottom: have a look at classes (PCB_)DRAW_PANEL_GAL (the canvas in the PCBnew window), (PCB_)VIEW (view manager & compositor for layers), (PCB_)PAINTER (actual drawing of single BOARD_ITEMs) and GAL (provides methods for drawing graphical primitives).
Start with painting on the screen - add a PCB_PAINTER::draw( your_item ) method that will draw your custom item using the API provided by the GAL class + modify the dispatching Draw method in PCB_PAINTER so that it recognizes the new item type and calls appropriate drawing method.
PS. If you plan to add new BOARD_ITEMs and hope to get these changes merged, first ask the core dev team. This is a major change to the architecture and as such it must be discussed if it fits in the project plans.
Grids are rendered directly in the low-level graphics backend (CAIRO_GAL/OPENGL_GAL). See GAL::DrawGrid()
PS2. As someone else already suggested, the best way to get in touch with Kicad’s sources architecture is through fixing bugs first or adding small features, like Qbort’s recent track filleting.
thanks for your answer — I will take time looking at the code.
I definitely will do so if I’m willing to. I will most likely just maintain my own fork if I decide to do so.
My main PC is FX8300/GTX1050Ti and a slim ultrabook level R5-3500U, both 16G RAM. But it just compiles too slow…One header changed and all 100 translation units that required it gets updated along with it. Pcbnew clean build take half an hour, linking the KiFace need almost a minute. Just too inconvenient for me ATM.
Thanks to garbage MS C++LS, I never made sense out of its ref tracing/virtual function override resolution etc.
I did do stuff like reading diffs from commits, especially with Jon’s new dimensions. That’s a complete guide to adding new item. Also did try to modify the DSN reader to see if I can add new stuff. so yeah I think I’m on a way of getting there.
Some time ago I was working on updating the “Getting started with KiCad” manual and I got as far as downloading it, getting the compiling environment working and writing a few pages. I was doing this on a 12 year old “Dualcore E6600” with a Passmark rating of 1500. Compiling the stuff took somewhere between 10 and 20 minutes and was unbearable. By out commenting a few lines however, I blocked generations of all languages except english, and that brought the compile time down to an acceptable time far shorter then a minute. Maybe between 30 and 40s.
There really is no need to do recompile all language variants on each design iteration.
Generally, adding new BOARD_ITEMs means a file format change. I really don’t encourage you to do this in your own fork, as now your KiCad will be creating files that can’t be opened in any official KiCad. This will be a real pain for you if you hit any bugs, and will make it a non-starter for anyone to consider using your fork.
Please, if you have an idea for something you’d like to add, discuss it with the development team. There are two options for how to do this:
Create a GitLab issue (feature request) and mention that you’d like to work on it. Discussion of the feature can take place on this issue before you start writing code or open a merge request.
Email the developer’s mailing list to discuss.
Note that while some of us happen to hang out here, this forum is not a developer’s forum and so you have to do one of the above instead of just discussing things here. Some of the lead developers do not visit this forum, but they may have input about your plans.
If I fix a bug on one platform (Linux, Mac, Microsoft), is it necessary for me to fix the bug on the other two platforms as well ? Or is it just as reasonable to submit the patch and expect other coders to test it on the other two platforms ?
You are not obligated to test on other platforms, however if your proposed patch breaks things on other platforms, you’ll need to work with devs who can test on those platforms to fix it.
By “work with” do you mean maintain constant communication with developers on the other two platforms until the additional issues associated with the proposed bug fix have been resolved to the satisfaction of all three code debuggers ?
Yes, that is typically what happens in a Merge Request on Gitlab. But, we don’t always test on MacOS before merging as we don’t have any CI for MacOS, so you might be off the hook for that platform (if something works on Linux and Windows, it almost always works on Mac also, but if there is any Mac specific problem it can be fixed by other developers)
I’m also interested in contributing to the project. Currently trying to get all of the dependencies set up so I can actually build it… It would be nice if there was a little more guidance in doing this or perhaps even VM/docker/Vagrant images/scripts to make it easy to get started.
If you find there are parts of https://dev-docs.kicad.org/en/build/ that are not enough guidance or otherwise don’t get you to a working setup, please mention them on the developers mailing list so we can fix the documentation!
Here are some detailed steps on building KiCad on linux. This was done back in 2019, so there may be some changes for 2021. Also, read a bit further in the replies to see some other modifications.
