kicad-developers team mailing list archive
Mailing list archive
Re: Decoupling issues with python
On 08/12/2012 03:34 AM, Miguel Angel Ajo Pelayo wrote:
> 2012/8/12 Lorenzo Marcantonio <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.