«

Eric Brunel <> wrote in message news:<bh8da1$ti2$>...
> Cousin Stanley wrote:
> > Michele ....
> >
> > I experience hangs with SIMPLE Python/Tk scripts
> > regularly using Windows 98 and this has been
> > a source of much frustration, almost to the point
> > of giving up on Tk ....
>
> Same problem, different solution: it made me give up on Windows 98...
>
> FYI, and just to make this post a bit more useful, it seems to be a problem in
> Windows 95/98, since no problem ever occured with the same scripts/distros on
> Win2k or WinXP, not to mention Unices...

These are very good news to me, since it means that the fault is not
mine
and that the approach I came out is not unreasonable (I hope). No bad,
for my first program using thread For the record, I NEVER use
Windows for development(actually I use it only for watching DVDs),
nevertheless I
wanted to try the script to check about portability issues.


Michele

Hello Michele,

> I wonder what is the recommended way of using Tkinter
> together with a command line oriented application.
I know it's not Tkinter but what about wxPython with wxCrust?

HTH.
Miki

Late to this thread, but --

in a similar situation, I just put:

_tkinter.dooneevent(_tkinter.DONT_WAIT)

in my main logic loop (cmd interpreter in your case), instead of
calling Frame.mainloop(). I believe Frame.update() does something
similar but for some reason this worked better.

ISTM this would be cleaner (and safer) than using threads. You can do
all your draw operations from your command line routines, and they
will get displayed as soon as the routine returns to your main loop to
wait for more input.

Am I missing something?

-dbm

(Michele Simionato) wrote in message news:<. com>...
> I wonder what is the recommended way of using Tkinter
> together with a command line oriented application.
> I have in mind something like that:
>
> import cmd,sys
>
> class CMD(cmd.Cmd):
> def do_this(self,*args):
> draw_a_diagram()
> def do_that(self,*args):
> draw_another_diagram()
> def do_exit(self,*args):
> sys.exit(0)
>
> c=CMD()
> c.cmdloop()
>
> Here the methods ``draw_a_diagram`` and ``draw_another_diagram``
> should do what you expect. Notice that I don't want to use
> different windows, the graphs should be displayed on the same
> window one over the other. BTW, I am not really displaying
> diagrams, this is only the simplest example I can figure out
> of graphics program driven by a command line interpreter.
> I want to stay with the CLI interface, which I like a lot
> thanks to the readline and completion support, the easy
> of use and the easy of implementation.
>
> I have no idea of how to do that, except via contorsions
> such as saving (a representation of) the diagrams in a file
> and having a separated Tkinter process that periodically look at the
> file, changing the display if the file has been updated. I
> guess there is a better way, since this is a quite common issue.
> Any suggestion?
>
> TIA,
>
> Michele

(dan) wrote in message news:< om>...
> Late to this thread, but --
>
> in a similar situation, I just put:
>
> _tkinter.dooneevent(_tkinter.DONT_WAIT)
>
> in my main logic loop (cmd interpreter in your case), instead of
> calling Frame.mainloop(). I believe Frame.update() does something
> similar but for some reason this worked better.
>
> ISTM this would be cleaner (and safer) than using threads. You can do
> all your draw operations from your command line routines, and they
> will get displayed as soon as the routine returns to your main loop to
> wait for more input.
>
> Am I missing something?
>
> -dbm

I like quite a lot you suggestion! "dooneevent" was the method I was
looking for! Actually, I would rather prefer to avoid threads for such a
simple program. Thanks to the power of Python I wrote down a working
script in less than five minutes, even if probably I will need more
than five minutes to understand what I wrote
Here it is:

import Tkinter as t
import cmd

root=t.Tk()
s=t.StringVar()
s.set('ciao')
label=t.Label(root,textvariable=s)
label.pack()

class Cmd(cmd.Cmd):
def do_display(self,arg):
s.set(arg)
root.tk.dooneevent(0)
def do_quit(self,arg):
root.quit()
return 'quit' # anything != None will do

Cmd().cmdloop()


I will later try it on Windows 98. Dunno exactly what "dooneevent" is doing,
I searched my python directories for "dooneevent" and found only one
usage of "doonevent" and copied it Unfortunately "dooneevent"
has no docstring, however few experiments show that "dooneevent()"
is the same that "dooneevent(0)" whereas "dooneevent(1)" hangs up
(it is waiting for what??)

Thanks for your help,


Michele

(smarter_than_you) wrote in message

> Also note that there are at least three ways to get this behavior:
>
> _tkinter.dooneevent(TCL_DONT_WAIT)
> Frame.update()
> Tkinter.dooneevent(0) #this is new to me! You found a third way to
> call it
>
that would be:

root.tk.dooneevent()

but anyway --

in my experiments, this last way (Michelle's way) has very bad timing,
if you care about that sort of thing. Both the _tkinter call and
update() seem to be more reactive.

(dan) wrote in message news:< om>...
> (smarter_than_you) wrote in message
>
> > Also note that there are at least three ways to get this behavior:
> >
> > _tkinter.dooneevent(TCL_DONT_WAIT)
> > Frame.update()
> > Tkinter.dooneevent(0) #this is new to me! You found a third way to
> > call it
> >
> that would be:
>
> root.tk.dooneevent()
>
> but anyway --
>
> in my experiments, this last way (Michelle's way) has very bad timing,
> if you care about that sort of thing. Both the _tkinter call and
> update() seem to be more reactive.

..update() seems to be working (even of Win9 and the name is
self-documenting, so at the moment it is my first candidate.

BTW, notice the spelling : Michele with one "l", italian male name,
as opposed to Michelle, with two "l", french female name.

Thanks, for your help,

Michele

(Michele Simionato) writes:

> I wonder what is the recommended way of using Tkinter
> together with a command line oriented application.
> I have in mind something like that:
[...]

Um. I'm coming to this thread late, but my pyrepl package works quite
nicely with Tkinter programs (on Unix, anyway).

$ pythoni
Python 2.2.1 (#1, Apr 9 2002, 13:10:27)
[GCC 2.96 20000731 (Red Hat Linux 7.1 2.96-9] on linux2
Type "help", "copyright", "credits" or "license" for more information.
->> import Tk
Traceback (most recent call last):
File "<input>", line 2, in ?
ImportError: No module named Tk
->> import Tkinter
->> root = Tkinter.Tk()
->> label = Tkinter.Label(root, text="hi!")
->> label.pack()

.... just like the native toplevel (which isn't surprising, as that's
where I cribbed the code from).

HTH,
mwh

--
QNX... the OS that walks like a duck, quacks like a duck, but is,
in fact, a platypus. ... the adventures of porting duck software
to the platypus were avoidable this time.
-- Chris Klein, alt.sysadmin.recovery

(Michele Simionato) writes:

> I will later try it on Windows 98. Dunno exactly what "dooneevent"
> is doing,

"man Tk_DoOneEvent"

Cheers,
mwh

--
I appear to have caused some confusion. Excellent.
-- JoeB, asr

Michael Hudson <> writes:

> (Michele Simionato) writes:
>
> > I will later try it on Windows 98. Dunno exactly what "dooneevent"
> > is doing,
>
> "man Tk_DoOneEvent"

****, that should be Tcl_DoOneEvent...

Cheers,
mwh

--
One of the great skills in using any language is knowing what not
to use, what not to say. ... There's that simplicity thing again.
-- Ron Jeffries