[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 able to
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
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
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 Windows?
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 happen
Michiel 1) Currently, there's only one PyOS_InputHook. So we're stuck
Michielif we find that some other extension module already set
MichielPyOS_InputHook. An easy solution would be to have an
MichielPyOS_AddInputHook/PyOS_RemoveInputHook API, and let Python
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.
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
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 make
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 how
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).
I don't
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 waiting.
I'm not
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
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
[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
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 callbacks,
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 the interpreter
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 clarification; please correct
me.
(1) There is some pre-discussion attached to patches
1049855 and 1252236. Martin Loewis and Michiel
de Hoon agreed that
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
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 have
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
which IDE
(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
which IDE to use is
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 argument
Michiel 1) What if the user decides to import Tkinter next? Tkinter
Michielnotices that PyOS_InputHook is already set, and does not
Michielreset it to its own event loop. Hence, Tkinter's events are
Michielnot handled. Similarly, if a user imports Tkinter before my
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
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. If the
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 the
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
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 proposed
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
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 cause
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 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. So this is the
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, e.g.
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
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
Probably
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
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
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 it's
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 know,
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 events,
Dear Pythoneers,
I use Python heavily for scientific computing, originally for
computational physics and nowadays for computational biology. One of the
extension modules I support is pygist, a module for scientific
visualization. For this (and similar) packages to work, it is important
to
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
43 matches
Mail list logo
