Re: status of fileevent support? (for use with Tcl::pTk)

(Continuing discussion from https://github.com/gisle/tcl.pm/issues/14 here per Vadim's suggestion) > chrstphrchvz commented Jul 11, 2018, 3:06 > PM CDT: >> I came across an issue using fileevent from Tcl::pTk on

Git repository for Tcl::pTk

To make the latest source code slightly more accessible, and able to accept patches (pull requests) more easily, I have converted the SVN repository for Tcl::pTk on SourceForge (https://sourceforge.net/p/perl-tcl-ptk/code/) to a Git repository, and have published it to GitHub:

Re: Tcl::pTk overwrite About [macOS]

> On Aug 13, 2018, at 1:22 PM, welle Ozean via tcltk wrote: > > Hello, > > I have a Tk application for macOS written with Tcl::pTk and packed as a > normal macOS bundle. In the macOS menu, under the name of the application > bundle there is a menu item called "About + Name of application".

Re: Custom Widgets

to then cover any cases not covered by Tcl::Tk to allow running existing Perl/Tk programs. There's also this document with a few sections on the differences between Tcl/Tk and Perl/Tk: http://phaseit.net/claird/comp.lang.perl.tk/ptkFAQ.html Hope this helps. Christopher

partial photo/image tests without Img extension?

I notice that both Tcl::Tk and Tcl::pTk have some tests that currently require the Img extension to handle image formats not included in Tcl/Tk. Would it be desirable to still test the formats that are available (gif; png on Tk 8.6), or is the test more about exercising the capabilities in Img?

Error running Makefile.PL on Windows

I have a machine with Windows 10 64-bit 1803, ActivePerl* 5.24.3, and ActiveTcl 8.6.7. *(Uses dmake and doesn't have gnu make. I'm not constrained to ActivePerl; I just didn't know about Strawberry until recently.) I tried installing Tcl.pm 1.25 from cpanm as well as running the latest

Re: Error running Makefile.PL on Windows

On 8/20/2018 2:36 PM, Konovalov, Vadim wrote: I have a machine with Windows 10 64-bit 1803, ActivePerl* 5.24.3, and ActiveTcl 8.6.7. *(Uses dmake and doesn't have gnu make. I'm not constrained to ActivePerl; I just didn't know about Strawberry until recently.) If you think that "dmake" is

Escaping $tclsh in Makefile.PL

In the Makefile.PL's for Tcl.pm, Tcl::Tk, and Tcl::pTk, the path to tclsh should probably be escaped somehow. That way, any characters like spaces get passed properly to the shell. I don't know what the best portable way to do this would be, nor whether surrounding it with double quotes (i.e.

Re: Escaping $tclsh in Makefile.PL

On 8/22/2018 6:21 AM, Konovalov, Vadim wrote: I wonder if quotemeta enough?? I don't think that will work on Windows, because it escapes "too much" as it were. But double quotes might be enough: it will work with e.g. "C:\New folder\..\ActiveTcl\bin\tclsh.exe" but not

Separate lists for user and dev discussion; centralized forum; watching for questions?

(See discussion on RT #125878: https://rt.cpan.org/Ticket/Display.html?id=125878 ) There’s been quite a bit of dev-related traffic on this list recently, although the total volume is still low (only a dozen or so threads from past couple years). Would it be possible/ideal to separate user-

Tcl::Tk for MacPorts

Alongside existing ports in MacPorts for Tcl.pm, Tkx, and Tcl::pTk, I have added the a port for Tcl::Tk, p5-tcl-tk. Christopher A. Chavez

Tcl::pTk: new co-maintainer, release 0.93, MacPorts

Hi everyone, I've recently been added as a co-maintainer to Tcl::pTk. Thanks to John Cerney for helping me get started. I'm particularly interested in its use with macOS aqua, since it allows running Perl/Tk programs with native aqua UI and without needing XQuartz. I released Tcl::pTk 0.93

Re: Drop support for Tcl/Tk 8.4?

> On Mar 27, 2019, at 3:29 AM, Christopher Chavez wrote: > > I am proposing to drop support for Tcl/Tk 8.4 from Tcl::pTk. Vadim, do either of Tcl.pm and Tcl::Tk intend to continue supporting Tcl/Tk < 8.5 (if they currently do)? Christopher A. Chavez

Re: Drop support for Tcl/Tk 8.4?

On 3/27/2019 4:25 AM, Konovalov, Vadim wrote: >> Vadim, do either of Tcl.pm and Tcl::Tk intend to continue >> supporting Tcl/Tk < 8.5 (if they currently do)? > > They currently do support 8.4 and I am planning to continue support; > Even 8.0 I supported > > Any signs that they don't? Not to my

Drop support for Tcl/Tk 8.4?

Hi all, I am proposing to drop support for Tcl/Tk 8.4 from Tcl::pTk. This is mainly because: 1. the developers of Tcl/Tk have no longer supported 8.4 for some time, and have encouraged anyone using it to upgrade; 2. many binary Tcl/Tk distributions and OS package managers no longer provide

Re: Buttons with icons but without boxes on macOS and Tcl::pTk

he 'aqua' theme. The syntax for both approaches seems already supported in Tcl::pTk. For the first approach, use $mw->ttkButton(-style => 'Toolbutton', …). For the second approach, use $mw->Button(-relief => 'flat', …). Hope this helps Christopher Chavez

Tcl::pTk release 0.95; Help wanted for known issues

Hi everyone, I have uploaded Tcl::pTk 0.95. In addition to the notable changes below, it is mainly an accumulation of minor or non-functional changes. Many test failures have been addressed, either by fixing bugs (usually in the tests themselves) or skipping/marking as TODO any tests with

Re: [macOS] Tcl::pTk Drag

(Trying to send this to the list again for reference and to see if I can send emails now. It didn’t go through the first time because GMX had been blocked by perl.org ) > On Sep 21, 2018, at 6:01 AM, welle Ozean via tcltk > wrote: > > Using Tcl::pTk I

Likely Tcl.pm issue on PerlMonks

Just want to share a recent question I found on PerlMonks, in case anyone else wants to take a look or can help: https://www.perlmonks.org/?node_id=1233609 The user was initially trying to get Tkx working with DWIM Perl + ActiveTcl but the error looks like it might be coming from Tcl.pm —

Tcl::pTk release 1.00

Hi all, I have released Tcl::pTk 1.00. One of the main changes is that I have attempted a two-line fix for RT #125049 and #129505 to make menu entries legible on macOS Aqua when the dark menu bar or dark mode is enabled. This change also affects the appearance of derived widgets so that they

Re: RE: High DPI on Windows with Tk

On 6/23/19 at 2:07 AM, Konovalov, Vadim wrote: > > > if ($^O eq 'MSWin32') { > > >use Win32::API; > > Here should be 'require', not 'use' Thanks for catching that, I have updated my post.

Tcl::pTk release 1.01

On 6/18/19 at 10:08 PM, Christopher Chavez wrote: > Hi all, > > I have released Tcl::pTk 1.00. > > > One of the main changes is that I have attempted a two-line fix for RT > #125049 and #129505 to make menu entries legible on macOS Aqua when the > dark menu bar

High DPI on Windows with Tk

Hi everyone, I wanted to share a way for using high-DPI appearance on Windows that I found, in case anyone was interested. I have posted it to https://www.perlmonks.org/?node_id=11101747 Before calling MainWindow->new in Tk, use Win32::API to invoke SetProcessDPIAware(): if ($^O eq

Re: trouble installing Tkx

On 11/20/2019 11:25 AM, Dave Howorth wrote: There's a bug #115662 for Tkx on rt.cpan.org that was opened three years ago with no response. I appended my log to it yesterday, since I seem to be encountering the same problem with newer software (I'm on openSUSE Leap 15.0)

Re: Call perl subroutine from $int->Eval

Sent: Thursday, December 05, 2019 at 3:31 PM From: "welle ozean via tcltk" To: tcltk@perl.org Subject: Call perl subroutine from $int->Eval > Is there a way to call a Perl subroutine from within the $int->Eval? Yes, see https://metacpan.org/pod/Tcl#Accessing-Perl-from-within-Tcl Tcl.pm

Re: Call perl subroutine from $int->Eval

Sent: Friday, December 06, 2019 at 11:30 AM From: "welle ozean" To: "Christopher Chavez" Subject: Re: Call perl subroutine from $int->Eval > Thank you Christopher, > this is very promising! But, I have no idea how to use it. Let's say I have > in my Perl cod

Re: trouble installing Tkx

On 11/23/2019 5:04 AM, Dave Howorth wrote: > Many thanks. I don't suppose there's a reason your pull request > hasn't been accepted yet. The pull request belongs to someone else (Maximilian Lika). Tkx has been dormant for several years, although it still works well with newer upstream Tcl/Tk

Re: Possible bug in Tcl.pm exposed by Tktable?

On 3/16/2020 3:48 AM, Christopher Chavez wrote: The addresses involved are inside allocations from Tcl's thread block cache, which I'm guessing could be heavily reused over the life of a Tcl program (to minimize direct calls to malloc()). I'll ask Tcl developers, but is anyone here aware

Re: Possible bug in Tcl.pm exposed by Tktable?

On 3/16/2020 4:09 AM, Christopher Chavez wrote: That page mentioned the Tcl exit command, which I've never used from Perl. Adding it completely prevents the error:     use Tcl;     my $i = new Tcl;     $i->Init;     $i->Eval(<<'EOS');     package require Tk     package req

Re: Possible bug in Tcl.pm exposed by Tktable?

On 3/7/2020 10:01 PM, Christopher Chavez wrote: ==17734==  Address 0x52012a0 is 8,400 bytes inside a block of size 16,384 alloc'd ==17734==    at 0x483577F: malloc (vg_replace_malloc.c:299) ==17734==    by 0x5550DFE: GetBlocks (tclThreadAlloc.c:1044) ==17734==    by 0x5550549: TclpAlloc

Re: Possible bug in Tcl.pm exposed by Tktable?

On 4/7/2020 3:05 AM, Konovalov, Vadim wrote: As a workaround, you can define this environment variable in Perl, then error goes away: vad@bonita:~$ perl -MTcl -we '$ENV{FOO}="x";my $i=new Tcl;$i->Eval("set env(FOO) bar");print qq/ok\n/' ok I have not yet given this a try, but does this mean

Re: Possible bug in Tcl.pm exposed by Tktable?

On 3/25/2020 11:29 PM, S.J. Luo wrote: Hi, After further tracing around the sources, I think I've figure out the root cause of the fault: Tcl interpreter (not Tcl.so, which is compiled from Tcl.xs) has changed global environment variable of the process while Perl is not aware of it. In more

Re: Possible bug in Tcl.pm exposed by Tktable?

On 4/1/2020 7:19 AM, Konovalov, Vadim wrote: A Tcl::pTk user opened a ticket observing this issue in the test suite: https://rt.cpan.org/Ticket/Display.html?id=132278 Can you open the ticket on Tcl.pm, given that we see that it is more relevant here? I have moved the existing ticket to keep

Possible bug in Tcl.pm exposed by Tktable?

Here's an issue I've known about for several months but hadn't reported. I'm curious if there are any ideas here for debugging or what the cause might be (if obviously in Tcl.pm), or if I should go ahead and report it to Debian package maintainers. Christopher A. Chavez

Re: Possible bug in Tcl.pm exposed by Tktable?

On 3/16/2020 4:09 AM, Christopher Chavez wrote: To partially answer my own question: there are some compile-time techniques to try like -DPURIFY https://wiki.tcl-lang.org/page/How+to+debug+memory+faults+in+Tcl+and+extensions After build from upstream sources (Tcl/Tk core-8-6-branch and TkTable

Check Tcl/Tk using Tcl.pm from Makefile.PL?

I often have multiple Tcl/Tk installations on a system for testing purposes, and quite a few times I have accidentally specified --tclsh for the wrong Tcl/Tk installation to Tcl::pTk, rather than whichever one Tcl.pm is currently using. I wonder if this could be prevented: when installing Tcl.pm

Re: Trying to use Tk 8.6

From: "Bill Costa" > On MacOS 10.13.6 I have Perl 5.28 installed in /opt/local/ using > MacPorts. This works well and no problems installing modules using > `cpanm`. I installed ActiveState's v8.6 of Tcl which is saved to > `/Library/Frameworks/Tcl.framework/Versions/8.6` and then installed > Tkx.

Tkx 1.10, new maintainer

Howdy, I am now the maintainer of Tkx; it was put up for adoption a few months ago [1]. Thanks to PAUSE admins for their help. I published Tkx 1.10, which will allow installation despite the known test failure [2]. I have set the repository and bugtracker to my fork [3]. [1]

Re: help Keyboard and Tk

> All key good, but I have a problem with the key f10. > > I can see F10 in the consol, no problem. > But in windows 10, f10 open the menu. For a very long time, it has been conventional behavior for many programs on Windows (not just Tk) for F10 to “activate” the menu. Tk having this binding