Mate, I am happy to share the entire messy thing if you like :-)
What I have is the timer/thread thing but also how I have used Pmw to create
an adaptive interface to the user (timers can be created or deleted as
required and the GUI just resizes/remaps everything).
Since it was never written to be read/understood by others, I am not sure
how good the code is to understand/read. It's probably not too bad, because
even for my own stuff I tend to write comments (never have believed in
"self-documenting code" :-)). But I doubt that it will have good enough
comments for somebody who hasn't seen Pmw or threads before to necessarily
work out what is happening.
But I am more than happy to post the entire thing somewhere - where is a
good place to post it?
Peter
On Tue, May 27, 2008 at 12:13 AM, Cameron Laird <[EMAIL PROTECTED]> wrote:
> On Mon, May 26, 2008 at 11:29:40AM +1000, Peter Milliken wrote:
> .
> .
> .
> > True, sleep() pauses the main app - if you run it there. It wasn't
> obvious
> > to me from the original question that this might be a problem :-)
> >
> > In my application (a simple egg timer that allows on the fly creation of
> new
> > timers and allows timing in relative or absolute terms i.e. in 5 minutes
> 23
> > seconds alert me or at 10:06:55 alert me) I leave the sleep() call down
> in
> > the thread that I created for each timer - so each "timer" thread pauses
> for
> > X seconds (1 second in my case because that is the smallest increment of
> > time that I am interested in).
> >
> > I use Pmw for all my GUI work - after getting your mind around how
> flexible
> > it can be, you can create some amazingly power applications that can
> > reconfigure themselves on the fly for the user - one of the best
> programming
> > interfaces I have ever used! The guy who did this has my complete
> > admiration! :-)
> >
> > Perhaps (just for fun :-)) think about recreating your application using
> > threads and (message) queues to pass information between the main Tk loop
> > and the various threads that you create.
> >
> > Be careful - Tkinter in not re-entrant and you need to leave all of your
> > graphics manipulations in the mainloop - but you can safely do all sorts
> of
> > other stuff (checking files for changes etc etc) in threads - as long as
> > they don't do any GUI work then you are safe.
> >
> > Doing threaded applications in Tk is definitely not for the beginner -
> you
> > can find cookbook examples of using threading with Tk.
> >
> > Personally I find it kind of fun to do - I work in real-time embedded
> > systems programming, so threading and tasking is very familiar territory.
> > But if you ever want to expand your horizons give it some thought - but
> be
> > mindful that it requires a different mindset to that of straight "linear"
> > thinking programming - many programmers have some difficulty when they
> are
> > first exposed to threads and multi-tasking applications - but once you
> get
> > past that barrier you start to think in those terms with ease :-)
> > > > .
> > > > .
> > > > .
> > > > > and thanks for the answers: how, i avoided the sleep() approach,
> > > > > because, as Cameron said i supposed that it freezed the
> application:
> > > > > being in sleep() it stops the mainloop()...
> > > .
> > > .
> > > .
> > > I need to put this minimal example of after()-based polling in the Wiki
> ...
> > >
> > > import Tkinter
> > > import time
> > >
> > > root = Tkinter.Tk()
> > >
> > > def my_update():
> > > display.set("The time now is '%s'." %
> time.asctime(time.localtime()))
> > > # Re-invoke myself in two seconds.
> > > root.after(2000, my_update)
> > >
> > > display = Tkinter.StringVar()
> > > window = Tkinter.Label(root, textvariable = display)
> > > window.pack()
> > > my_update()
> > > root.mainloop()
> .
> .
> .
> I think we're all together now. To be certain, I'll
> say some of this in my own words.
>
> sleep() is not a "problem", but it frequently is a
> *surprise* to those working in this area for the first
> time. Concurrency is indeed distinct from sequential-
> procedural patterns, and I agree that folklore tells
> us many newcomers to the area take a bit of time to
> adjust. I'd add that, to the best of my knowledge,
> that adjustment is present whether coding is in a
> thread-based or event-based idiom. While I'm also a
> firm believer that the latter is less error-prone for
> many common requirement sets, I agree that Pmw is a
> considerable value for which we all should be thankful.
>
> You're absolutely right that Tkinter (and X-windows-
> compatible toolkits, more generally) need to keep their
> GUIs in a single thread.
>
> Is it handy for you to share a threaded-Pmw-based equi-
> valent of the two-second-grainy clock I've included
> above? I think it'll make for an interesting comparison
> from which we perhaps might all learn. If you don't get
> to it in the next week, I'll try, although I'm rusty
> with Pmw.
>
_______________________________________________
Tkinter-discuss mailing list
Tkinter-discuss@python.org
http://mail.python.org/mailman/listinfo/tkinter-discuss
