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

RE: [tcltk-perl] Menu changes ??

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

> I see you are working on menus ... the AUTOLOAD problem you 
> just fixed, but now I see my menus created flat across the 
> entire first level (instead of as submenus).  Can you explain 
> what you are trying to do with that area?

Along the same lines, I'm not sure that the way that
create_widget_package and create_method_in_widget_package
are "correct".  They have different method inheritance
behavior as the previous Tk.pm.

For example, DialogBox used to get "resizable" from the
AUTOLOAD that handled Toplevels.  Now I get an error that
that isn't a recognized method.  Are only the created
methods in a widget package then recognized?  This makes
it to hard to make renamed/megawidgets.  Is there an easy
way to correct inheritance while maintaining the
separation you were trying to achieve?

Jeff

[tcltk-perl] Menu changes ??

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

Vadim,

I see you are working on menus ... the AUTOLOAD problem you
just fixed, but now I see my menus created flat across the
entire first level (instead of as submenus).  Can you explain
what you are trying to do with that area?

Thanks,

Jeff

RE: [tcltk-perl] RE: Tcl-Tk-0.77

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

> > Can you elaborate on what you mean here?  I think I understand it to 
> > mean relocatable shared libs on any platform, but I'm not quite sure.
> 
> I was thinking only for Windows, but yes, having such a 
> feature on all platforms must be done, not only for one of them.
> 
> I meant that from time to time it is needed to package all 
> required files into one executable so to have a possibility 
> to run it regardless whether computer have Tcl (or Perl) 
> installed. This is why "starkit"/tclkit is needed, and Perl's PAR.

We have starkits on the Tcl side, but not dll-based ones.  I
would have to look into that further.  In any case, Windows
is the one platform I'm least worried about, because cwd and
the path to the executable are guaranteed to be in the load
path, which makes relocation unnecessary (as it also has
defined lookup paths in Tcl).  It's the other platforms that
are more ornery.

> > operate like the Tcl browser plugin.  There would be no implicit 
> > dependencies on a particular set of Tcl/Tk dlls.  Instead you would 
> > start up and then try to load the Tcl and Tk dlls based on a set of 
> > heuristics.  This frees you from

> It would be fine if mentioned "heuristic" could be configured 
> somehow. Most obviously - to have a way to specify exact 
> location of binaries. Up to now I used some hack for this.

You define the heuristic in code, but currently on Windows
the Tcl browser plugin looks in:

1) Hard-coded (binary patchable) directory
2) Path based registry location of installed ActiveTcl

and on Unix:

1) TCL_PLUGIN_DLL env var
2) Hard-coded (binary patchable) directory
3) any compatible version on LD_LIBRARY_PATH

Jeff

Re: [tcltk-perl] RE: Tcl-Tk-0.77

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

> > BTW it would be good to develope a feature when Tcl/Tk
> > binaries, that Tcl::Tk use, could live in any directories, so
> > to ease creating of distributions that could be moved and
> > executed without requiring TCL to be installed (it is really
> > easy and I use this at work).
>
> Can you elaborate on what you mean here?  I think I understand
> it to mean relocatable shared libs on any platform, but I'm
> not quite sure.

I was thinking only for Windows, but yes, having such a feature on all
platforms must be done, not only for one of them.

I meant that from time to time it is needed to package all required files
into one executable so to have a possibility to run it regardless whether
computer have Tcl (or Perl) installed.
This is why "starkit"/tclkit is needed, and Perl's PAR.


>
> I've thought about having an optional configuration option for
> Tcl::Tk that uses the stubs libraries.  It is a bit tricky, but
> then it would operate like the Tcl browser plugin.  There
> would be no implicit dependencies on a particular set of Tcl/Tk
> dlls.  Instead you would start up and then try to load the Tcl
> and Tk dlls based on a set of heuristics.  This frees you from
>
> a) implicit dll tiedown
> b) version dependency (can use Tcl 8.5 even if compiled for 8.4)
> c) location dependency (see the npWin.c to see how I allow for
>    several locations)

It would be fine if mentioned "heuristic" could be configured somehow. Most
obviously - to have a way to specify exact location of binaries. Up to now I
used some hack for this.

>
> NpCreateMainInterp:
>
http://cvs.sourceforge.net/viewcvs.py/*checkout*/tclplugin/tclplugin/generic
/
> npInterp.c?content-type=text%2Fplain&rev=1.6
>
> NpLoadLibrary:
>
http://cvs.sourceforge.net/viewcvs.py/*checkout*/tclplugin/tclplugin/win/npW
i
> n.c?content-type=text%2Fplain&rev=1.7
>
> This would go in Tcl.xs:BOOT

Great.

Best regards,
Vadim.

RE: [tcltk-perl] RE: Tcl-Tk-0.77

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

> BTW it would be good to develope a feature when Tcl/Tk=20
> binaries, that Tcl::Tk use, could live in any directories, so=20
> to ease creating of distributions that could be moved and=20
> executed without requiring TCL to be installed (it is really=20
> easy and I use this at work).

Can you elaborate on what you mean here?  I think I understand
it to mean relocatable shared libs on any platform, but I'm
not quite sure.

I've thought about having an optional configuration option for
Tcl::Tk that uses the stubs libraries.  It is a bit tricky, but
then it would operate like the Tcl browser plugin.  There
would be no implicit dependencies on a particular set of Tcl/Tk
dlls.  Instead you would start up and then try to load the Tcl
and Tk dlls based on a set of heuristics.  This frees you from

a) implicit dll tiedown
b) version dependency (can use Tcl 8.5 even if compiled for 8.4)
c) location dependency (see the npWin.c to see how I allow for
   several locations)

NpCreateMainInterp:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/tclplugin/tclplugin/gene=
ric/
npInterp.c?content-type=3Dtext%2Fplain&rev=3D1.6

NpLoadLibrary:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/tclplugin/tclplugin/win/=
npWi
n.c?content-type=3Dtext%2Fplain&rev=3D1.7

This would go in Tcl.xs:BOOT

Jeff

[tcltk-perl] Trying to do META.yml more correct

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

I wonder if the followinf patch will made META.yml better:

--- META.yml.orig	Sat Apr 17 11:40:26 2004
+++ META.yml	Mon Apr 19 17:58:06 2004
@@ -7,8 +7,8 @@
 index:
   file:
   - lib/Tcl/Tk.pm
-no_index:
-  dir:
+private:
+  directory:
   - demos
   - tk-demos
 keywords:



Best regards,
Vadim.

[tcltk-perl] Simple Tcl-Tk experiment with BLT

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

I was pleased to notice that once BLT is installed (project BLT on
sourceforge.net site) it is extremely easy to manipulate from perl with
perlTk syntax.

That is, although gaining perlTk compatibility is easy and not completed,
but Tcl::Tk module is complete enough to create new applications with this
approach, like Jeff already mentioned.

Screenshot is at
http://home.peterstar.net/vkonovalov/BLT-tests/btl-test.jpg
http://home.peterstar.net/vkonovalov/BLT-tests/btl-test.pl.html

(There exists a small problem - BLT widgets typically invoked as blt::graph,
and either "import blt::*" should be used, or there could be a conflict in
widget names, but it is really easy to work aroud).


I'll try creating some explanations for publishing demos to web, but I am
extremely slow on this. And homepage on SF is not ready for web publishing
yet?

Best regards,
Vadim.

Re: [tcltk-perl] RE: Tcl-Tk-0.77

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

> > Saw the module on CPAN. My question is why not? Why doesn't
> > the Perl community use that module to interface with Tk since
> > it allows you to stay up-to-date with Tk itself?

It becames obvious that web page describing and illustrating features is
required.
There must be screenshots of Perl application that use Tcl/Tk with standard
widgets, and with some pure-Tcl and some unusual for perlTk world widgets,
(like BLT?)

Downloadable demos that could be executed also will be good. BTW it would be
good to develope a feature when Tcl/Tk binaries, that Tcl::Tk use, could
live in any directories, so to ease creating of distributions that could be
moved and executed without requiring TCL to be installed (it is really easy
and I use this at work).

"demo" and "tk-demo" directories of Tcl::Tk must be updated and improved.

Vadim.

Re: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

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

> > In case we'll move out perlTk compatibility to separate
> > module, what will stay in Tcl::Tk? Only few very old
> > subroutines like "label", "toplevel" and so on?
>
> There are multiple levels of compatability.  The basic coding
> style, as noted above, it worth keeping.  However, there are
> a lot of Perl/Tk-isms that needn't be repeated in a "clean"
> Tcl::Tk, like modifications to core commands that do not
> reflect the usual behavior of Tk.  There is also a ton of
> extra widgets that could be moved over.

agreed.
And subroutine "Darken", for example, that was inserted unmodified from
perlTk, is a very first candidate to move out.


>
> I would also like to add a "DeclareWidget" sub in Tcl::Tk
> that allows the use (or some submodule) to declare that it is
> making a widget available (freeing up the need to hack the
> ptk2tcltk hash).  Something like:
>
> Tcl::Tk::Declare('BWTree',    # name in Perl
>      'tree',      # name in Tcl
>      'BWidget',   # required Tcl package
>      'Tree::use', # extra code (if necessary)
>     )

It seems to me that Tcl::Tk::Declare is similar in spirit to
create_ptk_widget_sub.
It could be renamed, its interface could be improved and so on... but
create_ptk_widget_sub actually creates widget's subroutine and used from
AUTOLOAD.

Or may be yours Tcl::Tk::Declare will be implemented using a call to
create_ptk_widget_sub?

existance of hash like %ptk2tcltk could be considered like not a hack, but
rather some kind of correct declaration of relationship (and its design
could still be improved to be, say, hash of hashes that declare properties
or something like that).

This hash allows us to create things only when needed.

Creating subroutines when required could be accomplished by standard perl's
Autoload.pm/Autosplit.pm, but I am not very like using it. It must be used
when module is large enough, and probably should be avoided otherwise (to
not complicate things)

> > May be instead of doing special compatiiblity layer for
> > perlTk, may be it could be reasonable to just use perlTk
> > syntax as main way of doing GUI in perl? Many people just
> > used to using that syntax from perl, and there are books about it.
>
> Right, as above, but with minor mods.  I've noticed that the
> Perl/Tk docs aren't accurate often enough that if we start
> to veer from them, it won't be a big deal.

Indeed.

> > BTW (unrelated issue) if a line in Tk.pm "*{Tk::Exists} =
> > \&Tcl::Tk::Exists;" is commented out, it is possible to debug
> > Tcl::Tk code ising "ptkdb" debugger, which uses perlTk.
>
> Cool, but why is that one line needed?  Are you actually

I used it for trying some perlTk program, but this line really could be
deleted.

> loading Perl/Tk as well?  I intentionally turn on the
> tk_gestapo to avoid such interactions from occuring, as it
> may lead to undesired consequences.

it appears to be possible to do debugging even Tcl::Tk.pm with ptkdb, which
uses perlTk. And I did it succesfully.
I use ptkdb for quite long, and moving to console-mode debugger is not
convenient for me.

Vadim.

RE: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

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

> Actually 'use Tcl::Tk q(:perlTk);' needed only to export 
> MainWindow, MainLoop functions and few other, and nothing 
> more. Most perlTk syntax is available even without that qw(:perlTk)
> 
> Currently you still can write using "perlTk syntax":
> 
> use Tcl::Tk;
> $mw = Tcl::Tk::MainWindow; 
> $mw->Button(-text=>'test',-command=>sub{print 'test'})->pack; 
> Tcl::Tk::MainLoop;

This is in fact how we are setting our preferred Perl/Tcl::Tk
coding style, to use $mw->Widgettype as the way to create
widgets.  While it's not as "simple" as the usual Tcl style,
it is "clean" from the Perl perspective and works well.

> > A separate module is cleaner.  I would actually prefer that, but it is 
> > certainly an API change.  If we then end up with two ways of doing 
> > this because we need to stay compatible I rather just keep as it is.
> 
> In case we'll move out perlTk compatibility to separate 
> module, what will stay in Tcl::Tk? Only few very old 
> subroutines like "label", "toplevel" and so on?

There are multiple levels of compatability.  The basic coding
style, as noted above, it worth keeping.  However, there are
a lot of Perl/Tk-isms that needn't be repeated in a "clean"
Tcl::Tk, like modifications to core commands that do not
reflect the usual behavior of Tk.  There is also a ton of
extra widgets that could be moved over.

I would also like to add a "DeclareWidget" sub in Tcl::Tk
that allows the use (or some submodule) to declare that it is
making a widget available (freeing up the need to hack the
ptk2tcltk hash).  Something like:

	Tcl::Tk::Declare('BWTree',    # name in Perl
			     'tree',      # name in Tcl
			     'BWidget',   # required Tcl package
			     'Tree::use', # extra code (if necessary)
			    )

There may be other options, but you get the idea.  Perhaps
even do it in option => value syntax to extend it easier in
the future.

> May be instead of doing special compatiiblity layer for 
> perlTk, may be it could be reasonable to just use perlTk 
> syntax as main way of doing GUI in perl? Many people just 
> used to using that syntax from perl, and there are books about it.

Right, as above, but with minor mods.  I've noticed that the
Perl/Tk docs aren't accurate often enough that if we start
to veer from them, it won't be a big deal.

> BTW (unrelated issue) if a line in Tk.pm "*{Tk::Exists} = 
> \&Tcl::Tk::Exists;" is commented out, it is possible to debug 
> Tcl::Tk code ising "ptkdb" debugger, which uses perlTk.

Cool, but why is that one line needed?  Are you actually
loading Perl/Tk as well?  I intentionally turn on the
tk_gestapo to avoid such interactions from occuring, as it
may lead to undesired consequences.

Jeff

[tcltk-perl] RE: Tcl-Tk-0.77

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

Robert Hicks wrote:
> Saw the module on CPAN. My question is why not? Why doesn't
> the Perl community use that module to interface with Tk since
> it allows you to stay up-to-date with Tk itself?

Robert,

Perl/Tk and Perl's Tcl::Tk module have both been around for a
while, but Perl/Tk was more complete at first, offering a
simpler fully itegrated solution.  At this point for Tcl::Tk
you are still required to have a local Tcl/Tk installation to
build (this may be addressed with companion modules later).

At a technical level, Tcl::Tk wasn't all that spectacular
because it stayed 100% with the string-based interfaces that
Tcl has had for over a decade.  Only in the last couple of
weeks has Tcl::Tk been transformed with a pure SV <> Tcl_Obj
bridge.  In an app we test on locally (a few thousand lines
of code just for the app), we have seen 15% lower (better)
memory usage and snappier performance than the original
Perl/Tk version.

In addition to that, by alleviating the need to maintain the
specialized port of Tk for Perl (where Tcl is partially
ripped out), we are able to fully leverage platform
portability better.  Vadim uses this on Win/CE, and you
could also use this on OS X with Tcl/Tk's native Aqua port.
Feature level portability also must be noted.  The app we had
used Tk->fileevent on unix - but that's never been ported to
Windows for Perl/Tk, although Tcl has had fileevents on
Windows for *7* years.  Using Tcl::Tk we were able to
abstract this easily using the Tcl fileevent in a way that a
Perl programmer can still find friendly.

All this new development is very recent though.  The point
isn't to bury Perl/Tk, as Nick has done an excellent job
maintaining that over the years.  The point is to provide an
architectural replacement to make it easier to maintain in
the years to come.  Perl/Tk compatability in Tcl::Tk has a
lot until it's near complete.  If you want to build UIs from
scratch though, it's all there ready to use.

Regards,

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

Re: [tcltk-perl] Tcl-0.76 CPAN release

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

Vadim Konovalov wrote:

> However there is another problem: for some reason invoking
>   $widget->grid(-column=>1)
> results in transformation of 1 to 1.0 and grid packer gives an error.
> 
> Stringifying that "1" helps in this, but problem persists.

This will be due to checking SvNOK before SvIOK in TclObjFromSv.
However ... that should work correctly regardless, as grid should
be able to request the int from a Tcl_DoubleObj.  I will have to
look into this further.

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

Re: [tcltk-perl] Tcl-0.76 CPAN release

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

> > Do another 'Tcl' CPAN release with small addition right now? Version
0.77?
> > (will match with Tcl::Tk version BTW)
>
> Just add it in.  We aren't at a shortage of numbers ;).

I noticed a typo in Tcl-Tk-0.77 after releasing to CPAN, now corrected in
CVS.
I suppose typo is not critical, so no need to hurry doing next release.

Best regards,
Vadim.

Re: [tcltk-perl] Tcl-0.76 CPAN release

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

Vadim Konovalov wrote:
> However, when doing Tcl::Tk changes, I realised that I forgot to include a
> wrapper function "wcall" to Tcl.pm, which is needed for t/Optionmenu.t
	...
> Do another 'Tcl' CPAN release with small addition right now? Version 0.77?
> (will match with Tcl::Tk version BTW)

Just add it in.  We aren't at a shortage of numbers ;).

Jeff

Re: [tcltk-perl] Tcl-0.76 CPAN release

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

> false alarm:
>
> $widget->cget('-textvariable') for 'Optionmenu' is implemented as
> Tcl::Tk::MultipleWidget and that call is intercepted differently, right
now
> I will not touch CPAN version of Tcl.

However there is another problem: for some reason invoking
  $widget->grid(-column=>1)
results in transformation of 1 to 1.0 and grid packer gives an error.

Stringifying that "1" helps in this, but problem persists.

I made another release right now, and add test for this case later.

Best regards,
Vadim.

Re: [tcltk-perl] Tcl-0.76 CPAN release

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

> > Yes.  There is no reason to not update a CPAN release right away if
> > you discover there is something wrong about it.
>
> Ok, thanks.

false alarm:

$widget->cget('-textvariable') for 'Optionmenu' is implemented as
Tcl::Tk::MultipleWidget and that call is intercepted differently, right now
I will not touch CPAN version of Tcl.

Sorry for bothering.

Best regards,
Vadim.

Re: [tcltk-perl] Tcl-0.76 CPAN release

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

> Yes.  There is no reason to not update a CPAN release right away if
> you discover there is something wrong about it.

Ok, thanks.

BTW I'm doing rather deep changes into Tk.pm:
 - all widgets (Baloon, Menu, ...) will live in their own package, just like
Label, Button, Frame.
 - special_widget_abilities replaced just to creating subroutines in said
widget's packages
 - remove %scrolls hash away.
Probably code will be less in size and more consistent.

Best regards,
Vadim.

Re: [tcltk-perl] Tcl-0.76 CPAN release

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

"Vadim Konovalov" <va...@ar...> writes:

> Dear all!
> 
> I did Tcl-0.76 CPAN release (see below) and I am going to do Tcl-Tk-0.77
> release.
> 
> However, when doing Tcl::Tk changes, I realised that I forgot to include a
> wrapper function "wcall" to Tcl.pm, which is needed for t/Optionmenu.t
> 
> wcall is wrapper for "call" that tries to find its result in %anon-hash
> 
> What is your wise advice in this situation?
> 
> Do another 'Tcl' CPAN release with small addition right now? Version 0.77?
> (will match with Tcl::Tk version BTW)

Yes.  There is no reason to not update a CPAN release right away if
you discover there is something wrong about it.

--Gisle

[tcltk-perl] Tcl-0.76 CPAN release

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

Dear all!

I did Tcl-0.76 CPAN release (see below) and I am going to do Tcl-Tk-0.77
release.

However, when doing Tcl::Tk changes, I realised that I forgot to include a
wrapper function "wcall" to Tcl.pm, which is needed for t/Optionmenu.t

wcall is wrapper for "call" that tries to find its result in %anon-hash

What is your wise advice in this situation?

Do another 'Tcl' CPAN release with small addition right now? Version 0.77?
(will match with Tcl::Tk version BTW)

Comment out t/Optionmenu.t in Tcl-Tk and wait for robust implementation via
special Tcl object wrapper for SV, as Jeff mentioned?

Best regards,
Vadim.



=======================
The uploaded file

    Tcl-0.76.tar.gz

has entered CPAN as

  file: $CPAN/authors/id/V/VK/VKON/Tcl-0.76.tar.gz
  size: 20418 bytes
   md5: 01438df55b65f5ec2075548421311b1d

No action is required on your part
Request entered by: VKON (Vadim Konovalov)
Request entered on: Sat, 17 Apr 2004 07:03:21 GMT
Request completed:  Sat, 17 Apr 2004 07:03:50 GMT

Thanks,
--
paused, v460

Re: [tcltk-perl] t/info.t on Win32

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

Vadim Konovalov wrote:
> Do you mind if I'll insert mine, because it does not  rely on $^O  so will
> probably pass cleanly on other weird file systems?

Sounds fine to me.

[tcltk-perl] t/info.t on Win32

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

Dear Jeff,

I've noticed you made t/info.t to pass on Win32.

However I did it too, but from different side:

--- D:\Personal\cvsroot\Tcl\t\info.t Thu Apr 15 15:01:07 2004
+++ D:\Personal\perl-CPAN\Tcl\t\info.t Sat Apr 17 00:44:19 2004
@@ -7,11 +7,12 @@

 use Tcl;
 use Sys::Hostname qw(hostname);
+use File::Spec::Functions;

 my $tcl = Tcl->new;

 ok($tcl);
-ok($tcl->Eval("info nameofexecutable"), $^X);
+ok(canonpath($tcl->Eval("info nameofexecutable")), canonpath($^X));
 ok($tcl->Eval("info hostname"), hostname);

 my $tclversion = $tcl->Eval("info tclversion");


=====
Do you mind if I'll insert mine, because it does not  rely on $^O  so will
probably pass cleanly on other weird file systems?

Best regards,
Vadim.

Re: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

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

.....
> more consistent with same file from Tcl::Tk (now commited to CVS), and in
> case any of you want to be mentioned slightly, please do corrections.
Should

I meant to say "... slightly *differently* "

please excuse me.

Vadim.

Re: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

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

> > > If no one mind, I'll release both modules with version 0.77. (or is it
> > > reasonable to make version 0.80 due to many changes and improvements
> > > that were done?)
> >
> > I would not jump the number, but it is all up to you.
>
> Sync'ing to the same number is good, but I'm ambivalent about
> jumping the number.

okay, I'll use 0.76 then.

Besides, in addition to what I already said, I changed README file to be
more consistent with same file from Tcl::Tk (now commited to CVS), and in
case any of you want to be mentioned slightly, please do corrections. Should
I add Jan Dubois there as well?

Should we start managing "AUTHORS" file, like in Perl?

If there are objections/corrections, please speak.

Best regards,
Vadim.

Re: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

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

> > We are all in agreement - my perl fu is just not up to the
> > task of doing this quickly.  I was thinking that Tcl::Tk and
> > Tcl::pTk should be separate modules, instead of the odd (to me)
> > use Tcl::Tk q(:perlTk);
> > that is there now.

Actually 'use Tcl::Tk q(:perlTk);' needed only to export MainWindow,
MainLoop functions and few other, and nothing more. Most perlTk syntax is
available even without that qw(:perlTk)

Currently you still can write using "perlTk syntax":

use Tcl::Tk;
$mw = Tcl::Tk::MainWindow;
$mw->Button(-text=>'test',-command=>sub{print 'test'})->pack;
Tcl::Tk::MainLoop;


Probably things should be cleaned here as well...

>
> A separate module is cleaner.  I would actually prefer that, but it is
> certainly an API change.  If we then end up with two ways of doing
> this because we need to stay compatible I rather just keep as it is.

In case we'll move out perlTk compatibility to separate module, what will
stay in Tcl::Tk? Only few very old subroutines like "label", "toplevel" and
so on?

I think in case perlTk compatibility code will be big enough, we can arrange
to have it in nearby file and load it only when needed.

May be instead of doing special compatiiblity layer for perlTk, may be it
could be reasonable to just use perlTk syntax as main way of doing GUI in
perl? Many people just used to using that syntax from perl, and there are
books about it.

BTW (unrelated issue) if a line in Tk.pm "*{Tk::Exists} =
\&Tcl::Tk::Exists;" is commented out, it is possible to debug Tcl::Tk code
ising "ptkdb" debugger, which uses perlTk.


Best regards,
Vadim.

Re: [tcltk-perl] Why is Tcl a subclass of Tck::Tk?

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

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

> We are all in agreement - my perl fu is just not up to the
> task of doing this quickly.  I was thinking that Tcl::Tk and
> Tcl::pTk should be separate modules, instead of the odd (to me)
> 	use Tcl::Tk q(:perlTk);
> that is there now.

A separate module is cleaner.  I would actually prefer that, but it is
certainly an API change.  If we then end up with two ways of doing
this because we need to stay compatible I rather just keep as it is.

--Gisle