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.
For example:
9 files starting with specctra
47 files starting with class
29 files starting with pcb
I know you cant sort directly like that, but it gives a bit of an overview.
Anyway, I just wanted to see what anyone thought about it, if a renaming
was to happen, a good time for something like this might be around the
same time.
-Kristoffer
On 01/09/2018 04:08 PM, Wayne Stambaugh wrote:
On 1/9/2018 10:01 AM, Kristoffer Ödmark wrote:
Quite a bit of files under the root directory that could benefit from
some sorting as well :) Would be two patches then, one for renaming, and
one for sorting them somehow, both kinda large.
Maybe move classes to a folder called classes?
Please do not do this unless you are grouping related code such as the
swig/ folder in pcbnew/ or the netlist_exporters/ folder in eeschema.
-Kristoffer
On 01/09/2018 02:59 AM, Wayne Stambaugh wrote:
On 1/8/2018 8:06 PM, Chris Pavlina wrote:
Hi,
Soonish, I'd like to go through and rename header files to actually
match the names of the classes they define. It's a bit...unobvious that
PCB_EDIT_FRAME is in wxPcbStruct.h, for instance. Now, because this
would be a pretty large patch, I'd normally hold on until after 5.0 is
released, but I think it'd actually be best to get this in BEFORE 5.0,
because moving that many things around immediately after 5.0 would draw
a line in the history through which bugfix backports onto the 5.0 series
become difficult. The very end of the 4.0 series seems like a perfect
place. Because it's just a (large) rename, I think it has a relatively
small likelihood of actually breaking anything - either it compiles or
it doesn't, no change in functionality.
Wayne, would you be okay with this?
Chris,
I'm OK with this since it's not really a code change. I agree that it
makes more sense to do it now rather than to wait and create major
headaches when back porting bug fixes from the v6 development branch.
Thanks,
Wayne
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
_______________________________________________
Mailing list: https://launchpad.net/~kicad-developers
Post to : kicad-developers@lists.launchpad.net
Unsubscribe : https://launchpad.net/~kicad-developers
More help : https://help.launchpad.net/ListHelp
