Front page | perl.perl5.porters |
Postings from January 2012
On Wed, Jan 18, 2012 at 07:27:35AM -0700, Darin McBride wrote: > On Wednesday January 18 2012 1:40:21 AM Joel Roth wrote: > > A final note, Audio::Nama already uses AnyEvent, > > allowing a choice of event loops. Event is selected > > for terminal-only mode and Tk for terminal+Tk mode. > > I'm curious as to how you would receive events registered wtih Event while > T::RL is waiting for text, since T::RL is currently going to be spinning the > Tk event loop, not the Event event loop, unless you have an idle callback > registered with Tk that simply spins the Event loop once. I use Event in a situation that the app runs without loaded the Tk based GUI, to provide timers, etc. In that case, tkRunning is not set. > In other words, as far as I can tell, today, T::RL will only spin a Tk loop. > If Tk isn't loaded, it won't spin any loop, and all events will be on hold > (with a possible exception of signal handlers) until the user hits enter. I'm glad no one told *me* that! :-) A T::RL based command prompt seems to run fine alongside an Event event loop. I may be able to dig up some test code to verify this FYI. > > As far as I understand, the Tk event loop will > > still be required for Tk applications to play friendly > > with Term::ReadLine, however the AnyEvent layer > > might allow me to, for example, rewrite the GUI in Qt. > > Right - by switching T::RL to use AE (or at least default to it when it's > there), your GUI can use anything. I would also suggest reading some of the > Anyevent::Impl::* modules' perldocs - they're informative as to what bugs the > author had to overcome. In the Tk module, he talks about limitations > regarding the event loop, and how the event IDs can wrap around, clobbering > events. "So don't run Tk programs for more than an hour or so." Allowing the > user of the module the ability to work around these types of issues simply by > using another event model seems prudent. Ouch! This is an audio app that might record or play for long periods. Thanks, I will look into it. > > Bonus questions: Does any know if tkRunning setting supports > > other Tk implementations such as Tcl::Tk or Tkx? Do they > > provide events such as Tk::after? > > One of my "test that I didn't break anything" scripts is using Tk::after just > to prove that the events are being called. I don't know about Tcl::Tk or Tkx > - I actually don't use Tk, which is one of the driving factors behind this > itch. > > > If so, it may be necessary that these sister implementations > > of Tk be verified to function properly under patches > > proposed to Term::ReadLine, Term::ReadLine::Gnu, or > > possibly Gnu ReadLine. > > More testing == good. (But too much testing == unreasonable delay) Since my > new patch leaves everything alone when AE is not loaded, but works fine with Tk > when AE and Tk are loaded, these should continue to work. But testing our > questions is definitely good - I just don't know anything about these other > modules to know how to test them. > > > All this is written in theoretical ignorance, but with > > a measure of actual experience with the packages in > > question. > > :-) > > Thanks! Seems to be going both ways. :-) -- Joel RothThread Previous | Thread Next