On 08/12/2012 03:34 AM, Miguel Angel Ajo Pelayo wrote: > > > 2012/8/12 Lorenzo Marcantonio <[email protected] > <mailto:[email protected]>> > > 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. _______________________________________________ Mailing list: https://launchpad.net/~kicad-developers Post to : [email protected] Unsubscribe : https://launchpad.net/~kicad-developers More help : https://help.launchpad.net/ListHelp
