kicad-developers team mailing list archive
Mailing list archive
Re: Renaming headers?
Now that you say it, indeed the class prefix is kinda stupid, but at
least it helps when doing ls, since they are grouped in one place,
whatever the name after class_ :)
Sorting them by function would be the best i guess, I would suggest that
the commit(s) that is exactly where rc1 branches off be the one with
these changes, since there will be major confusion with patches otherwise.
I would lend support here, but I doubt I would be much help. But I would
very much like to see a sorting/renaming etc here, I think it would help
in attracting new devs as well, I remember getting stuck on the
Legacy/GAL stuff in the very beginning, not finding what was where.
On 01/09/2018 05:02 PM, Tomasz Wlostowski wrote:
On 09/01/18 16:21, Kristoffer Ödmark wrote:
Oh I was not planning on doing this, I am way to new to do a good job of
sorting the codebase. Just wanted to see if there have been anyone else
thinking in these lines. Currently in the pcbnew folder, the files seems
to be grouped by their names, which is also fine. I would just enjoy if
the files where grouped into folders more. there are currently 200+
files in the pcbnew root directory.
9 files starting with specctra
47 files starting with class
29 files starting with pcb
I would vote for moving the files into folders grouped by functionality.
- board/ - board model (class_board, track, via, etc) + core algorithms
(zone filling, connectivity, ratsnest)
- io/ - all I/O plugins and exporters (in separate subdirectories) +
plugin management code
- io/kicad - kicad plugin
- io/legacy - legacy plgugin
- io/exporters/specctra - specctra export code
- io/importers/eagle - eagle import code
- view/ - GAL display code
- tools/ - all GAL tools
- legacy/ - all legacy tools/canvas code
- ui/ - wx-specific user interface stuff (dialogs, frames, etc.).
If we go for separate subfolders, I'd also suggest removing the class_
prefixes from the file names. All of the new code is OOP, so each source
file contains a class (or more).
In the long term, we could also eliminate linking dependencies between
these folders (so that class BOARD has no dependency on the GUI, etc).