question about ActiveState's Tkx

In the Tcl.pm help, in the section
"Moving Tcl/Tk around with Tcl.pm",
it says:

In order to create Tcl/Tk application with this module, you need to make sur
e
that Tcl/Tk is available within visibility of this module. There are many wa
ys
to achieve this, varying on ease of starting things up and providing flexibl
e
moveable archived files.
Following list enumerates them, in order of increased possibility to change 
location.
First method
Install Tcl/Tk first, then install Perl module Tcl, so installed Tcl/Tk will
 be used.
This is most normal approach, and no care of Tcl/Tk distribution is taken
on Perl side (this is done on Tcl/Tk side)
...

I had installed Perl first. So I uninstalled it, and re-installed it.
But it doesn't seem to have worked.

That is to say, running

use Tkx;
print join "\n",  (Tkx::SplitList(Tkx::set('auto_path')));


lists

C:/Perl/lib/auto/Tcl/tkkit.dll/lib/tcl8.4
C:/Perl/lib/auto/Tcl/tkkit.dll/lib
C:/Perl/lib/auto/Tcl/tkkit.dll/lib/tk8.4

which seems to mean that tkkit.dll is being used, not Tcl/Tk.

( note: I couldn't get
use Tcl;
my $i = new Tcl;
print join "\n", ($i->GetVar('auto_path'));
to return anything.)

So how can I get Tkx.pm (and Tcl.pm)  to use Tcl/Tk instead of tkkit.dll?

(If nothing else, it should make using the Tcl/tk docs easier.)

thanks,
~greg

On Mar 2, 2:20 pm, "~greg" <g...@remove-comcast.net> wrote:
> In the Tcl.pm help, in the section
> "Moving Tcl/Tk around with Tcl.pm",
> it says:
>
>   In order to create Tcl/Tk application with this module, you need to make
 sure
>   that Tcl/Tk is available within visibility of this module. There are man
y ways
>   to achieve this, varying on ease of starting things up and providing fle
xible
>   moveable archived files.
>    Following list enumerates them, in order of increased possibility to ch
ange location.
>    First method
>    Install Tcl/Tk first, then install Perl module Tcl, so installed Tcl/Tk
 will be used.
>    This is most normal approach, and no care of Tcl/Tk distribution is tak
en
>     on Perl side (this is done on Tcl/Tk side)
>     ....

This is the generic Tcl.pm docs, whereas is appears you are using
ActivePerl, which includes Tkx.  We make some minor patches in order
to ensure there is a working and _reliable_ Tcl/Tk available.  This is
because ActivePerl's ppm UI is written in Tkx.

> which seems to mean that tkkit.dll is being used, not Tcl/Tk.

Yes, the tkkit.dll is a single-file dll that encompasses Tcl/Tk +
extensions.  This is patched in as the "default" Tcl/Tk to be found.

> So how can I get Tkx.pm (and Tcl.pm)  to use Tcl/Tk instead of tkkit.dll?

This can be controlled with the PERL_TCL_DLL environment variable
(point to another tclXY.dll should generally work), or $Tcl::DL_PATH
in Perl.

Jeff

Perhaps you could consider using Tk independently from Tcl.
I have heard that there is a module on CPAN for this.
--S

"Jeff Hobbs" <jeff.hobbs@gmail.com> wrote in message news:6259432e-43cd-43d6-856c-df79c6cf7
d15@e25g2000prg.googlegroups.com...
> On Mar 2, 2:20 pm, "~greg" <g...@remove-comcast.net> wrote: 
>
> This is the generic Tcl.pm docs, whereas is appears you are using
> ActivePerl, which includes Tkx.  We make some minor patches in order
> to ensure there is a working and _reliable_ Tcl/Tk available.  This is
> because ActivePerl's ppm UI is written in Tkx.
> 
>
> Yes, the tkkit.dll is a single-file dll that encompasses Tcl/Tk +
> extensions.  This is patched in as the "default" Tcl/Tk to be found.
> 
>
> This can be controlled with the PERL_TCL_DLL environment variable
> (point to another tclXY.dll should generally work), or $Tcl::DL_PATH
> in Perl.
>
> Jeff

~~~~~~~~~~~~~


Thank you!

First I have to say that I am flying in the dark here.
I've only just recently learned a little about TCL.
I'm not even sure how to formulate a clear questions.
So this will probably sound like rambling ....

It's my understanding that "::auto_path" points to the libraries that Tcl us
es.
Which is what I want access to. Possibly to override the ones in tkkit.dll.

I tried setting environmental variable PERL_TCL_DLL to C:\Tcl\bin\tcl85.dll
via "My Computer" > Properties > Advanced > Environmental Variables,
but it doesn't show up in %ENV, and it doesn't have any effect on auto_path.

Neither does setting $ENV{PERL_TCL_DLL} = 'C:/Tcl/bin/tcl85.dll';
That is,
use Tkx;
print join "\n",  (Tkx::SplitList(Tkx::set('auto_path')));


still prints the same C:/Perl/lib/auto/Tcl/tkkit.dll/lib/... paths.

I find that I can append to auto_path via eg

use Tkx;
Tkx::lappend('::auto_path', 'C:/Tcl/lib/tk8.5/ttk');
print join "\n",  (Tkx::SplitList(Tkx::set('auto_path')));


but I don't know if that makes the ttk library accessible,
or if inserting such paths in the front of auto_path would override
the default libraries. (I should test this, but I am trying to figure
out too many different things at the same time, and I'm just overloaded. )


It seems to me that the relevant section in Tcl.pm is this ....
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~
# (from Tcl.pm)
# ...
# consideration for moveable configuration of tcl/tk
# This is done before bootstraping, to make possible of searching of correct
# shared libraries

$Tcl::config::tcl_pm_path = [__FILE__=~/^(.*)Tcl\.pm$/i]->[0];
do "$Tcl::config::tcl_pm_path/Tcl.cfg" if -f "$Tcl::config::tcl_pm_path/Tcl.
cfg";

our $DL_PATH;
unless (defined $DL_PATH) {
$DL_PATH = $ENV{PERL_TCL_DL_PATH} || $ENV{PERL_TCL_DLL} || "";
}

unless ($DL_PATH) {
require Config;
for my $inc (@INC) {
my $tkkit = "$inc/auto/Tcl/tkkit.$Config::Config{so}";
if (-f $tkkit) {
$DL_PATH = $tkkit;
last;
}
}
}
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~

I think that means, first, that a "Tcl.cfg" file will somehow be used,
----if it exists somewhere relative to the Tcl.pm location.

(But there's no "Tcl.cfg" file in in my perl installation.
And I wouldn't know how to modify it, or make one )

Presumably Tcl.cfg can define $DL_PATH.

If it isn't defined, then $DL_PATH could
apparently be taken from the environmental variable
PERL_TCL_DL_PATH or PERL_TCL_DLL,
if one of these exists.

Then if all that falls through the
unless($DL_PATH) { ...}  get executed,
Which I think in effect must set
$DL_PATH to tkkit.dll .

But that's just wild speculation
because, to be honest,I don't understand any of it.

Then Tkx.pm seems to use Tcl.pm like this ....
~~~~~~~~~~~~~
package Tkx::i;
use Tcl;
my $interp;
my $trace_count = 0;
my $trace_start_time = 0;
BEGIN {
$Tcl::STACK_TRACE = 0;
$interp = Tcl->new;
$interp->Init;
}
~~~~~~~~~~~~~~~~

And bless you,
-if you can locate my confusion and help me out of it!

~greg

~~~~~~~~~~~~~~

ps:
(the following is a (mild) rant.
The point of it is that I like really Tkx,
except for this one thing....)

I wish that $interp wasn't local in Tkx.pm,

That is, I wish that Tkx::i::interp->Eval()
was accessible outside, so that whole
Tcl script lines could be evaluated.

As it is, I find that using Tkx::i::call()
is the easiest way to translate from Tcl/Tk programs to Tkx.
(I give an example of this below.)

But Tkx::i::interp would make it a lot easier.
The difference is that, as it says in Tcl.pm, ....

call (PROC, ARG, ...)
Looks up procedure PROC in the interpreter and invokes it using Tcl's eval s
emantics
that does command tracing and will use the ::unknown (AUTOLOAD) mechanism.
The arguments (ARG, ...) are not passed through the Tcl parser.
For example, spaces embedded in any ARG will not cause it to be split
into two Tcl arguments before being passed to PROC.

Which means I can not write eg
Tkx::i::interp->Eval("  pack .t -expand 'yes' -fill 'both'  ");

I have to write instead
Tkx::i::call(  pack => '.t', -expand=>'yes', -fill=>'both' );

etc, --which requires a more thinking when going from
Tcl/Tk to Tkx. And the wrappers would require still more thinking.

To use Tkx.pm effectively requires learning a little Tcl anyway.
The wrappers only add a layer of mist over the learning process.

In the Tkx::Tutorial it says that ...

For trivial programs like the one above using Tkx::widget wrappers
does not appear to be a win, but as the application grows and the
Tk path names  get longer it surely is.

and ....

This allow us conveniently to map most of the Tcl namespace to Perl.
If this mapping does not suit you, use Tkx::i::call($func, @args).
This will invoke the function named by $func with no name substitutions or m
agic.


But I am not sure that duplicating the namespace is more of a help,
or more a hindrance, when it comes to translating from Tcl/Tk to Tkx.

Tcl/Tk path names (dot notation) are extremely concise.
If necessary they could be made out of dotting perl strings.

It was confusion over things like this that made  the old Tk.pm
so hard to use.

Tcl is very clean. Which is why Tkx.pm is such a good idea.
So I don't understand why it has to be made to look more like Tk.pm.

I didn't like Tcl at first, but it really is beautiful.
And it's easy to learn, once you get over a few quirks.
Conceptually it's exquisite, - like Lisp and Forth.

~~~~~~~~

To see what I mean,
I translated a "text" widget taken from here:
[url]http://pages.cpsc.ucalgary.ca/~saul/personal/archives/Tcl-Tk_stuff/tcl_examples/[/
url]

using only Tkx::i::call().

This style made it very easy to translate from Tcl/Tk to Tkx.
(But Tkx::i::interp would make it even easier.)

~~~~~~~~~
use strict;
use warnings;

use Tkx qw(MainLoop);

*tcl = \&Tkx::i::call;

tcl
(
text => '.t',
-yscrollcommand => ".scroll set",
-setgrid => 'true',
-width => 40,
-height => 10,
-wrap => 'word');

tcl
(
scrollbar => '.scroll',
-command => ".t yview",
);

tcl(pack => '.scroll', -side => 'right', -fill=>'y');
tcl(pack => '.t', -expand=>'yes', -fill=>'both');

tcl('.t', 'tag','configure', 'bold_italics',
-font => "-family courier -size 12 -weight bold -slant italic");

tcl('.t','tag','configure', 'big',
-font => "-family helvetica -size 24 -weight bold");

tcl('.t','tag','configure', 'color1',
-foreground => 'red');

tcl('.t','tag','configure', 'sunken',
-relief => 'sunken', -borderwidth=>1);

tcl('.t','tag','bind','Ouch', '<1>', ".t insert end \"\\nOuch!\"");

tcl('.t',insert=>'end', "Here are a few text styles.\n");


tcl('.t',insert=>'end', "1. Bold italic text.\n", 'bold_italics');
tcl('.t',insert=>'end', "2. Larger Helvetica text.\n", 'big');
tcl('.t',insert=>'end', "3. Red text.\n", 'color1');
tcl('.t',insert=>'end', "4. Sunken text.\n", 'sunken');

tcl(button=>'.b',-text=>"5. An embedded Hello Button",
-command=>".t insert end \"\\nHello\"");

tcl('.t','window','create','end', -window=>'.b');
tcl('.t',insert=>'end', "\n");
tcl('.t',insert=>'end', "6. Text with a binding (try clicking me)", 'Ouch');
tcl('.t',insert=>'end', "\nAnd all this is editable!");


MainLoop();

"smallpond" <smallpond@juno.com> wrote in message news:6581288f-e715-4ac8-a84a-c04002a6a814
@e10g2000prf.googlegroups.com...
>
>
> Perhaps you could consider using Tk independently from Tcl.
> I have heard that there is a module on CPAN for this.
> --S


If you mean the old Tk.pm module,
- it's not maintained, and the book
hasn't been updated since 2002.

Tkx.pm is the way to go.
Just learn some Tcl.
It's good for you.

~greg wrote:

> If you mean the old Tk.pm module,
> - it's not maintained

Yes it is, well the CPAN version of perl-tk is. A new major update was
released earlier this year.

> Tkx.pm is the way to go.
> Just learn some Tcl.

Err.. this is the *perl-tk* newsgroup not a tcl newsgroup.

regards,

Colin

--
Colin Tuckley      |  +44(0)1903 236872  |  PGP/GnuPG Key Id
Debian Developer   |  +44(0)7799 143369  |     0x1B3045CE

Good advice is something a man gives when he is too old to set a bad
example. - La Rochefoucaud

On Mar 4, 6:31 pm, "~greg" <g...@remove-comcast.net> wrote:
> "smallpond" <smallp...@juno.com> wrote in messagenews:6581288f-e715-4ac8-a
84a-c04002a6a814@e10g2000prf.googlegroups.com...
> 
>
> If you mean the old Tk.pm module,
> - it's not maintained, and the book
> hasn't been updated since 2002.
>
> Tkx.pm is the way to go.
> Just learn some Tcl.
> It's good for you.


Tcl/Tk books in print from O'Reilly

Tcl/Tk in a Nutshell
By Jeff Tranter, Paul Raines
March 1999

Tcl/Tk Pocket Reference
By Paul Raines
October 1998

On Mar 4, 11:41 pm, Colin Tuckley <co...@tuckley.org> wrote:
> ~greg wrote: 
>
> Yes it is, well the CPAN version of perl-tk is. A new major update was
> released earlier this year.
> 
>
> Err.. this is the *perl-tk* newsgroup not a tcl newsgroup.

It is not actually necessary to learn Tcl (syntax-wise) to use Tkx.
All you need to know are the commands available.  All the syntax is
Perl-based, with the translation happening at a very efficient low
level.  The Tcl.pm module upon which Tkx is based is actually faster
and more memory efficient through the use of a rewritten Tcl bridge
than the older Perl/Tk is.  In fact, it should be possible to fully
reimplement Perl/Tk upon Tcl.pm, as Vadim has done in part with
Tcl::Tk.  It just requires someone to do it.

Jeff

"Jeff Hobbs" <jeff.hobbs@gmail.com> wrote in message news:4d5c833a-3453-4f66-88d7-ef701a39b
abb@h11g2000prf.googlegroups.com...
> On Mar 4, 11:41 pm, Colin Tuckley <co...@tuckley.org> wrote: 
>
> It is not actually necessary to learn Tcl (syntax-wise) to use Tkx.
> All you need to know are the commands available.  All the syntax is
> Perl-based, with the translation happening at a very efficient low
> level.  The Tcl.pm module upon which Tkx is based is actually faster
> and more memory efficient through the use of a rewritten Tcl bridge
> than the older Perl/Tk is.  In fact, it should be possible to fully
> reimplement Perl/Tk upon Tcl.pm, as Vadim has done in part with
> Tcl::Tk.  It just requires someone to do it.
>
> Jeff

~~~

That may be true. And I can't argue it anyway,
because I'm just beginning.

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 i
s
actually required to read those documents, for the purposes of Tkx,
it us not nearly so clear to anybody who's just starting out.

If you had to tutoring somebody about it, I guess you'd be
constantly saying things like: "don't pay any attention to that,
it's not important." But if you ever actually had to teach anybody anything,
then you ought to know how utterly hopeless that approach is.
It only engenders frustration and anger.

At the very least you have to say why this one set of binary bits
is extremely important, whereas this other set of binary bits,
--virtually identical as far as the student can see,  -is not at all importa
nt.

~~~

Second, it simply isn't true
And I give a counter example, now, to prove it.
~~

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

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))

And I just now tried that appraoch again,
and I get this error call ---

list element in quotes followed by "," instead of space

The last time I got an unbalanced something error.
~~

I don't completely understand it. But an idea
occurred to me. And I tried this ....

my $hold = $/;
undef $/;
open FILE,$file;
tk( '.2.1.t', 'insert', 'end', <FILE> );
close FILE;
$/ = $hold;

... and that works!

I though it would, because slurping
the file, in effect, puts the whole thing
on one TCL line, like this ....

'.2.1.t'  insert end <FILE>

whereas not slurping it puts it on several Tcl lines.
And in that case, I think, the Tcl interpreter puts
the whole thing in implicit braces. In other words,
it starts looking for a closing brace. And if the file
happens to contain braces, chances are there's
going to be an imbalance. Or a mysterious

list element in quotes followed by "," instead of space

~~~
The thing is, if I didn't know just the little bit about Tcl
that I've learnt, then this kind of thing would have completely defeated me.

I can't honestly recall if the old Tk.pm had Tcl-clarifiable problems like t
hat.
But I believe it did.



~greg

"Jeff Hobbs" <jeff.hobbs@gmail.com> wrote in message news:6259432e-43cd-43d6-856c-df79c6cf7
d15@e25g2000prg.googlegroups.com...
> On Mar 2, 2:20 pm, "~greg" <g...@remove-comcast.net> wrote: 
>
> This is the generic Tcl.pm docs, whereas is appears you are using
> ActivePerl, which includes Tkx.  We make some minor patches in order
> to ensure there is a working and _reliable_ Tcl/Tk available.  This is
> because ActivePerl's ppm UI is written in Tkx.
> 
>
> Yes, the tkkit.dll is a single-file dll that encompasses Tcl/Tk +
> extensions.  This is patched in as the "default" Tcl/Tk to be found.
> 
>
> This can be controlled with the PERL_TCL_DLL environment variable
> (point to another tclXY.dll should generally work), or $Tcl::DL_PATH
> in Perl.
>
> Jeff


That didn't seem to work for me.

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.)

But I am finding it very hard to tell which widgets are coming from which pa
ckages.
Which makes it very hard to use *any* documentation.

(I used
use Tkx;
Tkx::package_require('tile');
to get a ttk::notebook.
Maybe that overroad the basic tk text widget with something else??)



thanks,

~greg