tcltk-perl — Perl Tcl::Tk bridge module discussion

RE: [tcltk-perl] return of 1=>1.0 transformation error

[Jan D. <ja...@Ac...>]

> This is the exact code being run:
> 
> my $row = 0;
> foreach my $leaf('Tk.xbm','Xcamel.gif')
>  {
>   my $file = "./t/$leaf"; #Tk->findINC($leaf);
>   my $src = $mw->Photo(-file => $file);
>   ok(defined($src),1," Cannot load $file");
>   my $kind = 'Initial';
>   my $col = 0;
>   $mw->Label(-text  => 'Initial')
> 	->grid(-row => $row, -column => $col);
>   $mw->Label(-background => 'white',-image => $src)
> 	->grid(-row => $row+1, -column => $col++);
> 	...
> 
> We see that the problem is at -row 1, so that last line is the
> issue.  That this becomes SvNOK w/o being SvIOK in Perl 5.6
> seems "just wrong" to me (and obviously to others as 5.8 corrects
> the issue).  You guys are right that I should try without the
> SvIOK as well, but still, this is a wacky promotion behavior.

Perl 5.6.1 doesn't do anything weird there for me.  Maybe it it the
grid() method that modifies the SV?

You can investigate this using Devel::Peek.  It is not part of standard
Perl, but you can install it with PPM for ActivePerl.  Then insert

    require Devel::Peek;
    Devel::Peek::Dump($row);

Before each usage of $row and see where things change.

Cheers,
-Jan

RE: [tcltk-perl] return of 1=>1.0 transformation error

[Jeff H. <je...@Ac...>]

This is the exact code being run:

my $row = 0;
foreach my $leaf('Tk.xbm','Xcamel.gif')
 {
  my $file = "./t/$leaf"; #Tk->findINC($leaf);
  my $src = $mw->Photo(-file => $file);
  ok(defined($src),1," Cannot load $file");
  my $kind = 'Initial';
  my $col = 0;
  $mw->Label(-text  => 'Initial')
	->grid(-row => $row, -column => $col);
  $mw->Label(-background => 'white',-image => $src)
	->grid(-row => $row+1, -column => $col++);
	...

We see that the problem is at -row 1, so that last line is the
issue.  That this becomes SvNOK w/o being SvIOK in Perl 5.6
seems "just wrong" to me (and obviously to others as 5.8 corrects
the issue).  You guys are right that I should try without the
SvIOK as well, but still, this is a wacky promotion behavior.

Jeff

> > > Tcl error 'bad grid value "1.0": must be a non-negative integer at 
> > > d:/Perl56/site/lib/Tcl.pm line 363. ' while invoking scalar result 
> > > call:
> > >       "grid .lbl02 -row 1 -column 0" at
> > 	...
> > > perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.
> > 
> > This is specifically supposed to be handled by this code in
> > TclObjFromSv:
> > 
> >     else if (SvNOK(sv)) {
> > 	double dval = SvNV(sv);
> > 	int ival;
> > 	/*
> > 	 * Account for some perl versions aggressive NOK-ness where
> > 	 * an int was all that was intented.
> > 	 */
> > 	if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {
> > 	    objPtr = Tcl_NewIntObj(ival);
> > 	} else {
> > 	    objPtr = Tcl_NewDoubleObj(dval);
> > 	}
> >     }
> > 
> > as it was an issue that 5.6 decided to aggressively promote "1" with 
> > SvNOK as well as SvIOK, whereas 5.8 is corrected to not do that.
> 
> That code will not catch the case when the floating point 
> value has already been stringified.
> 
> What is weird thought is that Perl would still stringify an 
> NV of value 1.0 as "1" and not "1.0".  So is it possible that 
> the value already got round-tripped through Tcl?

RE: [tcltk-perl] return of 1=>1.0 transformation error

[Jan D. <ja...@Ac...>]

> > Tcl error 'bad grid value "1.0": must be a non-negative
> > integer at d:/Perl56/site/lib/Tcl.pm line 363. ' while
> > invoking scalar result call:
> >       "grid .lbl02 -row 1 -column 0" at
> 	...
> > perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.
> 
> This is specifically supposed to be handled by this code in
> TclObjFromSv:
> 
>     else if (SvNOK(sv)) {
> 	double dval = SvNV(sv);
> 	int ival;
> 	/*
> 	 * Account for some perl versions aggressive NOK-ness where
> 	 * an int was all that was intented.
> 	 */
> 	if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {
> 	    objPtr = Tcl_NewIntObj(ival);
> 	} else {
> 	    objPtr = Tcl_NewDoubleObj(dval);
> 	}
>     }
> 
> as it was an issue that 5.6 decided to aggressively promote
> "1" with SvNOK as well as SvIOK, whereas 5.8 is corrected to
> not do that.

That code will not catch the case when the floating point value has
already been stringified.

What is weird thought is that Perl would still stringify an NV of value
1.0 as "1" and not "1.0".  So is it possible that the value already got
round-tripped through Tcl?

Cheers,
-Jan

Re: [tcltk-perl] return of 1=>1.0 transformation error

[Gisle A. <gi...@Ac...>]

"Jeff Hobbs" <je...@Ac...> writes:

> > Tcl error 'bad grid value "1.0": must be a non-negative
> > integer at d:/Perl56/site/lib/Tcl.pm line 363. ' while
> > invoking scalar result call:
> >       "grid .lbl02 -row 1 -column 0" at
> 	...
> > perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.
> 
> This is specifically supposed to be handled by this code in
> TclObjFromSv:
> 
>     else if (SvNOK(sv)) {
> 	double dval = SvNV(sv);
> 	int ival;
> 	/*
> 	 * Account for some perl versions aggressive NOK-ness where
> 	 * an int was all that was intented.
> 	 */
> 	if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {

I think you should remove the SvIOK() test here.  Then it should work
even for SVs where only the NOK flag is set, but still contains a
whole duble.  That might happen as well.

This will have problem with very large values though.  Hmm.  You
probably also need to test that dval is within the integer range.

> 	    objPtr = Tcl_NewIntObj(ival);
> 	} else {
> 	    objPtr = Tcl_NewDoubleObj(dval);
> 	}
>     }
> 
> as it was an issue that 5.6 decided to aggressively promote
> "1" with SvNOK as well as SvIOK, whereas 5.8 is corrected to
> not do that.
> 
> Jeff
> 
> 
> 
> -------------------------------------------------------
> This SF.Net email is sponsored by: Oracle 10g
> Get certified on the hottest thing ever to hit the market... Oracle 10g. 
> Take an Oracle 10g class now, and we'll give you the exam FREE.
> http://ads.osdn.com/?ad_id=3149&alloc_id=8166&op=click
> _______________________________________________
> Tcltk-perl mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcltk-perl

RE: [tcltk-perl] return of 1=>1.0 transformation error

[Jeff H. <je...@ac...>]

> Tcl error 'bad grid value "1.0": must be a non-negative
> integer at d:/Perl56/site/lib/Tcl.pm line 363. ' while
> invoking scalar result call:
>       "grid .lbl02 -row 1 -column 0" at
	...
> perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.

This is specifically supposed to be handled by this code in
TclObjFromSv:

    else if (SvNOK(sv)) {
	double dval = SvNV(sv);
	int ival;
	/*
	 * Account for some perl versions aggressive NOK-ness where
	 * an int was all that was intented.
	 */
	if (SvIOK(sv) && ((double)(ival = SvIV(sv)) == dval)) {
	    objPtr = Tcl_NewIntObj(ival);
	} else {
	    objPtr = Tcl_NewDoubleObj(dval);
	}
    }

as it was an issue that 5.6 decided to aggressively promote
"1" with SvNOK as well as SvIOK, whereas 5.8 is corrected to
not do that.

Jeff

[tcltk-perl] plans for nearest future

[Konovalov, V. <vko...@sp...>]

Dear all,

It seems to me quite reasonable to make another CPAN release in next few
days, due to many new improvements and more perlTk compatibility features.

So, following things are in relation with this (mostly to Tcl::Tk module):

1. Grow test suite to cover most new features and widgets
2. Adapt test suite to not fail if user do not have some Tcl/Tk installed
(Tix first of all, may be others)
3. ./demos directory improvements -- code there was created when perlTk
syntax was not implemented, so it needs to be updated
4. (addressed directly to Jeff) All those changes for /lib/Tcl/Tk.pm
initiated between version 1.49 and 1.50 must be finished. No "my $int  =
$W{$$self}->{'INT'};"
5. I think I'll redo "tk-demos" directory to perlTk syntax, simply borrow
those from perlTk and adapt them.

Right after Friday I'll perform final cleaning of Tk.pm file (whatever that
means:) and will release at weeekend.
This means it will be almost necessary to have files not to be in
intermediate state after Friday.

After that there will be public holidays in Russia, and may be I'll spend
some hours in creating explanations on the web with demos and screenshots.

Any ideas or corrections are very welcomed.

Best regards,
Vadim.

[tcltk-perl] return of 1=>1.0 transformation error

[Konovalov, V. <vko...@sp...>]

Dear all,

I did not checked for details yet, but when I tried CVS version of Tcl and
Tcl::Tk I gave failed test for t/photo.t
Output is below:

Tcl error 'bad grid value "1.0": must be a non-negative integer at
d:/Perl56/site/lib/Tcl.pm line 363.
' while invoking scalar result call:
	"grid .lbl02 -row 1 -column 0" at d:/Perl56/site/lib/Tcl.pm line 364
	Tcl::call('Tcl::Tk=SCALAR(0x1b8f0d8)', 'grid', '.lbl02', '-row', 1,
'-column', 0) called at d:/Perl56/site/lib/Tcl/Tk.pm line 750
	Tcl::Tk::Widget::grid('Tcl::Tk::Widget::Label=SCALAR(0x20cdb14)',
'-row', 1, '-column', 0) called at t/photo.t line 23


Interesting to say, tests for geometry manager do not catch this, but
t/photo.t does

perl-5.8.2 passes test without this error, 5.6.0 and 5.6.1 fail.

If anyone have ideas how to fix, please share your knowledge.

Best regards,
Vadim.

[tcltk-perl] how to support pure-perl perlTk widgets?

[Vadim K. <va...@ar...>]

Implementation of pure-Perl widgets is based on Tix embedded into perlTk
(ConfigSpecs, ConstructWidget are parts of Tix and used in perlTk)
So, it could be possible to provide support for pure-Perl widgets using
namely that mechanism.

How do you all think, is it reasonable at all trying to support pure-perl
widgets?
Or have them re-implemented each time those are needed?

I, personally, do not like an idea for supporting those, and, at least, this
could be tried separatedly as independent effort once we'll have Tcl::Tk in
a good shape (and this is already the case, IMHO :)

Best regards,
Vadim.

RE: [tcltk-perl] Re: about difference in Tk.pm between 1.49 and 1 .50

[Konovalov, V. <vko...@sp...>]

Vadim Konovalov wrote:
> 
> > Actually, when doing such global replacement, please let it 
> be finished way
> > of doing things, and let us agree on how things will be 
> done. I think those
> > global package-wide hashes should actually be part of 
> Tcl::Tk interpreter
> > object.
> 
> Ah, we crossed messages (see my related post).  As I said, it
> wasn't meant to be final.

Indeed.

I hope when cleaning is finished all will be much better than earlier :) And
no  repeated "my $int  = $W{$$self}->{'INT'};"

:)

Yet, it appears that currently Perl<->Tcl::Tk<->Tcl/Tk eats less memory and
displays widgets considerably faster, so its better not to be lost when
doing many hash searches, dereferences and so on...


Best regards,
Vadim.

[tcltk-perl] Re: about difference in Tk.pm between 1.49 and 1.50

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:

> Actually, when doing such global replacement, please let it be finished way
> of doing things, and let us agree on how things will be done. I think those
> global package-wide hashes should actually be part of Tcl::Tk interpreter
> object.

Ah, we crossed messages (see my related post).  As I said, it
wasn't meant to be final.

> As Gisle already mentioned, simple changes should go directly to CVS but
> serious changes should be discussed first, may be best way is to send such
> patches to this list first.

This was actually done to just fix bugs in the new design around
the class method subroutines for widgets.  I guess we all agree
on what should be done.  Today's work was mostly a learning effort,
but while not "cleaner", it did address several bugs.  I will take
dirty over broken anytime.

-- 
     Jeff Hobbs, The Tcl Guy
     http://www.ActiveState.com/, a division of Sophos

[tcltk-perl] Re: about difference in Tk.pm between 1.49 and 1.50

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:
> For me, there is no much improvement in writing everywhere
>    my $int = $W{$$wid}->{'INT'};
> instead of
>    my $int = $wint{$$wid};
> 
> Here is why:
> both are not perfect but yours is larger, yet will be a bit slower (takes
> one more hash dereference).
> 
> For me, better is just to write
> 
> $wid->interp;

I would prefer the latter as well, but according to Jan the method
call is much slower than the extra hash dereference, so I chose the
more gruesome code in the interim.

Jeff

[tcltk-perl] internal changes to Tcl::Tk - more needed

[Jeff H. <je...@ac...>]

I jiggered some stuff around in Tcl::Tk that touches everything
essentially - how the basic object stuff is managed between
widgets and their data.  I fixed it up to have "instance data",
but it was a rough botch.  There are several limitations that I
did not work around.

I plan to rework all this tomorrow by changing Tcl::Tk to have
each Tcl::Tk object start with the instance control, like the
interp and the %W hash.  This will trickle down through all the
other bits (hopefully).  Each widget will be an object that can
have instance data, overloading the stringify to return the path.

I think (hope) this will address the limitations as well as
making the code simply cleaner.  If anyone has reservations or
great ideas, give them now ...

-- 
     Jeff Hobbs, The Tcl Guy
     http://www.ActiveState.com/, a division of Sophos

[tcltk-perl] about difference in Tk.pm between 1.49 and 1.50

[Vadim K. <va...@ar...>]

Dear Jeff,

I see you did many changes in Tk.pm.

But in case you do such global replacement, please make sure you're doing
replacement correctly.

For me, there is no much improvement in writing everywhere

   my $int = $W{$$wid}->{'INT'};


instead of
   my $int = $wint{$$wid};

Here is why:
both are not perfect but yours is larger, yet will be a bit slower (takes
one more hash dereference).

For me, better is just to write

$wid->interp;


Actually, when doing such global replacement, please let it be finished way
of doing things, and let us agree on how things will be done. I think those
global package-wide hashes should actually be part of Tcl::Tk interpreter
object.

As Gisle already mentioned, simple changes should go directly to CVS but
serious changes should be discussed first, may be best way is to send such
patches to this list first.

Best regards,
Vadim.

Re: [tcltk-perl] $widget->exists

[Jeff H. <je...@Ac...>]

Gisle Aas wrote:
> broke our app, because we used $bwtree->exists($path) to access the
> ".tree exists path" subcommand of BWTree.  After this change this
> method call was routed to winfo instead.  I fixed it in our sources be
> removing the winfo override for exists.  I suggest we make that
> official too.  There is already Tcl::Tk::Exists() for doing 'winfo
> exists' checks.

This is the correct way anyway, as the 'exists' method makes
most sense to be done without calling through the object
itself (it's like 'defined').

Jeff

[tcltk-perl] RE: $widget->exists

[Konovalov, V. <vko...@sp...>]

> My wish would be that there was a plain/easy to explain mapping from
> method calls to Tcl/Tk so that you can know which piece of
> documentation to look up.

I do not feel strong in creating documentation (I am not English native
speaker).
Improving documentation must be done, but my efforts are quite small here.

OTOH I think it will be possible for us to create a simple way (script) for
documentation to be used from existing Tcl/Tk installation, and adapted to
Tcl::Tk module on the fly, when requested.

Similar in spirit how methods are created on the fly, same way
documentation.

I am not sure whether it is at all possible though.
(documentation file on ActiveState's installation on Windows is file
doc\ActiveTclHelp.chm which is not to be parsed; but on Linux situation is
better: process result of 'man' command)

[tcltk-perl] Re: $widget->exists

[Gisle A. <gi...@Ac...>]

"Konovalov, Vadim" <vko...@sp...> writes:

> > The following change:
> > 
> >              * lib/Tcl/Tk.pm: perlTk compatibility: sub PathName,
> >              Exists, class, toplevel, parent, *all* winfo methods.
> > 
> > broke our app, because we used $bwtree->exists($path) to access the
> > ".tree exists path" subcommand of BWTree.  After this change this
> > method call was routed to winfo instead.  I fixed it in our sources be
> > removing the winfo override for exists.  I suggest we make that
> > official too.  There is already Tcl::Tk::Exists() for doing 'winfo
> > exists' checks.
> 
> Let it be like you said!
> 
> Will you insert this change by yourself?

Done.

> > Anyway, this illustrates that we need a better mechanism to deal with
> > conflicts like this.  There should be a way for force method calls to
> > resolve a particular way.
> 
> Firstly, you can always define specific method for any widget and no
> AUTOLOAD will mix with it.

Makes it harder to document sensibly what happens.  If the winfo
methods were $widget->winfo_foo instead there would not be this
problem.

> Personally to me, I very like current situation where exists such a
> mechanism when you can work in perlTk way even with new widgets. like in
> http://www.perlmonks.org/index.pl?node_id=346153

True.  I would not loose that.

My wish would be that there was a plain/easy to explain mapping from
method calls to Tcl/Tk so that you can know which piece of
documentation to look up.

On top of this we mix in PerlTk methods that only become available
when you request PerlTk compatiblity.  For these methods we don't
require consistency in naming or behaviour.

--Gisle

[tcltk-perl] RE: $widget->exists

[Konovalov, V. <vko...@sp...>]

> The following change:
> 
>              * lib/Tcl/Tk.pm: perlTk compatibility: sub PathName,
>              Exists, class, toplevel, parent, *all* winfo methods.
> 
> broke our app, because we used $bwtree->exists($path) to access the
> ".tree exists path" subcommand of BWTree.  After this change this
> method call was routed to winfo instead.  I fixed it in our sources be
> removing the winfo override for exists.  I suggest we make that
> official too.  There is already Tcl::Tk::Exists() for doing 'winfo
> exists' checks.

Let it be like you said!

Will you insert this change by yourself?



> 
> Anyway, this illustrates that we need a better mechanism to deal with
> conflicts like this.  There should be a way for force method calls to
> resolve a particular way.

Firstly, you can always define specific method for any widget and no
AUTOLOAD will mix with it.

Secondly, situation was worse recently, when all non-trivial widgets created
methods in Tcl::Tk::Widget package and therefore could mix with each other
easily.



Also, there exists a TODO comment in AUTOLOAD and there is an explanation
about restricting method names in Widget autoloading mechanism

Personally to me, I very like current situation where exists such a
mechanism when you can work in perlTk way even with new widgets. like in
http://www.perlmonks.org/index.pl?node_id=346153


Best regards,
Vadim.

[tcltk-perl] $widget->exists

[Gisle A. <gi...@Ac...>]

The following change:

             * lib/Tcl/Tk.pm: perlTk compatibility: sub PathName,
             Exists, class, toplevel, parent, *all* winfo methods.

broke our app, because we used $bwtree->exists($path) to access the
".tree exists path" subcommand of BWTree.  After this change this
method call was routed to winfo instead.  I fixed it in our sources be
removing the winfo override for exists.  I suggest we make that
official too.  There is already Tcl::Tk::Exists() for doing 'winfo
exists' checks.

Anyway, this illustrates that we need a better mechanism to deal with
conflicts like this.  There should be a way for force method calls to
resolve a particular way.

--Gisle

Re: [tcltk-perl] Re: EV subroutine in Tcl.pm

[Vadim K. <va...@ar...>]

> I will do this conversion, but it may not be until Monday morning
> as I'm not sure when I'll get into work this weekend (it's a nice,
> sunny weekend here for a change :) ).

ok, I'll do this myself.

Have a nice weekend :)

Best regards,
Vadim.

Re: [tcltk-perl] Re: EV subroutine in Tcl.pm

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:
>>>I really want to change name of Tcl::EV to Tcl::Ev
	...
> Jeff, will you perform renaming EV->Ev? Please?

I will do this conversion, but it may not be until Monday morning
as I'm not sure when I'll get into work this weekend (it's a nice,
sunny weekend here for a change :) ).

Jeff

Re: [tcltk-perl] Re: EV subroutine in Tcl.pm

[Vadim K. <va...@ar...>]

> > I really want to change name of Tcl::EV to Tcl::Ev
> >
> > ALL-CAPS names usually used for constant subroutines and for some
special
> > for Perl subroutines, and never such names are used to just name
ordinary
> > subroutine, like in our case.
> >
> > Please add your argumentation, and better yet let us agree to rename it.
>
> OK, I was just trying to differentiate from the original.
> I have started using it in code, so I will just have to watch
> for that commit and change those references.

Differentiate from original is easy - once you see \\'XY' you catch an error
and ask user to fix.
But once you started using that newer scheme -- indeed, it's another.

But as long as Tcl.pm changes are very hot, it will be easy to change this
back, because you remember what you recently did.
And, again, once you'll rename EV->Ev, you'll get diagnostic quickly and
will fix them.

>
> I still prefer using the ('%X', '%Y') argument style though.
> Since users have to change their code around anyway, it seems
> safe to make it more explicit what they are doing.  I suppose
> you could still support \\'XY' given ref-ref-scalar's are
> unlikely to be used as regular arguments.

This is not what I need :)
As long as there is no simpliest to user just Ev('X'), any reasonable scheme
is fine to me.

Jeff, will you perform renaming EV->Ev? Please?

I will be very grateful.

Best regards,
Vadim.

[tcltk-perl] Re: EV subroutine in Tcl.pm

[Jeff H. <je...@Ac...>]

Vadim Konovalov wrote:
> I really want to change name of Tcl::EV to Tcl::Ev
> 
> ALL-CAPS names usually used for constant subroutines and for some special
> for Perl subroutines, and never such names are used to just name ordinary
> subroutine, like in our case.
> 
> Please add your argumentation, and better yet let us agree to rename it.

OK, I was just trying to differentiate from the original.
I have started using it in code, so I will just have to watch
for that commit and change those references.

I still prefer using the ('%X', '%Y') argument style though.
Since users have to change their code around anyway, it seems
safe to make it more explicit what they are doing.  I suppose
you could still support \\'XY' given ref-ref-scalar's are
unlikely to be used as regular arguments.

-- 
     Jeff Hobbs, The Tcl Guy
     http://www.ActiveState.com/, a division of Sophos

[tcltk-perl] EV subroutine in Tcl.pm

[Vadim K. <va...@ar...>]

I really want to change name of Tcl::EV to Tcl::Ev

ALL-CAPS names usually used for constant subroutines and for some special
for Perl subroutines, and never such names are used to just name ordinary
subroutine, like in our case.

Please add your argumentation, and better yet let us agree to rename it.

Best regards,
Vadim.

Re: [tcltk-perl] %replace_options question

[Vadim K. <va...@ar...>]

> > while implementing pTk compatibility widget "BrowseEntry" I
> > used %replace_options and it looks to me keys to this hash
> > must be perlTk name and not Tcl/Tk name, because different
> > widgets could be implemented with a single Tcl/Tk widget (it
> > appears BrowseEntry cound be implemented with ComboBox)
> >
> > Should I change %replace_options logic a bit?
>
> If that's what is necessary, although I don't know quite what you mean
> without an example ...

I just added few lines to implement perlTk's BrowseEntry
Browseentry.pm in perlTk lives in "Tixish" directory, but I did not found it
in Tix.

Nevertheless, it appears BrowseEntry could be implemented with ComboBox.

So I add
     ComboBox   => {-choices=>'-values'},
to %replace_options

This is slightly odd, because someone who previously inserted that line to
hash did not intended to have "-choices".

Another way will be better: I'll add key pair
     BrowseEntry   => {-choices=>'-values'},
and nothing outside said widget will be touched.

Interesting to say, implementing perlTk's TList in a level needed by my
application, ended with adding just one line to %ptk2tcltk and fwe lines to
need_tk!

Vadim.

RE: [tcltk-perl] %replace_options question

[Jeff H. <je...@Ac...>]

> while implementing pTk compatibility widget "BrowseEntry" I 
> used %replace_options and it looks to me keys to this hash 
> must be perlTk name and not Tcl/Tk name, because different 
> widgets could be implemented with a single Tcl/Tk widget (it 
> appears BrowseEntry cound be implemented with ComboBox)
> 
> Should I change %replace_options logic a bit?

If that's what is necessary, although I don't know quite what you mean
without an example ...

Jeff