kicad-developers team mailing list archive
Mailing list archive
Re: Decoupling issues with python
On 8/13/2012 4:29 AM, Lorenzo Marcantonio wrote:
On Mon, Aug 13, 2012 at 10:01:18AM +0200, Miguel Angel Ajo Pelayo wrote:
but may be BOARD and "schematic file" have a common ancestor that can hold
the method to get the filename?
There is a base class with an accessor only, the filename is get/set
separately (usually during I/O). Then there is the PCB_FRAME and the
SCH_FRAME (idem for the SCREEN). For eeschema it is more complicated
since there are many SCREENs (one for sheet); if the SCREEN and FRAME
are view/controller classes it is logical that the filename should go
in the model (BOARD and... well, it seems that the SCREEN in eeschema is
the model too:((((
I could try this: move the filename from BASE_SCREEN to SCH_SCREEN (thus
leaving eeschema unfazed and still correct since SCH_SCREEN is the
eeschema model), and then adding it to BOARD; a quick grep
shows that the filename in pcbnew is not required very often and most
probably the BOARD would be available near there.
(this refactoring reminds me a binary tree balancing act :P:P)
Welcome to the party! I have been fighting BASE_SCREEN almost from the
beginning of my involvement with the project and I'm not the only one
who has had to wrestle with this class. The problem with BASE_SCREEN is
it contains both view and model code. This really rears it's ugly head
in Eeschema. What I think needs to happen is that all of the model code
needs to be ripped out of it an placed in the appropriate model class.
Unfortunately there is no model class (in the traditional sense) in
Eeschema. I have been slowly refactoring the Eeschema code over the
years in an attempt to get us to the point where we can finally make the
transition. The Pcbnew scripting support may finally require us to bite
the bullet and fix the problem once and for all. In the short term you
could add all the board related model items that are currently stored in
BASE_SCREEN to BOARD. Since there is no scripting support for
schematics at this point, you should be fairly safe. This way you don't
break anything in Eeschema and you solve the BOARD scripting dilemma.
If you chose to go this route, please add a note in BASE_SCREEN to
indicated the members not used by Pcbnew as a courtesy to other developers.
At some point I will get around to (unless someone beats me to it)
creating a SCHEMATIC model object and remove the last bits of model code
from BASE_SCREEN. I was tentatively planning on finishing it before I
implement the new s-expression schematic file format. Given the
difficultly I've being having trying to find the time to finish the
Footprint* methods for the PCB_IO plug in, it wont be anytime soon.
Once the SCHEMATIC object is written, BASE_SCREEN should probably be
renamed to BASE_VIEW_SETTINGS ( or VIEW_SETTINGS since I've never been a
big fan of the BASE_ prefix ) which is all the code that will be left in
this object. From there you can derive PCB_VIEW_SETTINGS and
SCH_VIEW_SETTINGS to handle any board and schematic specific view
settings as required.
As you continue to make your way through the code base, you will find
more problems like this. If you would have done this five years ago,
you would have found a whole lot more of them. I personally have spent
considerably more time fixing the underlying design issues than I have
implementing new features. I suspect this pattern will continue for
some time but we are making progress. While fixing design issues is not
very glamorous and not visible to the end use, it is always welcome and
appreciated by the developers who come after you.