[omniORB] omniORBpy + wxPython; omniORBpy + Twisted

charles bartlett csbartlett at comcast.net
Wed Jan 2 00:28:07 GMT 2008


Stephen,

I attached a file that can replace example_echo_srv.py when running the
stringified echo example from the omniORBpy examples. It demonstrates
that your suggested mechanism works and fills in some of the missing
details.

To run:
- open two terminals
- in term1 type:  python example_echo_srv_wxpython.py
you should now see the "simple button example" window; press 'Send' to
note the text window update.
- copy the IOR from term1, it starts with 'IOR:xxx...xxx'; should be
able to do this without killing the "simple button example" window
- in term2 type:  python example_echo_clt.py IOR:xxx...xxx; where you
paste in the IOR that was copied from term1; you should see 'Hello from
Python' in the text window update
- now you can mix pressing 'Send' or rerunning the term2 command as you
like to note the independent operation of the wxpython event loop and
the omniORB updates

You have to copy over the IOR everytime you restart the server, as it
changes apparently. It is easier to send this to a file and read it, but
this is a quick little example.

I like to be explicit in the above, to save time for those who are
trying these examples.

I suppose one can infer from this example that it is feasible (using the
mechanism you suggested) to drive any wxPython widget as the output of a
CORBA call from some remote client, which was my interest.

I ran the above on Ubuntu; I did not try it on Windows.

Thanks again for your instructive suggestion - you saved me some time
searching around. I hope my example will likewise be helpful to someone
else.

BTW, I did not look at the tic-tac-toe example in detail yet, but it did
not appear to use the mechanism you suggested as it does not call
wx.CallAfter.

You will also note that this example does no explicit registration of
servants with a POA, it simply extends Example__POA.Echo. So, maybe I am
missing something here.

Note that the attached file has a specific ordering of the wxPython and
omniORBpy code; violate the ordering and you may incur an error.

Charles

On Fri, 2007-12-28 at 08:24 -0500, charles bartlett wrote:
> Stephen,
> 
> Thanks for your instructive response.
> 
> As you "use omniORB and wxPython (together) extensively" and have
> provided an outline of how to use them together, I will code an example
> and ask more specific questions as they arise later. The exercise will
> be instructive.
> 
> It would be better to have a pointer to an example already constructed.
> If that is not readily available in omniORB documentation, then perhaps
> it should be. (I am not asking you to construct such an example!) By
> comparison, the wxPython demo program is very good because it
> immediately shows, with little effort, the various capabilities of
> wxPython and basically how to code them.
> 
> 
> Thanks to the omniORB developer(s) for reducing the barrier to using
> CORBA to a learning curve and for the pointer to its "simple
> explanation".
> 
> On Fri, 2007-12-28 at 00:26 -0800, Stephen Hansen wrote:
> > 
> >         I am looking for something similar for omniORBpy, although it
> >         could run
> >         in a thread other than the GUI event loop. 
> >         
> >         Alternatively, please provide a pointer to how to interface
> >         omniORBpy to
> >         Twisted, i.e. send data from a CORBA client to the omniORBpy
> >         to the
> >         Twisted framework to a Twisted server faithfully.
> > 
> > I'm not sure what you're asking, exactly.
> > 
> > 
> > You don't have to do anything special to use omniORBpy with anything.
> > You don't actually have to ever run " orb.run()" and enter an event
> > loop to use it; all you have to do is register servants with a POA,
> > and use poa._get_the_POAManager().activate(). Unlike twisted, there's
> > no separate event loop to maintain and integrate at all.
> > 
> > 
> > omniORB automatically runs in any number of threads seamlessly with no
> > effort required from you. It handles connections, spawns threads, and
> > does everything itself internally.
> > 
> > 
> > The only thing you have to worry about is having code instigated from
> > omniORB interacting with the GUI. In this case, you use "wx.CallAfter"
> > to control the GUI and send changes to it. 
> > 
> > 
> > So if you get a chunk of data in a CORBA object and want it to trigger
> > a change in your GUI, you "wx.CallAfter(self.control,argument)"
> > instead of " self.control(argument)" and the GUI will process it.
> > 
> > 
> > I can give more specific details, as we use omniORB and wxPython
> > extensively ... but need more specific questions.
> > 
> > 
> > --Stephen
-------------- next part --------------
A non-text attachment was scrubbed...
Name: example_echo_srv_wxpython.py
Type: text/x-python
Size: 1416 bytes
Desc: not available
Url : http://www.omniorb-support.com/pipermail/omniorb-list/attachments/20080102/5a18fba6/example_echo_srv_wxpython.py


More information about the omniORB-list mailing list