[wxPython-users] Adding GUI to already existing CLI framework

Stani's Python Editor spe.stani.be at gmail.com
Fri Aug 3 05:23:38 PDT 2007


Probably you need wx.lib.pubsub which is independent of wx. You can just
copy the file pubsub.py to your application in case you want to drop wx.
Stani
--
http://pythonide.stani.be

Frank Aune schreef:
> Hello,
> 
> I'm about to begin designing a GUI for an already existing CLI framework 
> written in python. And I believe its a good idea to invest some time into 
> researching implementation ideas instead of jumping straight into writing 
> code.
> 
> I do not want my CLI framework to be dependent on wx in any way, so the GUI 
> must be completely separated.
> 
> All error messages in the CLI framework are handled by exceptions, so those 
> are relatively easy to catch in the GUI. I have identified two areas where I 
> must come up with a solution:
> 
> 1. How to execute blocking code in the CLI framework from the GUI, without 
> making the GUI unresponsive. 
> 
> 2. How to signal messages and events from the CLI framework up into the GUI, 
> without making the CLI framework dependent on the GUI. I'm thinking 
> especially about progress bar updates and progress messages etc.
> 
> 
> Possible solutions for 1. I can think of:
> - Make decorator function in the GUI for threading the CLI framework
> - Make CLI framework threaded
> - Use twisted callbacks
> 
> Personally I dont like twisted callbacks in wx (never could make them work 
> like I wanted), but I'm looking for advice on the cleanest way of 
> accomplising this. I have used threads and thread-decorators in wx apps 
> before, and I'm crazy enough to actually admit I like it :-)
> 
> 
> Possible solutions for 2. I can think of:
> - Let CLI framework communicate with GUI over a UNIX socket, possibly using 
> JSON socket API.
> 
> - Use DBUS for signaling the GUI (the CLI framework deals with hotpluggable 
> HW, so I think DBUS usage is a good idea anyway)
> 
> - Have a possible GUI object reference in the CLI framework constructor ( GUI 
> = None), and then test if the GUI object exists - and if so, do signaling 
> through the GUI object reference through a self-defined API. To separate the 
> dependency on wx, I could make my own signaling layer which the CLI framework 
> calls, and then in this layer again call wx functions.
> 
> - Just let the CLI framework send out wx.EVENTS and from CLI framework POW 
> don't care if someone is listening. Then make the GUI respond to these 
> events. This will make the framework depend on wx (at least it needs to 
> import wx into its namespace and send out events), but perhaps this is an 
> acceptable approach?
> 
> I'm pretty clueless on how to accomplish this in a clean way, so I am very 
> much looking for good advice on how you guys deal with this sort of 
> challenges!
> 
> Code examples, articles, tutorials, opinions - all are welcome :-)
> 
> Thank you very much for all input, and have a nice weekend!
> 
> Best regards,
> Frank Aune
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: wxPython-users-unsubscribe at lists.wxwidgets.org
> For additional commands, e-mail: wxPython-users-help at lists.wxwidgets.org
> 
> 





More information about the wxpython-users mailing list