question about ActiveState's Tkx

On Mar 7, 10:18 am, "~greg" <g...@remove-comcast.net> wrote:
> I don't know how to test which dll is being used,
> but I find that the tk text widget, in Tkx, seems to be deficient.
>
> That is, I get a "bad option" error on a text widget, namely  -----
>
>    bad option "count": must be  bbox, cget, compare, configure,
>    debug, delete, dlineinfo, dump, edit, get, image, index, insert,
>    mark, scan, search, see, tag, window, xview, or yview
>
> which means that
>
>    count, peer, and replace
>
> are missing (relative to the ActiveState Tcl/Tk document
> for the basic tk 'text' widget.)

Yes, the redirect sends you now to the Tk 8.5 documentation, but it is
Tk 8.4 that ships in the Tkx tkkit (8.4 was the officially stable
version until early this year).

Jeff

On Mar 6, 8:55 pm, "~greg" <g...@remove-comcast.net> wrote:
> But I will point out two things.
>
> First, the Tkx documentation completely defers to the Tcl/Tk documentation
.
> And while it may be perfectly obviously to you how little knowledge of Tcl
 is
> actually required to read those documents, for the purposes of Tkx,
> it us not nearly so clear to anybody who's just starting out.

This has more to do with the lack of time to write full and proper
documentation (it's all open source, anyone want to contribute?  ;) )
than that the Tcl/Tk docs are actually "just right" for your needs.

> I am using the notation
> *tk = \&Tkx::i::call,

See my other response for "designed syntax" for Tkx.  Perhaps you
prefer the direct function calls to the ->?

> The problem was that I tried to load a file
> into a text widget, like this:...
>
>   open FILE, $file;
>   tk( '.2.1.t', 'insert', 'end',  <FILE> );
>   close FILE;
>
> (where '.2.1.text' is the path name to the text widget (frames
> being named by plain digits))

You should never need to know the names of widgets in Tkx, although
you can assign them if you choose (with the -name => "myname" option).

> And I just now tried that appraoch again,
> and I get this error call ---
>
>    list element in quotes followed by "," instead of space

I believe the problem here is that <FILE> is being expanded into
multiple arguments, so you aren't actually passing the one arg you
think - it is being broken into many.

Jeff

"Jeff Hobbs" <jeff.hobbs@gmail.com> wrote in message news:158ce414-11c4-4d6d-b321-02fb5d650
834@e23g2000prf.googlegroups.com...
> On Mar 7, 10:18 am, "~greg" <g...@remove-comcast.net> wrote: 
>
> Yes, the redirect sends you now to the Tk 8.5 documentation, but it is
> Tk 8.4 that ships in the Tkx tkkit (8.4 was the officially stable
> version until early this year).
>
> Jeff




That does explain a lot!
~~
But now here's the remaining problem, as I understand it.

Near the conclusion to an exchange that can be found here:
http://community.activestate.com/fo...t-update-but-no
(the "Greg" asking the questions isn't me (i'm "~greg"))

"kjw" says: ----

I asked one of the Perl developers and here is part of his answer:

The concept of "precious" packages is gone.
PPM still relies on having certain packages available
and it tries to ensure its success by searching for modules in the 'perl' ar
ea
before it searches 'site'. For this to work it is highly desirable for the p
ackages
in the 'perl' area not to be removed or 'upgraded' unless this happens when
ActivePerl itself is.

He goes on to say that it is possible to force upgrades of packages
in the 'perl' area, but it is unnecessary and may possibly cause problems.
Cheers,
kjw

(It seems to me that searching "perl/lib" before "site/lib" is backwards.
And that upgrading packages in the 'perl' area *is* sometimes necessary,
as it seems to be in the present case. But anyway, ..)

I "reinstalled" Tkx.pm, and the result was two installations of Tkx.pm,
the original one in the (*effectively* precious) "perl" area,
and the new one in the "site" area.

But this was futile for several reasons.
Perl searches the "perl" area first (which I think is crazy)
and so, if I don't try and succeed in removing Tkx from the "perl" area,
--against advise, --then the "site" version can never be used,
--making any potential upgrades to Tkx.pm, or any other
"perl" area module, impossible! (Which is crazy.)

But worse, Tkx.pm depends on Tcl.pm.
And Tcl.pm can not be either "reinstalled" nor "removed"!

That is, in the GUI ppm4 those options are grayed out.
And %ppm search tcl reports:
*** no packages matching 'tcl' found ***

(The ActiveState 5.10 build status report for Tcl.pm version 0.95
says it FAILs on all 4 systems!)

To get Tkx.pm (and Tcl.pm) to use Tcl/bin/tcl85.dll instead of Perl/lib/auto
/Tcl\tkkit.dll
I tried the advice about the environment variables PERL_TCL_DLL
and PERL_TCL_DL_PATH, and $DL_PATH.
And while I don't know anything about Tcl.cfg files,
I don't think that would work either. The reason being,
as I quoted before ....

(from Tcl.pm)
# This is done before bootstraping, to make possible
#  of searching of correct shared libraries

Which, if I understand the word "bootstraping" correctly,
means that the information is already hard-wired in the tkkit.dll !
(Or somewhere anyway that can not be gotten around
simply by changing an environmental variable.)

As I said somewhere, the first thing I tried was
uninstalling and reinstalling the whole perl installation
(because I had installed Tcl/Tk after,  not before, perl.)
And that didn't work. And now I think I understand why.

The whole point of ActiveState perl is that everything is pre-compiled.
Meaning that when you install it, it does not do a make
(or the compile, or "bootstrap", part of make anyway)
of things like Tcl.pm. That was already done before
it landed on my computer. Which means that the hard
wired path to tkkit.dll  can not be gotten around by doing
a total re-install of perl !

And since it can not be gotten around by reinstalling Tcl.pm either,
since Tcl.pm and tkkit.dll are so damn dogged,
the upshot is that there is quite simply no way of getting
Tkx.pm to use Tcl/bin/tcl85.dll instead of Perl/lib/auto/Tcl/tkkit.dll !

Which defeats one of the advertised goals ---

The benefit of this {the Tkx.pm} approach compared
to Nick Ing-Simmons's classic Tk.pm module
is that you can always use the latest features that Tk/Tcl
provides and that you can use Tcl's native megawidgets directly.
Tk.pm has stagnated recently because of the huge effort needed to port
it to run with newer versions of Tk.  The downside of the Tkx approach
is that you will need to know a bit about Tcl and that you have to
install Tcl/Tk on both your development and deployment systems.
- Gisle Aas

tkkit.dll perhaps resolves that D&D downside,
but if it can't be over-ridden, then it defeats the other mentioned benefits
.

Being Tk 8.4, and not Tk 8.5, as you say, -- just rubs it in! :)

~greg.

(I smile, because I am acutely aware that it really is
free and open-source. Rather like a kid on christmas with a big pile
of great new toys, and finding that one of them is "batteries not included."
As in other areas of life, delaying the goal only increases the ultimate ple
asure.)

On Mar 8, 3:56 am, "~greg" <g...@remove-comcast.net> wrote:
> But now here's the remaining problem, as I understand it.
>
> Near the conclusion to an exchange that can be found here:http://community.activestate.c


Yes, there is still a limited concept of precious packages, in that
you can update modules which will bork core programs like ppm, so you
need to do these updates with that knowledge.  Only the ppm UI relies
on Tkx though.

> I "reinstalled" Tkx.pm, and the result was two installations of Tkx.pm,
> the original one in the (*effectively* precious) "perl" area,
> and the new one in the "site" area.
>
> But this was futile for several reasons.
> Perl searches the "perl" area first (which I think is crazy)
> and so, if I don't try and succeed in removing Tkx from the "perl" area,
> --against advise, --then the "site" version can never be used,
> --making any potential upgrades to Tkx.pm, or any other
> "perl" area module, impossible! (Which is crazy.)

For this one, you are best off asking directly on the ActivePerl
mailing list.

> But worse, Tkx.pm depends on Tcl.pm.
> And Tcl.pm can not be either "reinstalled" nor "removed"!

The Tkx used is compatible with all the current versions of Tcl, and
Tcl is precious in the sense that it ties at the low-level C bridge
for us.

> (The ActiveState 5.10 build status report for Tcl.pm version 0.95
> says it FAILs on all 4 systems!)

The ppm 5.10 module builds are still a work in progress to achieve
maximum module build success.

> To get Tkx.pm (and Tcl.pm) to use Tcl/bin/tcl85.dll instead of Perl/lib/au
to/Tcl\tkkit.dll
> I tried the advice about the environment variables PERL_TCL_DLL
> and PERL_TCL_DL_PATH, and $DL_PATH.
> And while I don't know anything about Tcl.cfg files,
> I don't think that would work either. The reason being,
> as I quoted before ....

These work quite well, as seen here:

C:\>perl -MTcl -e "my $i = Tcl->new; $i->Init; print $i->call('info',
'patchlevel');"
8.4.17
C:\>set PERL_TCL_DL_PATH=C:\Tcl\bin\tcl85.dll

C:\>perl -MTcl -e "my $i = Tcl->new; $i->Init; print $i->call('info',
'patchlevel');"
8.5.1

> it landed on my computer. Which means that the hard
> wired path to tkkit.dll  can not be gotten around by doing
> a total re-install of perl !

Again, not true - see above.

Jeff

"Jeff Hobbs" <jeff.hobbs@gmail.com> wrote in message news:db6aab56-c648-491f-a3e7-e928d66ef
1b1@s13g2000prd.googlegroups.com...
> On Mar 8, 3:56 am, "~greg" <g...@remove-comcast.net> wrote: 
>
> Yes, there is still a limited concept of precious packages, in that
> you can update modules which will bork core programs like ppm, so you
> need to do these updates with that knowledge.  Only the ppm UI relies
> on Tkx though.
> 
>
> For this one, you are best off asking directly on the ActivePerl
> mailing list.
> 
>
> The Tkx used is compatible with all the current versions of Tcl, and
> Tcl is precious in the sense that it ties at the low-level C bridge
> for us.
> 
>
> The ppm 5.10 module builds are still a work in progress to achieve
> maximum module build success.
> 
>
> These work quite well, as seen here:
>
> C:\>perl -MTcl -e "my $i = Tcl->new; $i->Init; print $i->call('info',
> 'patchlevel');"
> 8.4.17
> C:\>set PERL_TCL_DL_PATH=C:\Tcl\bin\tcl85.dll
>
> C:\>perl -MTcl -e "my $i = Tcl->new; $i->Init; print $i->call('info',
> 'patchlevel');"
> 8.5.1
> 
>
> Again, not true - see above.
>
> Jeff


What'd I tell ya? That gets the batteries! I just needed faith.
(but for me it went from 8.4.something(not 17) to 8.5.0 (not 8.5.1) )

Looking back, when I had set  that variable from the command line,
it only lasted for that particular "cmd /k" session.

And when I set it via "My Computer"'s properties, it didn't work at all.
So I removed it from that environment before I tried anything else.

This time I left it there. And then re-booted.
And that made it stick. And now it works.

The upshot: The root of the problem was that I didn't
(still don't) have a firm grasp of window's environments!


Thank you infinitely, especially for your patience,

~greg

On Mar 10, 2:04 pm, "~greg" <g...@remove-comcast.net> wrote:
> Looking back, when I had set  that variable from the command line,
> it only lasted for that particular "cmd /k" session.
>
> And when I set it via "My Computer"'s properties, it didn't work at all.
> So I removed it from that environment before I tried anything else.
>
> This time I left it there. And then re-booted.
> And that made it stick. And now it works.
>
> The upshot: The root of the problem was that I didn't
> (still don't) have a firm grasp of window's environments!

If you set env variables from the Desktop Properties dialog, then you
have to start a _new_ command shell to get the changed variables, or
at worst log in/out.  Just a tidbit for next time, as restarting can
be quite a long process.

Jeff