After some of the recent discussion here I updated Tkx::ROText to be a
frame-based megawidget instead of a pseudo-subclassed text widget. I
added an _mpath() method to delegate all calls to the text subwidget.
Everything seemed rosy.
I recently noticed that in one of my applications which uses Tkx::ROText
I could no longer control scrolling via the scrollbars. Explicit calls
to xview() and yview() work but the scrollbar bindings don't. I had to
replace this:
$hsb->configure(-command => [$rotext, 'xview']);
$vsb->configure(-command => [$rotext, 'yview']);
with this:
$hsb->configure(-command => ["$rotext.text", 'xview']);
$vsb->configure(-command => ["$rotext.text", 'yview']);
The problem (presumably) is that the built-in scrollbar widget is
oblivious to the Perl layer and thus the delegation provided by
_mpath(). It's trying to call yview() on a frame. Fail!
Knowing what's going on, is there anything to be done about it? It's
easy enough to specify the subwidget when configuring scrollbars but
that would mean that the users of my module must be aware of the widget
implementation and the limitations of the toolkit.
I'm thinking about undoing the changes that made Tkx::ROText frame-based
as the benefits seem small compared to this drawback. That would solve
this particular problem but I wonder what other ones might be out there.
It's also rather ominous for the Tkx::Scrolled widget that I've been
thinking about creating.
It seems like the right place to fix this is in the toolkit but I can't
think of a way to do that without making the thin layer either thicker
(everything goes through a Perl layer) or more intrusive (sniff out
object references in -command bindings and perform _mpath()
substitution on them). Any ideas?
-mjc
