kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/13/2012 03:00 PM, Lorenzo Marcantonio wrote:
> On Mon, Aug 13, 2012 at 11:23:54AM -0500, Dick Hollenbeck wrote:
>> Anyways, I had given all this a lot of thought, because I could foresee these problems a
>> year ago or more.
>>
>> The BOARD_ACTIONS class is my preferred solution, and it diligently implemented would mean
>> scripting is easier and you also can get rid of compiling things twice, because you can
>> park the process main()s on top of the DLL/DSOs, which is what should happen eventually.
> OK, got it. It seemed to me strange that dual compilation... namespace
> or class is mostly a stylistic choice if the action has no long term
> state (this is one of the reason for my preference of multiple dispatch
> object systems contrasted to message based like smalltalk/C++/java and
> 80% of the other OO languages)
>
> For the filename issue I've done this (as I have said before):
>
> - Removed the filename from BASE_SCREEN (private variable and
>   accessors);
>
> - Put a 'compatibility' one in SCH_SCREEN to keep eeschema working. I.e.
>   it is in SCH_SCREEN directly not, it's not inherited anymore...
>   I could see that SCH_SCREEN is mostly the model of eeschema, so it
>   isn't too bad.
>
> - For gerbview I simply used a private member (since it's only used to
>   keep the last filename selected and repropose the name)
>
> - pcbnew get the filename in the BOARD; most of the access paths were:
>   (parent->)frame->screen->filename which can be easily replaced with
>   (parent->)frame->board->filename
>
> - Profit :D we can have the filename from a BOARD* and (theorically)
>   I could do a plot without even a screen or frame allocated (how to get
>   hold of that board is another question...)


Of course you should be able to eventually.   Here again below is my vision for
re-architecting the link images comprising KiCad suite.

For Pcbnew, BOARD_ACTIONS is a way to cleave off the procedural code, away from the UI
code, yet still have it exist tightly bound within the frame, just like now.

Depending on where it is instantiated:

a) as one of two base classes in the PCB_EDIT_FRAME using multiple inheritance, or

b) stand alone, near the top of the DLL/DSO. 


I foresee a number of link images: 

1) pcbnew process image

2) eeschema process image

3) pcbnew DLL/DSO

4) eeschema DLL/DSO


Eventually we may want to combine 1) and 2), yet preserve separate link images 3) and 4)
underneath a common process.

Sooner, i.e. yesterday, we want 1) to sit on top of 3), and 2) to sit on top of 4). 
Scripting wants to sit on top of 3) and 4) also.

We are not there yet, because of spaghetti.  It's the Italians' fault, really.  If we did
not have spaghetti, we would not have this problem.


Part of separating things means finding sensible boundaries, a.k.a. interfaces.

A link image boundary between the future smaller pcbnew process image (pcbnew main()
program) and its underlying DLL/DSO might be at BOARD_ACTIONS.  So BOARD_ACTIONS would get
linked into the DLL/DSO, and
then using mutliple inheritance, it becomes part of the PCB_EDIT_FRAME.

Immediately, by procrastinating the image boundary determiniation, you can inject
BOARD_ACTIONS and simply start moving functions from PCB_EDIT_FRAME into BOARD_ACTIONS. 
But only the procedural code.  All the argument gathering which is happening in the
dialogs, gets done, and then the procedural code is called in BOARD_ACTIONS to actually do
the work.

So this evolutionary separation process has you moving dialogs UP, and procedural code
DOWN.  Eventually, when you can link BOARD_ACTIONS and below without dialog or UI code,
you have the basis of your scripting DLL/DSO, and it can also then become the workhorse of
number 1) above.  You have reached a point of single compilation, and a shared DLL/DSO
which is useful for both scripting and by a thinner pcbnew process image.


Dick


BTW  BASE_SCREEN's biggest problem is that is is trying to make Pcbnew similar to Eeschema
and vice versa.  This is not helpful.  Having the freedom to evolve in separate directions
is more important at this point.  So BASE_SCREEN is no at all helpful in my view.  Also
remember that even in the final state, there are still 3) and 4) as SEPARATE link images. 
So there is freedom to do things differently, as as separate link images, there is no
value in polymorphism.  Polymorphism is only helpful when you have two similar behaviors
in the *same* link image.