From dking at nrao.edu Tue May 17 11:56:17 2005 From: dking at nrao.edu (David King) Date: Tue, 17 May 2005 09:56:17 -0600 Subject: [AstroPy] python XPA module? Message-ID: <428A1421.7050500@nrao.edu> Hi folks: I'm wondering if someone has made the XPA messaging system available as a python module. As I understand it, it is used by DS9's gui process to receive user input from a user-level process. I have a viewer somewhat similar to DS9 that I'm trying to move to the python world; I need console/scripted input as well as normal responsiveness to events on the gui. I imagine a python-XPA module would be quite useful in many other contexts as well. Regards, David King National Radio Astronomy Observatory. From rowen at u.washington.edu Tue May 17 12:26:33 2005 From: rowen at u.washington.edu (Russell E Owen) Date: Tue, 17 May 2005 09:26:33 -0700 Subject: [AstroPy] python XPA module? In-Reply-To: <428A1421.7050500@nrao.edu> References: <428A1421.7050500@nrao.edu> Message-ID: At 9:56 AM -0600 2005-05-17, David King wrote: >Hi folks: > >I'm wondering if someone has made the XPA messaging system available >as a python module. As I understand it, it is used by DS9's gui >process to receive user input from a user-level process. I have a >viewer somewhat similar to DS9 that I'm trying to move to the python >world; I need console/scripted input as well as normal >responsiveness to events on the gui. > >I imagine a python-XPA module would be quite useful in many other >contexts as well. Is your viewer going to be publicly available, and if so, might you tell us more about it? The RO package* includes a DS9 module that uses xpa to do its thing. You could easily adapt it for use with other xpa apps. However, it's not as fast as it might be -- it calls the command-line xpa commands rather than linking to the C API. I also have a SWIG interface for xpa from a colleague; I have sent him email to ask him how publicly available it is and will let you know. -- Russell *available from . From dking at nrao.edu Mon May 23 14:03:01 2005 From: dking at nrao.edu (David King) Date: Mon, 23 May 2005 12:03:01 -0600 Subject: [AstroPy] Re: gui/thread issues Message-ID: <42921AD5.7050508@nrao.edu> >>>>David King wrote [private note, not a previous thread]: David> Dear Prabhu: I noticed a forum thread discussing gui David> threading, e.g.: David> http://www.scipy.net/pipermail/ipython-dev/2004-November/000299.html David> I'm asking you to have mercy on a fairly new python user. David> I want to use Tkinter and still have the python console David> remain 'live'. I have the impression you have gone far David> more deeply into this than I, and that others as well have David> thought on it. Yet I still have no solid doc on when David> tk.mainloop() is necessary and when not, on how to process David> Tkinter events while the python interpreter remains active David> to input. I have prowled around fairly extensively in a David> (so-far) vain search for the definitive answer to this. Prabhu Ramachandran wrote: > The answer strongly depends on what particular Python interpreter you > are using. Under IPython (without -wthread or -gthread) or vanilla > Python, tk.mainloop() is not necessary and in fact should not be > called if you want the console active. Even if you do not call the > mainloop, events will still be processed and your application will work > just fine. > > However, if you are running apps written with pyGTK or wxPython then > you can't get away with running a Tkinter app and not calling > mainloop. With IPython, there is an option (-wthread/-gthread) that > starts up the GTK and wx mainloops in a secondary thread and allows > for an interactive console on the main thread. In this case, if you > start a Tkinter application, it will in all probability not work. > This is because GTK and wx have their own event handling loops that do > not play nicely with the Tkinter event loop in another thread. To get > around this, IPython also provides a -tk flag that processes tk events > every so often. Now this works best only if tkinter is compiled with > thread support, if not things break badly. > > With the IDLE interpreter things are different since IDLE itself > starts the mainloop and recent versions of IDLE have some issues and > you might want to read this thread: > > http://aspn.activestate.com/ASPN/Mail/Message/edu-sig/1818398 > > > I hope I have answered the question clearly enough and not confused > you any more. Dear Prabhu: Thanks you very much for your note regarding Python-gui interaction; very kind of you. Some of what I've read on the net does add to my confusion, but definitely _not_ your reply; it is helping me piece things together. In the short run, I would be ok just using Tk alone on IPython or plain Python, although I'd be happiest having the whole picture. In the long run, our project will want to serve varied users, who will no doubt want to use python in their own way. Russell Owen also mentioned that Tkinter's 'after[_idle]' might not work without calling mainloop() explicitly; although perhaps I can do without those features, I'd certainly like to know if this is the case, and what else to watch out for of this sort.... I will continue to study what I have (that forum-thread link was helpful too--thanks). But I can't help feeling other python gui programmers must run up against this problem too, and wonder why practically all the standard Tkinter doc (including Grayson's book) just says "you gotta call mainloop() to make anything actually appear and respond in Tkinter" (manifestly untrue). I'm beginning to suspect that although the information I seek resides in various people's heads, noone has written a real overview of gui event loop/threading issues, with simple pictures of what is going on, the various cases known to work or not work, and guidance on how to write the most generally usable gui apps in python while keeping the interpreter 'alive'. Ideally, I'd like to see an overview considering all the cases: - Tkinter, wx, GTK - plain python, IPython, IDLE - IPython -wthread -gthread and -tk flags - compiling Tkinter with/without thread support Perhaps when I'm done with my researches I'll write such an article myself... :-). Meanwhile, any other pointers or good clues you can give would certainly be welcome. There are also some intriguing comments in _tkinter.c on threading; my 'ideal guithreads article' would also provide an overview of that code, as an aid in reading it. (I will be dwelling on thc C/C++ side as well in my project. FYI, I am trying to port a C++ library that displays our in-house types of (astronomical) data, so that it can operate under python control. As currently used, it is already a custom Tk widget (outside of Tkinter/python), and has a command interface as well (via a home-grown inter-process communication framework), so that it is controlled through both mouse and scripting. I want to replace the current command interface with python scripting). As a concrete question, may I ask you how to tell if 'tkinter is compiled with thread support'? (I note that a 'test_threading' passed in the 'make test' log for my python; I presume that if threading was on for my python build, it was on for building _tkinter.so...(?)) Anyway, thanks again for your help; I hope I haven't taken too much of your time. Regards, David King From perry at stsci.edu Mon May 23 14:25:04 2005 From: perry at stsci.edu (Perry Greenfield) Date: Mon, 23 May 2005 14:25:04 -0400 Subject: [AstroPy] Re: gui/thread issues In-Reply-To: <42921AD5.7050508@nrao.edu> References: <42921AD5.7050508@nrao.edu> Message-ID: <729cb13ce6781f439540fdcdd72e6a7b@stsci.edu> On May 23, 2005, at 2:03 PM, David King wrote: > > In the short run, I would be ok just using Tk alone on IPython or plain > Python, although I'd be happiest having the whole picture. In the > long run, > our project will want to serve varied users, who will no doubt want to > use > python in their own way. > Note that Tkinter windows under the standard Python interpreter are only 'alive' when the intepreter prompt is active. If you invoke a function that takes a long time, the window will be unresponsive since the Tk events are only handled within the Python interpreter loop. In this respect IPython should have an advantage with threading. > > I will continue to study what I have (that forum-thread link was > helpful > too--thanks). But I can't help feeling other python gui programmers > must > run up against this problem too, and wonder why practically all the > standard > Tkinter doc (including Grayson's book) just says "you gotta call > mainloop() > to make anything actually appear and respond in Tkinter" (manifestly > untrue). I think the problem is that, by and large, almost all uses of GUIs are centered on their being standalone applications and thus little thought is given to having a command line coexisting with the GUI. Our needs are pretty atypical in this regard. Perry Greenfield From fredrik at pythonware.com Wed May 25 03:13:08 2005 From: fredrik at pythonware.com (Fredrik Lundh) Date: Wed, 25 May 2005 09:13:08 +0200 Subject: [AstroPy] Re: gui/thread issues References: <42921AD5.7050508@nrao.edu> Message-ID: David King wrote: > I will continue to study what I have (that forum-thread link was helpful > too--thanks). But I can't help feeling other python gui programmers must > run up against this problem too, and wonder why practically all the standard > Tkinter doc (including Grayson's book) just says "you gotta call mainloop() > to make anything actually appear and respond in Tkinter" (manifestly untrue). no, that's 100% true if you use Tkinter from a running Python program. that's how most people use Python, and that's how most Tkinter programs are meant to be used. if you type Python commands into an interactive prompt, the exact behaviour depends on the program that offers the interactive environment. if that pro- gram already runs a main loop (or provides some other kind of message pump), *and* the program runs your commands/snippets *in its own process*, Tkinter commands *may* work without additional message handling. Tkinter itself has no control over that. From barrett at stsci.edu Tue May 31 10:11:57 2005 From: barrett at stsci.edu (Paul Barrett) Date: Tue, 31 May 2005 10:11:57 -0400 Subject: [AstroPy] [Fwd: [SciPy-dev] IDL to Python converter available] Message-ID: <429C70AD.7070300@stsci.edu> This announcement about an IDL to Python converted from the SciPy-dev list might be of interest to those on AstroPy. -- Paul -- Paul Barrett, PhD Space Telescope Science Institute Phone: 410-338-4475 ESS/Science Software Branch FAX: 410-338-4767 Baltimore, MD 21218 -------------- next part -------------- An embedded message was scrubbed... From: Christopher Stawarz Subject: [SciPy-dev] IDL to Python converter available Date: Mon, 30 May 2005 17:13:09 -0400 Size: 5450 URL: