On 11/15/05, Fredrik Lundh <[EMAIL PROTECTED]> wrote:
> If you want to write portable code that keeps things running "in the
> background" while the users hack away at the standard interactive
> prompt, InputHook won't help you.
>
So probably it should be improved, or changed a bit, to work also on
Noam Raphael wrote:
> It didn't. Strange freezes started to appear, only when working from
> IDLE. This made me investigate a bit, and I've found that Tkinter
> isn't run from a seperate thread - the dooneevent() function is called
> repeatedly by PyOS_InputHook while the interpreter is idle.
rep
On 11/14/05, Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> wrote:
> Ronald Oussoren wrote:
>
> > I wonder why nobody has suggested a seperate thread for managing the
> > GUI and
> > using the hook in Python's event loop to issue the call to update_plot.
> >
> Ha. That's probably the best solution
Michiel> 1) Currently, there's only one PyOS_InputHook. So we're stuck
Michiel>if we find that some other extension module already set
Michiel>PyOS_InputHook. An easy solution would be to have an
Michiel>PyOS_AddInputHook/PyOS_RemoveInputHook API, and let Python
Mic
On Sun, Nov 13, 2005, Josiah Carlson wrote:
>
> I personally like Edward Loper's idea of just running your own event
> handler which deals with drawing, suspend/resume, etc...
>
>> If, however, Python contains an event loop that takes care of events as
>> well as Python commands, redrawing won't
Ronald Oussoren wrote:
> I wonder why nobody has suggested a seperate thread for managing the
> GUI and
> using the hook in Python's event loop to issue the call to update_plot.
>
Ha. That's probably the best solution I've heard so far, short of adding
a Tcl-like event loop API to Python.
There
On 14-nov-2005, at 8:16, Josiah Carlson wrote:
>
> I personally like Edward Loper's idea of just running your own event
> handler which deals with drawing, suspend/resume, etc...
>
>> If, however, Python contains an event loop that takes care of
>> events as
>> well as Python commands, redrawin
On 14-nov-2005, at 16:00, [EMAIL PROTECTED] wrote:
>
> Ronald> ... except when the GUI you're using doesn't expose (or
> even
> Ronald> use) a file descriptor that you can use with select.
> Not all the
> Ronald> world is Linux.
>
> Can you be more specific? Are you referring to
Michiel Jan Laurens de Hoon wrote:
> This is exactly the problem. Drawing one picture may consist of many
> Python commands to draw the individual elements (for example, several
> graphs overlaying each other). We don't know where in the window each
> element will end up until we have the list of
Michiel Jan Laurens de Hoon wrote:
> >Did you read my reply? ipython, based on code.py, implements a few simple
> >threading tricks (they _are_ simple, since I know next to nothing about
> >threading) and gives you interactive use of PyGTK, WXPython and PyQt
> >applications in a manner similar to
[EMAIL PROTECTED] wrote:
>Ronald> ... except when the GUI you're using doesn't expose (or even
>Ronald> use) a file descriptor that you can use with select. Not all the
>Ronald> world is Linux.
>
>Can you be more specific? Are you referring to Windows? I'm not suggesting
>you'd be ab
Ronald> ... except when the GUI you're using doesn't expose (or even
Ronald> use) a file descriptor that you can use with select. Not all the
Ronald> world is Linux.
Can you be more specific? Are you referring to Windows? I'm not suggesting
you'd be able to use the same exact implem
Michiel Jan Laurens de Hoon wrote:
> If, however, Python contains an event loop that takes care of events as
> well as Python commands, redrawing won't happen until Python has
> executed all plot commands -- so no repainting in vain here.
Ah, I think now I understand the problem. It seems that y
Josiah Carlson wrote:
> Or heck, if you are really lazy, people can use a plot() calls, but
> until an update_plot() is called, the plot isn't updated.
I really recommend that those interested in all these issues have a look at
matplotlib. All of this has been dealt with there already, a long ti
Michiel Jan Laurens de Hoon wrote:
>>Yes, you can. Actually, Tkinter *always* runs in a separate thread
>>(separate from all other threads).
>>
> Are you sure? If Tkinter is running in a separate thread, then why does
> it need PyOS_InputHook?
Well, my statement was (somewhat deliberately) misl
I personally like Edward Loper's idea of just running your own event
handler which deals with drawing, suspend/resume, etc...
> If, however, Python contains an event loop that takes care of events as
> well as Python commands, redrawing won't happen until Python has
> executed all plot commands
On 14-nov-2005, at 2:20, Michiel Jan Laurens de Hoon wrote:
> [EMAIL PROTECTED] wrote:
>
>> If I have a Gtk app I have to feed other (socket, callback) pairs
>> to it. It
>> takes care of adding it to the select() call. Python could
>> dictate that the
>> way to play ball is for other packa
As I understand it, you want to improve the performance of interactively
run plot commands by queuing up all the plot sub-commands, and then
drawing them all at once. Hooking into a python event loop certainly
isn't the only way to do this. Perhaps you could consider the following
approach:
Michiel Jan Laurens de Hoon wrote:
> Fernando Perez wrote:
>>Did you read my reply? ipython, based on code.py, implements a few simple
>>threading tricks (they _are_ simple, since I know next to nothing about
>>threading) and gives you interactive use of PyGTK, WXPython and PyQt
>>applications in
Fernando Perez wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>For an extension module such as
>>PyGtk, the developers may decide that PyGtk is likely to be run in
>>non-interactive mode only, for which the PyGtk mainloop is sufficient.
>>
>>
>
>Did you read my reply? ipython, based on code
Greg Ewing wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>Greg Ewing wrote:
>>
>>
>>>How about running your event loop in a separate thread?
>>>
>>>
>>I agree that this works for some extension modules, but not very well
>>for extension modules for which graphical performance is cri
Michiel Jan Laurens de Hoon wrote:
> For an extension module such as
> PyGtk, the developers may decide that PyGtk is likely to be run in
> non-interactive mode only, for which the PyGtk mainloop is sufficient.
Did you read my reply? ipython, based on code.py, implements a few simple
threading tr
Martin v. Löwis wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>But there is another solution with threads: Can we let Tkinter run in a
>>separate thread instead?
>>
>>
>
>Yes, you can. Actually, Tkinter *always* runs in a separate thread
>(separate from all other threads).
>
>
Are you
Noam Raphael wrote:
> On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
> > Noam Raphael wrote:
> >
> > > callback". Then, when the interpreter is idle, it will call all the
> > > registered callbacks, one at a time, and everyone would be happy.
> >
> > Except for those who don't like busy wait
Noam Raphael wrote:
>On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
>
>
>>Noam Raphael wrote:
>>
>>
>>>All that is needed to make Tkinter and Michiels'
>>>code run together is a way to say "add this callback to the input
>>>hook" instead of the current "replace the current input hook wit
Michiel Jan Laurens de Hoon wrote:
> Greg Ewing wrote:
>
> > How about running your event loop in a separate thread?
>
> I agree that this works for some extension modules, but not very well
> for extension modules for which graphical performance is critical
I don't understand. If the main thre
[EMAIL PROTECTED] wrote:
>If I have a Gtk app I have to feed other (socket, callback) pairs to it. It
>takes care of adding it to the select() call. Python could dictate that the
>way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to
>feed Python the (socket, callback) pair.
Greg Ewing wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>I have an extension module for scientific visualization. This extension
>>module opens one or more windows, in which plots can be made.
>>
>>
>
>What sort of windows are these? Are you using an existing
>GUI toolkit, or rolling you
Martin v. Löwis wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>
>>The problem with threading (apart from potential portability problems)
>>is that Python doesn't let us know when it's idle. This would cause
>>excessive repainting (I can give you an explicit example if you're
>>interested).
>>
Mark Hammond wrote:
> : Currently, event loops are available in Python via PyOS_InputHook, a
> : pointer to a user-defined function that is called when Python is idle
> : (waiting for user input). However, an event loop using PyOS_InputHook
> : has some inherent limitations, so I am thinking about
Michiel Jan Laurens de Hoon wrote:
> I have an extension module for scientific visualization. This extension
> module opens one or more windows, in which plots can be made. Something
> similar to the plotting capabilities of Matlab.
>
> For the graphics windows to remain responsive, I need to ma
On 11/13/05, Greg Ewing <[EMAIL PROTECTED]> wrote:
> Noam Raphael wrote:
>
> > All that is needed to make Tkinter and Michiels'
> > code run together is a way to say "add this callback to the input
> > hook" instead of the current "replace the current input hook with this
> > callback". Then, when
Noam Raphael wrote:
> All that is needed to make Tkinter and Michiels'
> code run together is a way to say "add this callback to the input
> hook" instead of the current "replace the current input hook with this
> callback". Then, when the interpreter is idle, it will call all the
> registered cal
[EMAIL PROTECTED] wrote:
> Python could dictate that the
> way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to
> feed Python the (socket, callback) pair. Then you have a uniform way to
> control event-driven applications.
Certainly, if all other event-driven packages are wi
Jim Jewett wrote:
> (6) Mark Hammond suggests that it might be easier to
> replace the interactive portions of python based on the
> "code" module. matplotlib suggests using ipython
> instead of standard python for similar reasons.
>
> If that is really the simplest answer (and telling users
>
On 11/12/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> If I have a Gtk app I have to feed other (socket, callback) pairs to it. It
> takes care of adding it to the select() call. Python could dictate that the
> way to play ball is for other packages (Tkinter, PyGtk, wxPython, etc) to
> feed
>> This sounds sort of like the situation that existed with sys.exitfunc
>> before the creation of the atexit module. Can't we develop an API
>> similar to that so that many different event-loop-wanting packages
>> can play nice together?
Greg> I can't see how that would help
Michiel Jan Laurens de Hoon wrote:
> I have an extension module for scientific visualization. This extension
> module opens one or more windows, in which plots can be made.
What sort of windows are these? Are you using an existing
GUI toolkit, or rolling your own?
> For the graphics windows to
[EMAIL PROTECTED] wrote:
> This sounds sort of like the situation that existed with sys.exitfunc before
> the creation of the atexit module. Can't we develop an API similar to that
> so that many different event-loop-wanting packages can play nice together?
I can't see how that would help. If th
Michiel> 1) What if the user decides to import Tkinter next? Tkinter
Michiel>notices that PyOS_InputHook is already set, and does not
Michiel>reset it to its own event loop. Hence, Tkinter's events are
Michiel>not handled. Similarly, if a user imports Tkinter before my
Jim Jewett wrote:
> > really? Python comes with a module that makes it trivial to get
> > a fully working interpreter console ...
>
> Using an event loop (or an external GUI) should not require
> forking the entire interactive mode, no matter how trivial that
> fork is.
repeating a bogus argumen
Jim Jewett wrote:
> (6) Mark Hammond suggests that it might be easier to
> replace the interactive portions of python based on the
> "code" module. matplotlib suggests using ipython
> instead of standard python for similar reasons.
>
> If that is really the simplest answer (and telling users
> w
Martin v. Löwis wrote:
>Before trying to explain the reason, please try to explain the
>problem first. What is it *really* that you want to do which
>you feel you currently can't do?
>
>
Probably I should have started the discussion with this; sorry if I
confused everybody. But here it is:
I h
I think this is an excellent summary of the discussion so far. Probably
clearer than my own posts.
Thanks, Jim!
--Michiel.
Jim Jewett wrote:
>There has been enough misunderstanding in this thread
>that the summarizers are going to have trouble. So I'm
>posting this draft in hopes of clarificat
Michiel wrote:
> Guido van Rossum wrote:
>
> >On 11/9/05, Michiel Jan Laurens de Hoon
> <[EMAIL PROTECTED]> wrote:
> >
> >
> >>My application doesn't need a toolkit at all. My problem is that because
> >>of Tkinter being the standard Python toolkit, we cannot have a decent
> >>event loop in Python.
Michiel Jan Laurens de Hoon wrote:
> I have come to this conclusion after several years of maintaining a
> scientific plotting package and trying to set up an event loop for
> it. Whereas there are some solutions that more or less work, none of
> them work very well, and the solutions that we found
Michiel Jan Laurens de Hoon wrote:
>>You are missing multi-threading, which is the widely used
>>approach to doing things simultaneously in a single process.
>
> The problem with threading (apart from potential portability problems)
> is that Python doesn't let us know when it's idle. This would
Guido van Rossum wrote:
>On 11/9/05, Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> wrote:
>
>
>>My application doesn't need a toolkit at all. My problem is that because
>>of Tkinter being the standard Python toolkit, we cannot have a decent
>>event loop in Python. So this is the disadvantage I
At 01:47 PM 11/10/2005 +, Donovan Baarda wrote:
>Twisted is an async-framework that I believe has support for using a
>variety of different event-loops, including Tkinter and wxWidgets, as
>well as it's own.
Technically, it just gives Tkinter a chance to run every so often; you
specifically *
Martin v. Löwis wrote:
> Michiel Jan Laurens de Hoon wrote:
>
>> It's not because it likes to be in charge, it's because there's no
>> other way to do it in Python.
>
> As I said: this is simply not true.
You are right in the sense it is possible to get events handled using
the solutions you pr
On 11/9/05, Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> wrote:
> My application doesn't need a toolkit at all. My problem is that because
> of Tkinter being the standard Python toolkit, we cannot have a decent
> event loop in Python. So this is the disadvantage I see in Tkinter.
That's a non-s
On Thu, 2005-11-10 at 00:40 -0500, Michiel Jan Laurens de Hoon wrote:
> Stephen J. Turnbull wrote:
>
> >Michiel> What is the advantage of Tk in comparison to other GUI
> >Michiel> toolkits?
[...]
> My application doesn't need a toolkit at all. My problem is that because
> of Tkinter being
Michiel Jan Laurens de Hoon wrote:
> It's not because it likes to be in charge, it's because there's no other
> way to do it in Python.
As I said: this is simply not true.
> Tkinter is a special case among GUI toolkits because it is married to
> Tcl. It doesn't just need to handle its GUI event
Michiel Jan Laurens de Hoon wrote:
> At this point, I can't propose a specific modification yet because I
> don't know the reasoning that went behind the original choice of Tk as
> the default GUI toolkit for Python (and hence, I don't know if those
> reasons are still valid today).
I don't kno
Stephen J. Turnbull wrote:
>Michiel> What is the advantage of Tk in comparison to other GUI
>Michiel> toolkits?
>
>IMO, Tk's _advantage_ is that it's there already. As a standard
>component, it works well for typical simple GUI applications (thus
>satisfying "batteries included" IMO), and
Greg Ewing wrote:
>I'm not sure the event-loop situation would be
>much different with another one, anyway. From what
>I've seen of GUI toolkits, they all have their own
>form of event loop, and they all provide some way
>of hooking other things into it (as does Tkinter),
>but whichever one you're
> "Michiel" == Michiel Jan Laurens de Hoon <[EMAIL PROTECTED]> writes:
Michiel> What is the advantage of Tk in comparison to other GUI
Michiel> toolkits?
IMO, Tk's _advantage_ is that it's there already. As a standard
component, it works well for typical simple GUI applications (thus
On Thu, 10 Nov 2005 16:02:04 +1300, Greg Ewing <[EMAIL PROTECTED]> wrote:
>Michiel Jan Laurens de Hoon wrote:
>
>> At this point, I can't propose a specific modification yet because I
>> don't know the reasoning that went behind the original choice of Tk as
>> the default GUI toolkit for Python
>
>
Michiel Jan Laurens de Hoon wrote:
> At this point, I can't propose a specific modification yet because I
> don't know the reasoning that went behind the original choice of Tk as
> the default GUI toolkit for Python
Probably because at the time it was really the
only cross-platform GUI toolkit
Martin v. Löwis wrote:
> Michiel Jan Laurens de Hoon wrote:
>
>> 2) Will Tkinter always be the standard toolkit for Python, or are
>> there plans to replace it at some point?
>
>
> Python does not evolve along a grand master plan. Instead, individual
> contributors propose specific modifications,
Michiel Jan Laurens de Hoon wrote:
> 1) Did I miss something? Is there some way to get an event loop with
> Tkinter?
Yes, and yes. You are missing multi-threading, which is the widely used
approach to doing things simultaneously in a single process. In one
thread, user interaction can occur; in a
61 matches
Mail list logo
