Front page | perl.perl5.porters |
Postings from January 2012
Re: [perl #108470] Term::ReadLine should use AE instead of Tk for event looping
From:
Darin McBride
Date:
January 18, 2012 07:14
Subject:
Re: [perl #108470] Term::ReadLine should use AE instead of Tk for event looping
Message ID:
1433060.Cg7QTNGf9G@naboo
My apologies for the duplicate posts... apparently the delay on email was
longer than I had expected. :-(
On Wednesday January 18 2012 1:40:21 AM you wrote:
> I am author of a Audio::Nama, a Tk application that uses
> Term::ReadLine::Gnu with the tkRunning option to allow the
> user to control the app by entering commands via T::RL
> as well as by manipulating Tk widgets.
>
> While I don't really understand how event loops work,
> it appears that the tkRunning setting actually
> belongs to Term::ReadLine::Gnu. IOW, it is necessary to
> install the latter for the tkRunning setting to work.
Looking through the T::RL::G code, it calls $self->register_Tk, which is in
T::RL::Tk - where my patches are, and I *think* it registers the perl Tk_getc
function as the getc for readline (it's hard for me to follow), which, again,
is where my patches are.
> So I wonder, will it be sufficient to patch
> Term::ReadLine? Perhaps Gnu ReadLine will
> need patched as well?
Perhaps. However, at worst, the Tk mode won't be affected.
> Second, I wonder, why change the existing API?
> Couldn't another setting, AERunning, be simply
> added rather than replacing tkRunning?
> As you point out, not everyone may want to
> add another dependency to their code.
The existing API isn't changed, but my answer to that is that AE is both more
modern (not sufficient by itself) and more generic. The point of AE seems to be
to support any event model you might need, including Tk.
> Third, if such patches were proposed, I would want
> them to be tested fully (and I will be happy to help.)
My issue here is merely that the existing tests seem less than adequate. I've
run some sample code manually - with AE, Tk, and AE & Tk, and it all seemed to
work. However, that's all manual, and with T::RL::Perl, not T::RL::Gnu (I
never have luck with T::RL::G, I don't know why). I'll have to look at the
tests for the T::RL implementations to see if they have anything I can use for
a base for testing. Otherwise, I have some really nasty ideas - we'll have to
see. I'm having problems enough keeping up the test files for $work :-)
> 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.
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.
> 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.
> 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!