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

RE: [tcltk-perl] packaging Tcl::Tk and Tcl/Tk files within Perl installation

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

Jan Dubois wrote:
> On Sun, 14 Nov 2004, Konovalov, Vadim wrote:
> > Your code mostly refers to __hpux, which I am not familiar.
> >
> > Did I understood correctly that "sl" in "libtcl8.4.sl" stands for 
> > "starpack library"?
> 
> No, it stands for "shared library".  It is the HP-UX 
> equivalent of a .so or .dll.

To follow up on this, the code for handling the starpack as
dll has nothing to do with the recent HP-UX support commits
(those are purely for HP-UX).  The code has been in the CVS
for a while now.  If you compile with -DUSE_TCL_STUBS (which
should probably be the default), then when it loads the Tcl
library, we make 2 extra sym checks for TclKit_AppInit, which
would replace Tcl_Init on the interp, and TclKit_SetKitPath.
These are used to indicate the shared library is the starkit
source, and all is contained within it.

Jeff

RE: [tcltk-perl] packaging Tcl::Tk and Tcl/Tk files within Perl installation

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

On Sun, 14 Nov 2004, Konovalov, Vadim wrote:
> Your code mostly refers to __hpux, which I am not familiar.
>
> Did I understood correctly that "sl" in "libtcl8.4.sl" stands for
> "starpack library"?

No, it stands for "shared library".  It is the HP-UX equivalent of
a .so or .dll.

> Why only __hpux then, why not any linux system also involved?

Older versions of HP-UX don't have dlopen() support and the emulation of
dlopen() inside DynaLoader is not easily accessible from XS code.

Cheers,
-Jan

RE: [tcltk-perl] packaging Tcl::Tk and Tcl/Tk files within Perl installation

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

......

> >  - after Tcl, Tk, trf, memchan, vfs built, they could be linked with
> >    Tcl.xs we get single Tcl.dll, (otherwise Perl's Tcl.dll calls
> >    Tcl/Tk's tcl84.dll and tk84.dll)
> >  - "tcl-scripts.zip" created during build
> >  - all related *.tcl scripts being used from 
> "tcl-scripts.zip" archive
> >    directly using Tcl's vfs::zip vrtual FS.
> 
> This is interesting.  We (ActiveState) have done something
> similar for our own purposes.  We did this by basing the

I did not finalized my initial idea at previous weekend, unfortunately, as I
was stuck in helping friends with their hardware problems.
However I am planning to finalize it really soon.
I will name modules as Tcl-packaged and Tcl-zpackaged, if no better name
will be suggested ot come into my mind.

It would be highly beneficial for fully feature-enabled module to be placed
in 4-5 library files and zip-archived file with scripts...

> work on starpacks as dlls.  You will see some of the code
> that I commited to Tcl.xs to support this.

That's very good, and few questions though.

Your code mostly refers to __hpux, which I am not familiar.

Did I understood correctly that "sl" in  "libtcl8.4.sl" stands for "starpack
library"?

Why only __hpux then, why not any linux system also involved?

Best regards,
Vadim.

RE: [tcltk-perl] packaging Tcl::Tk and Tcl/Tk files within Perl installation

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

Vadim wrote:
> I developed small Perl script that aims in Tcl/Tk build 
> process for creation of Tcl/Tk being used from Perl's Tcl::Tk 
> modules only.

> However following currently works:
> 
>  - after Tcl, Tk, trf, memchan, vfs built, they could be linked with
>    Tcl.xs we get single Tcl.dll, (otherwise Perl's Tcl.dll calls
>    Tcl/Tk's tcl84.dll and tk84.dll)
>  - "tcl-scripts.zip" created during build
>  - all related *.tcl scripts being used from "tcl-scripts.zip" archive
>    directly using Tcl's vfs::zip vrtual FS.

This is interesting.  We (ActiveState) have done something
similar for our own purposes.  We did this by basing the
work on starpacks as dlls.  You will see some of the code
that I commited to Tcl.xs to support this.

The Tcl-side of that is proprietary, as it is a part of the
Tcl Dev Kit, but we posted all the basic coding bits for it
to the starkit mailing list during development for others
to consider.  We will likely use this same approach for the
Tcl web browser plugin.

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

[tcltk-perl] packaging Tcl::Tk and Tcl/Tk files within Perl installation

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

I developed small Perl script that aims in Tcl/Tk build process for
creation of Tcl/Tk being used from Perl's Tcl::Tk modules only.

All steps are very very first preliminary and only work on Win32.

However following currently works:

 - after Tcl, Tk, trf, memchan, vfs built, they could be linked with
   Tcl.xs we get single Tcl.dll, (otherwise Perl's Tcl.dll calls
   Tcl/Tk's tcl84.dll and tk84.dll)
 - "tcl-scripts.zip" created during build
 - all related *.tcl scripts being used from "tcl-scripts.zip" archive
   directly using Tcl's vfs::zip vrtual FS.

Following are not currently working but expect those really soon
(after weekend)

 - tk.res not linked with Tcl.dll but it should
 - process requires Compress::Zlib static lib behind the scenes
 - non-Win32
 - Tcl/Tk versions other than 8.4.7


Alternatively, it is quite possible to create distribution without any
compressing/zip tricks, so using all Tcl/Tk without trf, memchan, vfs.
This will be easier and not harder.

When all will be settled, I suppose creating CPAN distribution with
names like

 TclTk-zpackaged   - Tcl/Tk+Tix+some others, trf, memchan, vfs and Tcl
                    scripts zipped
 TclTk-packaged    - same but no zipping

I like first one much better than second.

I placed my "build area" with mentioned script at
  www.vkonovalov.ru/tcltk-misc
File tcltk-packaged.zip contains current build tree.

All things are not settled, and after a week or two things will
stabilize much more, so people who do not have enough time to look
into broken scripts should wait a bit. On the contrary, those who want
help things to grow in a sane way, should speak early.


-- 
Best regards,
 Vadim

[tcltk-perl] RE: [Activetcl] why simple Tcl script have very different executi on time...

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

> > Give following simple script:
> > 
> > for {set i 0} {$i < 1000000} {incr i} {}
> > 
> > If invoked from file: tclsh a.tcl
> > finishes execution in about 6 seconds on my PC.
> 
> > When I input same string from within "tclsh" shell it 
> finishes in 3 seconds.
> 
> In general, Tcl does not compile toplevel code, since it is
> expected this code runs once.  Not great for large loops.  If
> you have a large loop, put it in a proc if you want it to run
> fast:
> 
> proc test {} {
>      for {set i 0} {$i < 1000000} {incr i} {}
> }
> test

Thanks, that's really it.

Initially my test was:

perl -MTcl -we "$t0=Win32::GetTickCount();$i=new Tcl;$i->Eval('for {set i 0}
{$i < 1000000} {incr i} {}');print Win32::GetTickCount()-$t0;"
6119

Now it is:
perl -MTcl -we "$t0=Win32::GetTickCount();$i=new Tcl;$i->Eval('proc test {}
{for {set i 0} {$i < 1000000} {incr i} {}};test');print
Win32::GetTickCount()-$t0;"
1312

Will use this knowledge, as it makes sence to me.

Best regards,
Vadim.

[tcltk-perl] Re: [Activetcl] why simple Tcl script have very different execution time...

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

Konovalov, Vadim wrote:
> why simple Tcl script have very different execution time when invoked from file
> and from tclsh?
> 
> Give following simple script:
> 
> for {set i 0} {$i < 1000000} {incr i} {}
> 
> If invoked from file: tclsh a.tcl
> finishes execution in about 6 seconds on my PC.

> When I input same string from within "tclsh" shell it finishes in 3 seconds.

In general, Tcl does not compile toplevel code, since it is
expected this code runs once.  Not great for large loops.  If
you have a large loop, put it in a proc if you want it to run
fast:

proc test {} {
     for {set i 0} {$i < 1000000} {incr i} {}
}
test

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

RE: [tcltk-perl] Re: [Activetcl] why simple Tcl script have very different execution time...

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

> I noticed this as well.  What I came to recognize is that 
> when executing 
> a script, you must wait for the scripting engine to load, 
> then compile, 
> then execute your script.
> When you are already inside an interpreter allot of that time 
> is cut down.

Suppose loading of external moduels takes some amount of time, but how could
it be explained that after changing 1000000 with 10000000 in that script
there is 35 seconds of deifference in execution time?? Time for loading
modules should be added to total execution time, not multiplied.

I would rather suspect some tricks with pre-compilations and different
number of memory allocations, but I am no knowledgable here, in Tcl source
code...


> You may wish to try writing a script that launches and loads 
> all of the 
> required extensions, then sources your application files.
> 
> You will notice a speed increase even on your one liner.

interesting to note, I invoked tclsh, and then typing
  source a.tcl
and
  for {set i 0} {$i < 1000000} {incr i} {}
differs in execution time also...



Thanks for your ideas on the matter!

> 
> Konovalov, Vadim wrote:
> 
> >why simple Tcl script have very different execution time 
> when invoked from
> >file and from tclsh?
> >
> >Give following simple script:
> >
> >for {set i 0} {$i < 1000000} {incr i} {}
> >
> >If invoked from file:
> >   tclsh a.tcl
> >
> >finishes execution in about 6 seconds on my PC.
> >
> >When I input same string from within "tclsh" shell it 
> finishes in 3 seconds.
> >
> >Same behaviour (but larger execution time) when I replace 
> 1000000 with
> >10000000 --- 60 and 25 seconds appropriately
> >
> >How this could be explained? Better yet, how can I speed up 
> worse case to be
> >in line with best one?
> >
> >I used ActiveTCL version 8.4.6
> >
> >Thanks in advance.
> >
> >Vadim.
> >_______________________________________________
> >ActiveTcl mailing list
> >Act...@li...
> >To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
> >
> >  
> >
> 
> 
> 
> -------------------------------------------------------
> This SF.net email is sponsored by: IT Product Guide on 
> ITManagersJournal
> Use IT products in your business? Tell us what you think of 
> them. Give us
> Your Opinions, Get Free ThinkGeek Gift Certificates! Click to 
> find out more
> http://productguide.itmanagersjournal.com/guidepromo.tmpl
> _______________________________________________
> Tcltk-perl mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcltk-perl
> 

[tcltk-perl] Re: [Activetcl] why simple Tcl script have very different execution time...

[Visnet <vi...@tw...>]

I noticed this as well.  What I came to recognize is that when executing 
a script, you must wait for the scripting engine to load, then compile, 
then execute your script.
When you are already inside an interpreter allot of that time is cut down.

With larger applications, or issues that take a significant length of 
time.  This becomes transparent.

My workaround is rather simple.

I create a procedure inside all of my applications that sources another 
script.  In this way I can simply source other scripts and they behave 
in a much faster manner.

You may wish to try writing a script that launches and loads all of the 
required extensions, then sources your application files.

You will notice a speed increase even on your one liner.

Konovalov, Vadim wrote:

>why simple Tcl script have very different execution time when invoked from
>file and from tclsh?
>
>Give following simple script:
>
>for {set i 0} {$i < 1000000} {incr i} {}
>
>If invoked from file:
>   tclsh a.tcl
>
>finishes execution in about 6 seconds on my PC.
>
>When I input same string from within "tclsh" shell it finishes in 3 seconds.
>
>Same behaviour (but larger execution time) when I replace 1000000 with
>10000000 --- 60 and 25 seconds appropriately
>
>How this could be explained? Better yet, how can I speed up worse case to be
>in line with best one?
>
>I used ActiveTCL version 8.4.6
>
>Thanks in advance.
>
>Vadim.
>_______________________________________________
>ActiveTcl mailing list
>Act...@li...
>To unsubscribe: http://listserv.ActiveState.com/mailman/mysubs
>
>  
>

[tcltk-perl] why simple Tcl script have very different execution time...

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

why simple Tcl script have very different execution time when invoked from
file and from tclsh?

Give following simple script:

for {set i 0} {$i < 1000000} {incr i} {}

If invoked from file:
   tclsh a.tcl

finishes execution in about 6 seconds on my PC.

When I input same string from within "tclsh" shell it finishes in 3 seconds.

Same behaviour (but larger execution time) when I replace 1000000 with
10000000 --- 60 and 25 seconds appropriately

How this could be explained? Better yet, how can I speed up worse case to be
in line with best one?

I used ActiveTCL version 8.4.6

Thanks in advance.

Vadim.

Re[2]: [tcltk-perl] Tcl::Tk and Tcl/Tk files within Perl installation

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

>> It was easy to arrange so that Tcl/Tk gets all scripts from zipped
>> archive "tcltk.zip"
>>
>> So I ended with about 3 or 4 files for entire Perl + Tk. Adding Tix
>> makes only one file more (tix8184.dll) and tcltk.zip becomes a bit
>> larger. All pure-Tcl extension go to that "tcltk.zip"

JD> All of the above sounds pretty cool.  This will make it a lot easier
JD> for people to use Tcl::Tk without having to install a whole Tcl
JD> installation.

Yes, I also think so.

So I plan to reach a final goal in my spare time within few weeks.


>> I did it further: after few touches in Perl's makefile it is possible
>> to embed extension into perl.dll (it was possible earlier, and I
>> mostly restored and extended such a possibility)
>>
>> So I have 2Mbyte perl58.dll that contains Perl itself, Tcl/Tk, and
>> some Perl extensions (Compress::Zlib for example).

JD> I don't understand the value of this later part.  Why would you want to
JD> do this?  The big advantage of DynaLoader is that you no longer need
JD> to statically link extensions into core Perl (except for DynaLoader
JD> itself, of course).  Am I missing something?

Indeed, mostly modules should be loaded dynamically.
And I will mostly use Tcl::Tk using DynaLoader. 99.5% of the time

There are reasons I did this step:
 - to prove the concept it is able to work, and flexible enough to
   allow different configurations.
 - I was fixing Perl's makefile-s and dynaloader in respect to
   statically building of extensions and decided to do some testing.
 - I was requested to implement some GUI application, and it will
   always start with GUI. So there exist some sence to reduce startup
   time.
   At least it is reasonable to include Compress::Zlib into perl58.dll
   within my distro, because otherwise it always will start from
   loading Zlib.dll, and I will save in startup time a bit.
   
   Still, I am not sure whether my final distribution will have Tcl
   statically built into Perl, because having it separatedly increases
   flexibility in that sence that I can upgrade Tcl/Tk without
   rebuilding Perl each time.

But I do agree that normally Tcl::Tk should be dynamically loaded when
needed, so my extending of Perl's DLL is rather playing.

Best regards,
Vadim.

RE: [tcltk-perl] Tcl::Tk and Tcl/Tk files within Perl installation

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

On Tue, 12 Oct 2004, Konovalov, Vadim wrote:
> While playing with Perl and Tcl::Tk module on Win32, I discovered
> that it is relatively easy to build Tcl.dll (derived from Tcl.xs)
> that contains entire Tcl/Tk binaries. (all my experiments are on
> Win32 for now)
>
> I built tcl and tk statically, and then specified those libraries in
> Makefile.PL, so I got large Tcl.dll and it worked.
>
> It was easy to arrange so that Tcl/Tk gets all scripts from zipped
> archive "tcltk.zip"
>
> So I ended with about 3 or 4 files for entire Perl + Tk. Adding Tix
> makes only one file more (tix8184.dll) and tcltk.zip becomes a bit
> larger. All pure-Tcl extension go to that "tcltk.zip"

All of the above sounds pretty cool.  This will make it a lot easier
for people to use Tcl::Tk without having to install a whole Tcl
installation.

> I did it further: after few touches in Perl's makefile it is possible
> to embed extension into perl.dll (it was possible earlier, and I
> mostly restored and extended such a possibility)
>
> So I have 2Mbyte perl58.dll that contains Perl itself, Tcl/Tk, and
> some Perl extensions (Compress::Zlib for example).

I don't understand the value of this later part.  Why would you want to
do this?  The big advantage of DynaLoader is that you no longer need
to statically link extensions into core Perl (except for DynaLoader
itself, of course).  Am I missing something?

Cheers,
-Jan

[tcltk-perl] Tcl::Tk and Tcl/Tk files within Perl installation

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

While playing with Perl and Tcl::Tk module on Win32, I discovered that it is
relatively easy to build Tcl.dll (derived from Tcl.xs) that contains entire
Tcl/Tk binaries.
(all my experiments are on Win32 for now)

I built tcl and tk statically, and then specified those libraries in
Makefile.PL, so I got large Tcl.dll and it worked.

It was easy to arrange so that Tcl/Tk gets all scripts from zipped archive
"tcltk.zip"

So I ended with about 3 or 4 files for entire Perl + Tk.
Adding Tix makes only one file more (tix8184.dll) and tcltk.zip becomes a
bit larger.
All pure-Tcl extension go to that "tcltk.zip"

I did it further: after few touches in Perl's makefile it is possible to
embed extension into perl.dll
(it was possible earlier, and I mostly restored and extended such a
possibility)

So I have 2Mbyte perl58.dll that contains Perl itself, Tcl/Tk, and some Perl
extensions (Compress::Zlib for example).

I'll perform many cleanup and will describe in manual pages somehow.

Why do I write all this?

1. to let you know it is available. Will share any knowledge on this on
request.

2. it could be reasonable to decide what "official" way of doing things is.
Having only limited set of files in module's distribution is a great plus.

3. Besides Win32, there are many other platforms to do. Although I can do
some minimal testing and development on Linux and FreeBSD, I will need
advices from experts for sure.

Timeline for completing this on Win32 (including description/documentation)
is few weeks or several weeks (as usual).

Best regards,
Vadim.

[tcltk-perl] FW: [MACTCL] loadable TkAqua

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

Just an FYI that Daniel Steffen has Tk now loadable from Tcl
on Aqua (required some thread voodoo).  This also enables
Tcl::Tk on Aqua, with confirmation from the attached email.

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

-----Original Message-----
From: Daniel A. Steffen
Sent: Monday, September 27, 2004 2:51 AM
To: tcl mac; Jim Ingham
Cc: Wout Mertens
Subject: [MACTCL] loadable TkAqua


All,

the follwoing has been on my almost-finished pile for a while, finally  
got around to cleaning it up this weekend:

	http://sourceforge.net/tracker/index.php? 
func=detail&aid=1035348&group_id=12997&atid=312997

this has patches to core-8-4-branch and HEAD that enable [package  
require Tk] for TkAqua.

All platform specific code from tkMacOSXAppInit.c is moved to  
tkMacOSXInit.c and tkMacOSXAppInit.c is removed and replaced by the  
generic unix/tkAppInit.c.

Almost all such startup code was interp specific and is moved into the  
existing initialization code in TkpInit(). The only  
pre-interp-initialization we need to do is setting up the  
Resources/Scripts/AppMain.tcl startup file (if present), this code is  
moved to a new TkMacOSXDefaultStartupScript() which is called from  
Tk_Main() (the only change to generic code).

The main project change is addition of a pkgIndex.tcl script in  
Tk.framework/Resources/Scripts, which enables [package require Tk].

I've also added code to TkpInit() that checks if we are loaded into a  
bundled executable; and if not, attempts to dynamically acquire the  
undocumented CPSEnableForegroundOperation SPI and use it to notify the  
window server that we are now a full GUI application (this will not  
break if that SPI ever disappears or changes its name).
Even though we've previously discussed and rejected using CPS SPI, I've  
lost my scruples on this after talking to the LaunchServices engineers  
at WWDC (who said to go ahead and use the same workaround that JAR  
launcher, SDL, wxPython etc all already use, it's not likely to go away  
at this point and an official solution is not in the pipeline). Just  
google for CPSEnableForegroundOperation to see how widespread use of  
this SPI is... In any case, this code can be disabled via #define if  
desired.
Of course it's still much preferred to use a bundled executable, as you  
cannot get a dock icon, document bindings, a bundle id, etc otherwise,  
also the aete resource for Wish is not available to an unbundled  
executable (i.e. app cannot be targeted via AppleScript)

With all this, [package require Tk] now works from tclsh wrapped as a  
bundled executable, and also unbundled if the above code is enabled.

In particular, this also allows the Tcl::Tk perl module to properly  
load TkAqua:
	http://search.cpan.org/~vkon/Tcl/
	http://search.cpan.org/~vkon/Tcl-Tk/
get release 0.84 which has my changes to build the Tcl module against  
Tcl.framework; and configure the Tcl module with
	perl Makefile.PL --tclconfig  
/Library/Frameworks/Tcl.framework/tclConfig.sh --usestubs  
INSTALLSITEMAN3DIR=/usr/local/man/man3
and the Tcl::Tk module with
	perl Makefile.PL INSTALLSITEMAN3DIR=/usr/local/man/man3
both modules should pass all their 'make test's...

Jim, could you review this for checkin?

Cheers,

Daniel

-- 
** Daniel A. Steffen     **  "And now for something completely
** Dept. of Mathematics  **   different"    Monty Python
** Macquarie University  **  
** NSW 2109 Australia    **  <http://www.maths.mq.edu.au/~steffen/>

[tcltk-perl] which is the best way to provide hook(s) in Tcl::Tk module

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

Salut!

In my Perl applications that use Tcl::Tk I usually do a hack which allows me
to use Tcl/Tk that is distributed with application and is placed somewhere
nearby.

Those 2 hacks are:

1. it is already in CPAN 

    if (defined $::tcl_library) {
	# hack to redefine search path for TCL installation
	$i->SetVar('tcl_library',$::tcl_library);
	print STDERR "tcl_library=$::tcl_library.\n";
    }
....


2. it is only in my appliations and not in CPAN modules
    $i->SUPER::Init();
    if (defined $::tcl_init) {
        $::tcl_init->($i);
	# hack
    }
    $i->need_tk('Tk');


2nd hack allows me to have packed distribution.

My way of doing this thing is not perfect, and I would like to discuss which
aproach should be included into CPAN distribution of bridge module.

I dare to remember that we discussed a necessity to provide such a way, so
to provide for people easier manupulation.
That said, it could be reasonable to discuss a question in details,
otherwise I am in danger to take imperfect decision.

Best regards,
Vadim.

RE: [tcltk-perl] CE .Net 4.2

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

> I have a PDA which has Windows CE .Net 4.2 on it.  It is 
> running on a Xscale processor.  Will the arm binaries for 
> Tcl/Tk, Tcl::Tk, and perl work on this device?

Yes, they should.  That is an upwards compatible combination.

Jeff

[tcltk-perl] CE .Net 4.2

[Paul F. <fa...@ca...>]

I have a PDA which has Windows CE .Net 4.2 on it.  It is running
on a Xscale processor.  Will the arm binaries for Tcl/Tk, Tcl::Tk, and perl
work on this device?

[tcltk-perl] RE: widget demo

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

> In the widget demo widget_lib/bind.pl (Hypertext) a error occurs on
> 
>         @normal = (-background => undef, qw/-relief flat/);
> 
> This will cause errors.  If set -background = 'white'
> no error occurs.  Question is how to set to default background
> of a app?

To say, this works:
perl -MTk -we
"$b=tkinit->Button(-bg=>'blue',-command=>sub{$b->configure(-bg=>'black')})->
pack;MainLoop"

but this causes core dump when I press button (perl585,Tk804):
perl -MTk -we
"$b=tkinit->Button(-bg=>'blue',-command=>sub{$b->configure(-bg=>undef)})->pa
ck;MainLoop"

So I am not surprised it does not work with Tcl::Tk

may be you need to save previous value and restore it instead of using
undef?

Yet I know this could be done with 'option' feature inTk, but I am not sure
about details of it, because I never used it yet.

> Also, how does someone do something like this.
> 
> $ListBox->bind('<1>','selectLine');
> 
> then
> 
> my $text= $ListBox->getSelected();
> 
> $ListBox s a ROText type box.


I do it this way:
$t->tag('bind','rep','<1>'=>sub {
    my $l = $t->tagPrevrange('rep','current');
    my @sel = $t->tag('ranges','sel');
    $t->tag('remove','sel',@sel) if $#sel>-1;
    if (exists $x{$l}) {
      print STDERR "[$x{$l}]\n";
      call_display_parameters($x{$l});
    }
});

$t is text widget

HTH

Best regards,
Vadim.

[tcltk-perl] widget demo

[Paul F. <fa...@ca...>]

In the widget demo widget_lib/bind.pl (Hypertext) a error occurs on

        @normal = (-background => undef, qw/-relief flat/);

This will cause errors.  If set -background = 'white'
no error occurs.  Question is how to set to default background
of a app?

Also, how does someone do something like this.

$ListBox->bind('<1>','selectLine');

then

my $text= $ListBox->getSelected();

$ListBox s a ROText type box.

Re: [tcltk-perl] Package Img

[Paul F. <fa...@ca...>]

On Tue, Sep 07, 2004 at 11:18:56PM -0700, Jeff Hobbs wrote:
> Konovalov, Vadim wrote:
> >>One strange thing on your doodle.pl It works great on
> >>my i386 Linux box which has tcl/tk 8.4.7 but on my CASIO which has
> >>8.4.4 all lines start from the upper left-hand corner.  Any ideas??
> >
> >
> >I saw same behaviour, and I didn't realized why it behaves that way.
> 
> This may be a bug in the %x/%y translation on Win/CE only.
> I haven't confirmed this, but there are some bugs in the
> Win/CE port still where functionality has to be emulated
> because the CE OS doesn't currently support it.

Here's what I did to make it work.  Forgot to post it, Sorry.  I took a flare
and did the same thing Slaven Rezic does in his Tk::Sketch module.
And returned if "return if $x < 0 || $y < 0;" in the doodle_start
and doodle_move functions.  I guess Tk has the same problem?


#!/usr/bin/perl

use Tcl::Tk qw/:perlTk/;
my $mw = MainWindow->new();
my $c = $mw->Canvas(-background => "white")
  ->pack(-fill => 'both', -expand => 1);

our $id;
doodle($c);

MainLoop;

sub doodle {
    my ($w, $color) = @_;
    my $color = "black" unless defined $color;
    Tcl::Tk::bind($w->interp, $w, '<1>',
		  [\&doodle_start, Tcl::Ev('%x', '%y'), $w, $color]);
    Tcl::Tk::bind($w->interp, $w, '<B1-Motion>',
		  [\&doodle_move, Tcl::Ev('%x', '%y'), $w]);
#   bind $w <1>         [list doodle'start %W %x %y $color]
#   bind $w <B1-Motion> {doodle'move %W %x %y}
}

sub doodle_start {
    my ($x, $y, $w, $color) = @_;
return if $x < 0 || $y < 0;
    $id = $w->create('line', $x, $y, $x, $y, -fill => $color);
#   set ::_id [$w create line $x $y $x $y -fill $color]
}

sub doodle_move {
    my ($x, $y, $w) = @_;
return if $x < 0 || $y < 0;
    my @coords = $w->coords($id);
    unshift @coords, $x, $y;
    $w->coords($id, @coords);
#   $w coords $::_id [concat [$w coords $::_id] $x $y]
}

Re: [tcltk-perl] Package Img

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

Konovalov, Vadim wrote:
>>One strange thing on your doodle.pl It works great on
>>my i386 Linux box which has tcl/tk 8.4.7 but on my CASIO which has
>>8.4.4 all lines start from the upper left-hand corner.  Any ideas??
> 
> 
> I saw same behaviour, and I didn't realized why it behaves that way.

This may be a bug in the %x/%y translation on Win/CE only.
I haven't confirmed this, but there are some bugs in the
Win/CE port still where functionality has to be emulated
because the CE OS doesn't currently support it.

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

RE: [tcltk-perl] Package Img

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

> One strange thing on your doodle.pl It works great on
> my i386 Linux box which has tcl/tk 8.4.7 but on my CASIO which has
> 8.4.4 all lines start from the upper left-hand corner.  Any ideas??

I saw same behaviour, and I didn't realized why it behaves that way.

Did you resolved this?

Thanks.

RE: [tcltk-perl] Package Img

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

> What would I need to comment out so it stops complaining 
> about the need
> of "Img"?

exactly that.

I am sorry for delaying next releasing of Tcl::Tk perl module, which will
require 'Img' only when really needed.
Until that, just comment out need_tk('Img') inside Tcl/Tk.pm, there are only
few places.

I'll do CPAN release in nearest couple of days.

Best regards,
Vadim.

Re: [tcltk-perl] Package Img

[Paul F. <fa...@ca...>]

On Tue, Sep 07, 2004 at 01:27:52PM -0700, Jeff Hobbs wrote:
> > Ok, I've solved all my issues save one.  It seems that
> > to save a Canvas need the Photo method.  That is part of 
> > tkimg. Is there somewhere I can get binaries of tkimg for 
> > Wince for both ARM and Mips processors?
> 
> You really don't need the tkimg module, unless you want
> some other format than GIF or PPM.  I don't know of any
> ports to WinCE for Img, and it wouldn't be an easy port.
> It relies on the graphics libraries for the other formats,
> like libtiff, libpng, libjpeg, so you would have to have
> those ported first (which they are, in some cases).

What would I need to comment out so it stops complaining about the need
of "Img"?

RE: [tcltk-perl] Package Img

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

> Ok, I've solved all my issues save one.  It seems that
> to save a Canvas need the Photo method.  That is part of 
> tkimg. Is there somewhere I can get binaries of tkimg for 
> Wince for both ARM and Mips processors?

You really don't need the tkimg module, unless you want
some other format than GIF or PPM.  I don't know of any
ports to WinCE for Img, and it wouldn't be an easy port.
It relies on the graphics libraries for the other formats,
like libtiff, libpng, libjpeg, so you would have to have
those ported first (which they are, in some cases).

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