kicad-developers team mailing list archive
Mailing list archive
Re: Hoping to contribute but I have some questions
Thank you so much for the offer!
My code is here: https://github.com/BrianAtDocumentedDesigns/RenumKicadPCB
It needs to be seriously reworked in order to incorporate into Kicad because of the way it works.
I read in the project sch, pcb, and netlist files. I scan the PCB file and create a list of components. Then I do a "rules based" sort of the components, create a was/is list, and essentially do a "search and replace" on the .sch, .pcb, and netlist files. This involves recursing through the root schematic, which is a little tricky. This means the code is highly dependent on the file formats and does not update times stamps, etc.. Nevertheless, the utility has been downloaded a fair number of times. I no of no non-Kicad related issues. I apologize if the code is not up to professional standards but I try.
I believe it would be very easy to adopt the code to fit into Kicad entirely. Instead of parsing the PCB and sch file formats I could use the built-in Kicad structures, and instead of doing a text search and replace I'd update the structures as is done in Annotate or Edit inside Kicad. So I'd have to go from c to
c++ coding but also tie directly into eeSchema and PCBNew and using the objects and functions. Since much of what my utility does is already inside Kicad its just a question of figuring out where the existing functions and structures are and using those (of course, since I am used to c, and not c++, my terminology is all wrong but I am sure you understand what I mean).
My initial thoughts were to modify PCBNewto write a was/is file then modify eeSchema to use that was/is file to re-annotate the schematic. That could, of course result in file coherence issues. The Kweilin approach would greatly simplify this since I would not have to add a new file formation and require the user to run a command in PCBNew then run another tool in eeSchema. On reflection, it did occur to me that a similar approach might allow forward/backward annotation (i.e. a change to the schematic reference designation being immediately reflected in the PCB and vice versa) but that is another thing to think about. I am having trouble finding KiwayMailln source but I'll figure that out.
How I am going to do this is, of course, evolving. In the past I discovered you really don't understand a problem the first time you solve it. Since this will be my second go around, I'll probably do it better but I'll only understand the approach after I have studied the PCBNew and eeSchema source. Based on my analysis of eeSchema, despite my limited grasp of c++, I can see that updating the schematics annotation is quite straightforward from inside eeSchema - its basically the annotate function except, instead of generating a new annotation I incorporate the was/is information. I have to study PCBnew to figure out how to extract the component information and relay that to eeSchema (presumably by KiwailMailln). The sorting, etc., is already written in my utility, so I'd just have to rewrite that in c++ as necessary.
If you give me a day or so I'll be delighted to send you example of my dialogs. They are very simple - quite similar to the annotation dialog in eeSchema.
From: Tomasz Wlostowski <tomasz.wlostowski@xxxxxxx>
Sent: January 4, 2019 6:19 PM
To: Brian Piccioni <brian@xxxxxxxxxxxxxxxxxxxxx>; 'KiCad Developers' <kicad-developers@xxxxxxxxxxxxxxxxxxx>
Subject: Re: [Kicad-developers] Hoping to contribute but I have some questions
On 04/01/2019 18:51, Brian Piccioni wrote:
> I am still keen to attempt to incorporate geographical component annotation into KiCad. In general, it is preferable for component annotation to be done relative to the PCB and in some logical order (left/right, top to bottom, etc). Thereafter this information is imported to the schematic. I wrote a standalone utility (RenumKicadPCB) which does this but ideally, we’d want the function built into Kicad.
> I understand this would be viewed as a “rogue effort” but lack of geographical component annotation is a major missing feature and my hope is that if my code works the developers might consider adding it or something like it into the project. Otherwise I’ll just maintain my own variant of the two affected applications for limited use.
> I am not used to working in c++ or working on large projects. Nevertheless, I figured I’d give it a try. I have been studying the source for a few weeks and have developed a strategy which would be very simple to implement if I had more skill/experience.
> The first thing I want to do is to add the ability for eeSchema to import a “was/is” file to update schematic annotation. Since renumbering the PCB can be done manually or with a plugin this seems like a good first step. Since an annotation function already exists in eeSchema, all I would have to do it provide an option for replacing annotation with a was/is rather than the annotation generated by eeSchema’s annotate function.
> I see a clear path to doing so however, the scope of Kicad and my limited experience with c++ and large projects mean it is not going to be easy for me. I am not that adept at navigating Doxygen files so I have a few questions regarding the source code (these are limited to eeSchema at the moment).
> 1) Where are the file IO functions? I have searched for (for example) LoadProjectFIle and find the prototype but not the actual function. Similarly I find the prototype for SaveEEFile() but not the actual function.
> 2) I would like to copy as much of the existing code and dialogs as possible (i.e. make new dialog based off another dialog) but when I open, for example, dialog_annotate_base.h I see
> // C++ code generated with wxFormBuilder (version Jun 5 2018)
> // http://www.wxformbuilder.org/
> // PLEASE DO *NOT* EDIT THIS FILE!
> But I can’t find the “source” from which this file is generated. Where is it?
> 3) There is a guide on the Kicad documentation “Tool framework” which describes adding a tool to PCBNew. Is there a similar guide to adding a tool/function to eeSchema? How do I go about this?
Others have already answered to your questions so here's my offer: I believe geographical annotation is a very useful feature so I can offer a bit of my help. Point me to:
- the latest sources of your tool,
- a sketch of the user interface (dialogs), can be a hand-made drawing
Once I have this information, I'll try making a basic port of your code to Kicad codebase to the stage where you could take it over and contribute further features/fixes on your own.