kicad-developers team mailing list archive

[Miguel Angel Ajo Pelayo <miguelangel@xxxxxxx>]

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
>
>
Yes, refactoring is also needed there, too big classes are a problem,

What's PLOTTER class reponsible for exactly?



> - Is it correct that everything is compiled twice? I see that
>   a pcbnew.so is being generated... is this for running as a python
>   module (i.e. from python and not with python inside)?
>
>
Yes, it's somehow needed because of the way Cmake implements swig module
generation. First time everything is compiled for the _pcbnew.so (in a
different subdirectory), and the next time is compiled for pcbnew itself.
If we define a compilation strategy ourselves ignoring the SWIG macros
provided by cmake, that could be avoided, but not sure if it could cause
trouble the day we can build a diet _pcbnew.so without all the UI parts.


I compile pcbnew doing "make pcbnew" to avoid the _pcbnew.so compilation
while I'm working, that saves 1/2 of my time and energy.




> --
> Lorenzo Marcantonio
> Logos Srl
>
> _______________________________________________
> Mailing list: https://launchpad.net/~kicad-developers
> Post to     : kicad-developers@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~kicad-developers
> More help   : https://help.launchpad.net/ListHelp
>



-- 

Miguel Angel Ajo Pelayo
http://www.nbee.es
+34 636 52 25 69
skype: ajoajoajo