kicad-developers team mailing list archive

[Dick Hollenbeck <dick@xxxxxxxxxxx>]

On 08/12/2012 03:34 AM, Miguel Angel Ajo Pelayo wrote:
>
>
> 2012/8/12 Lorenzo Marcantonio <l.marcantonio@xxxxxxxxxxxx
> <mailto:l.marcantonio@xxxxxxxxxxxx>>
>
>     I have two somewhat important issues with the python binding... as you
>     know I'm implementing the plot interface.
>
>     - Decoupling the message logs: for 'big' messages we usually show
>       message boxes; these *could* be acceptable for scripting (maybe
>       a better solution would be throwing an exception...) but other
>       messages (for example the 'created %s directory') are currently
>       hardwired to the text control in the dialog... this is a clear
>       'functionality tied to UI' issue (and MVC was created to address it);
>       sadly most (if not all) the features in kicad are similarily tied to
>       the UI code.
>
>
> Yes that was the UI coupling I talked about in the previous messages (what I'd seen when
> trying to let scripting plot), some refactoring might help.
>  
>
>     This makes difficult to export stuff to 'pure' scripting.
>       Currently I'm using an optional pointer to the message log box;
>       I don't know where these messages should go during scripting (standard
>       output? is it redirected to the python console?)
>
>
> This is something we should investigate how to do. Even some scripting output now
> doesn't go to the scripting console, the scripts launched from the console itself do,
> but the ones running as plugins or other stuff don't (adding that to the scripting TODO
> list right now).
>
> May be "text output messages" should be given to an optional callback function? (this
> way if we call plotting from UI we get the text back to UI, and if we call it from
> scripting we could provide a simple printer, or fetch it somewhere to get it back into
> another scripting-built-UI or whatever).
>
>  
>
>       Ideally a 'message log' interface should be defined with a couple of
>       implementations (message box and python log/whatever); this could be
>       used also in other situations requiring progress log;
>
>
> Yes, yes, it something that worth to think about. 
>
>  
>
>     - Access to core classes: from what I've seen of the python bindings it
>       seems that the root object is the BOARD, which makes sense; sadly the
>       plot routines at the moment are in the PCB_EDIT_FRAME (like a lot of
>       the operations); another issue of feature/UI intermingling. I'll try
>       to extract them from PCB_EDIT_FRAME and put them relative to the BOARD
>       or, better yet, externally; I'm not a fan of 'everything in classes':
>       external stuff should be externally (the old OO philosophical dilemma:
>       the BOARD drivers the PLOTTER, the PLOTTER reads the BOARD or
>       something else read the BOARD and drive the PLOTTER?). Also the
>       PCB_EDIT_FRAME has already way too methods, and a diet could improve
>       it :D
>


My idea was a BOARD_ACTIONS class, which could stand alone.  The UI code and scripting
both can call functions in that class.

Then you could use multiple inheritance and put BOARD_ACTIONS back into PCB_EDIT_FRAME as
one of two base classes supporting PCB_EDIT_FRAME.  This provides for the UI close to what
is happening now.

But since BOARD_ACTIONS could also stand alone, the scripting could use it in a form
independent of PCB_EDIT_FRAME.  

That might give you the best of both worlds then.

Another nice thing about this design and plan is that it can be done evolutionary, i.e.
over time.