[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