tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TkPath 0.4.1

[Paul O. <pa...@po...>]

Thanks Marc,

I remember discussions regarding changes in Tk9 MacOS related code,
but do not know the details.

I plan a new release of BAWT after Tcl/Tk 9.0.2 release.
Hopefully a tkpath version available for all platforms can be included.

Paul


Am 30.06.2025 um 16:44 schrieb Marc Culler:
> Tk 9 uses updateLayer instead of drawRect. (!!!!!!!!!!!!!)
>
> That means that the process for getting a working CGContextRef needs to be different.
>
> I will submit a PR.
>
> - Marc
>
>
> On Mon, Jun 30, 2025 at 8:05 AM Paul Obermeier <pa...@po...> wrote:
>
>     Thanks Nicolas for testing and reporting.
>
>     I got the same warnings when compiling on MacOS.
>     I checked the first warning with the suspicious pointer cast,
>     but found out that the corresponding code is not called when running the "Apple" demo.
>     So this warning does not seem to be the primary case, that demos do not run with Tk9.
>
>     Paul
>
>     Am 30.06.2025 um 08:20 schrieb nicolas bats:
>>     Hi Paul, Ashok,
>>
>>     I've compiled tkPath on macOS15 and here's reported warnings:
>>
>>     *./macosx/tkMacOSXPath.c:113:50: **warning: **incompatible pointer types passing 'TkWindow *' (aka 'struct TkWindow *') to parameter of type 'Tk_Window' (aka 'struct Tk_Window_ *') [-Wincompatible-pointer-types]*
>>
>>     113 | Tk_Window contWinPtr = Tk_GetOtherWindow(macWin->toplevel->winPtr);
>>
>>     |*^~~~~~~~~~~~~~~~~~~~~~~~*
>>
>>     *./macosx/tkMacOSXPath.c:244:24: **warning: **'disableFlushWindow' is deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations. [-Wdeprecated-declarations]*
>>
>>     244 | [[view window] disableFlushWindow];
>>
>>     |*^*
>>
>>     */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1010:1: **note: *'disableFlushWindow' has been explicitly marked deprecated here
>>
>>     1010 | - (void)disableFlushWindow API_DEPRECATED("Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations.", macos(10.0,10.14));
>>
>>     | *^*
>>
>>     *./macosx/tkMacOSXPath.c:247:53: **warning: **'graphicsPort' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]*
>>
>>     247 | context->c = (CGContextRef)[currentGraphicsContext graphicsPort];
>>
>>     |*^~~~~~~~~~~~*
>>
>>     |CGContext
>>
>>     */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28: **note: *property 'graphicsPort' is declared deprecated here
>>
>>     107 | @property (readonly) void*graphicsPort NS_RETURNS_INNER_POINTER API_DEPRECATED_WITH_REPLACEMENT("CGContext", macos(10.0,10.14));
>>
>>     |*^*
>>
>>     */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28: **note: *'graphicsPort' has been explicitly marked deprecated here
>>
>>     *./macosx/tkMacOSXPath.c:295:30: **warning: **'enableFlushWindow' is deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations. [-Wdeprecated-declarations]*
>>
>>     295 | [[context->view window] enableFlushWindow];
>>
>>     | *^*
>>
>>     */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1011:1: **note: *'enableFlushWindow' has been explicitly marked deprecated here
>>
>>     1011 | - (void)enableFlushWindow API_DEPRECATED("Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations.", macos(10.0,10.14));
>>
>>     | *^*
>>
>>     4 warnings generated.
>>
>>
>>
>>     should I open a ticket on gitHub?
>>
>>     best regards,
>>
>>     nicolas
>>
>>
>>     Le jeu. 26 juin 2025 à 05:06, apnmbx-public--- via Tcl-Core <tcl...@li...> a écrit :
>>
>>         Thanks Paul. I overlooked checking the demos. Committed a fix and they should be working now. Verified 9.0 and 8.6 with Ubuntu and 9.0 with VC++. Missed a structure field initializer during the merge though I’m not sure why it only impacted 9.0 and not 8.6.
>>
>>         Also, I noticed the TkPathItemType and TkPathCanvas structure no longer match the corresponding types in Tk. I presume that is ok since they are only used internally.
>>
>>         Hope someone will look at macos errors.
>>
>>         /Ashok
>>
>>         *From:*Paul Obermeier <pa...@po...> <mailto:pa...@po...>
>>         *Sent:* Thursday, June 26, 2025 1:22 AM
>>         *To:* tcl...@li...
>>         *Subject:* Re: [TCLCORE] TkPath 0.4.1
>>
>>         Thanks Ashok for caring.
>>
>>         I tested the tcltk-depot version on Windows (gcc), several Linux distros, Raspi and RiscV
>>         using Tcl/Tk 8.6.16 and 9.0.1.
>>         With the exception of MacOS the test suite runs without errors.
>>         On MacOS 15.5 there is 1 test suite error (both using 8.6.16 and 9.0.1), see below.
>>         The demos work fine using 8.6.16, but do not work using 9.0.1.
>>
>>         I created issues for the 2 MacOS problems in case one of the Mac gurus
>>         wants to take a closer look.
>>
>>         Regards,
>>         Paul
>>
>>         Am 25.06.2025 um 17:30 schrieb apnmbx-public--- via Tcl-Core:
>>
>>             https://github.com/tcltk-depot/tkpath now (purportedly) holds the merge of all the tkpath forks, versioned 0.4.1. There were more diffs w.r.t. Paul’s 0.4.0 than I expected so it would be nice if someone reviewed the merge.
>>
>>             I’ve run the test suite on Windows 64 (VC++) and Ubuntu 20 (WSL). Volunteer needed to test on macOS (at least) and confirm.
>>
>>             I do not plan further work on it myself.
>>
>>             /Ashok
>>
>>             *From:*Paul Obermeier <pa...@po...> <mailto:pa...@po...>
>>             *Sent:* Thursday, June 19, 2025 12:55 AM
>>             *To:* apn...@ya...; tcl...@li...
>>             *Subject:* Re: [TCLCORE] tclx, tktreectrl and tkpath repositories and a request
>>
>>             Some history.
>>             I originally had Rene's tkpath version in BAWT (last update was in 2018),
>>             which does not compile on Mac.
>>             Manfred Rosenberger (author of tkpath based RattleCAD) asked me to add
>>             Christian Werner's version of tkpath, because his version runs on Mac and
>>             has several other fixes.
>>             After Tcl9 release Steve Shaw sent me a Tcl9 ready version of tkpath.
>>             Unfortunately this version was based on Rene's version (no Mac) and did only
>>             work with Tcl9, but not Tcl8.
>>             I then merged the Tcl9 changes into Christian's version, which is the version 0.4.0
>>             available with BAWT.
>>
>>             So in my point of view, the BAWT version is the most advanced one.
>>             It runs the test suite without errors on Windows and Linux using Tcl/Tk 8.6.16 and Tcl/Tk 9.0.1
>>             The test suite runs on Mac with 1 error both using Tcl/Tk 8.6.16 and 9.0.1, see below.
>>
>>             Paul
>>
>>             ==== canvText-1.12 configuration options: bad value for -stipple FAILED
>>             ==== Contents of test case:
>>
>>                 .c create text 20 20 -tag test
>>                 .c itemconfigure test $name $badValue
>>
>>             ---- Test completed normally; Return code was: 0
>>             ---- Return code should have been one of: 1
>>             ==== canvText-1.12 FAILED
>>
>>
>>             Am 18.06.2025 um 05:26 schrieb apnmbx-public--- via Tcl-Core:
>>
>>                 Thanks Paul. Do you know if your version of tkpath also incorporates Rene’s changes from chiselapp?
>>
>>                 I hope someone picks up tkpath, else I will make an attempt at a merge at some point. For the macOS issues, I’m afraid I have no way of testing GUI’s. At least for console only, Github actions can be used (painfully).
>>
>>                 /Ashok
>>
>>                 *From:*Paul Obermeier <pa...@po...> <mailto:pa...@po...>
>>
>>                 I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles
>>                 using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
>>                 See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z
>>
>>                 It works on Windows and Linux using Tcl 8.6 and 9.0.
>>                 It works on Mac using 8.6, but does not work with Tcl 9.0.
>>
>>
>>
>>
>>                     tktreectrl and tkpath have been tested on Windows and Linux. Someone testing on macOS would be helpful.
>>
>>                 Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.
>>
>>                 Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.
>>
>>
>>
>>
>>
>>                 _______________________________________________
>>
>>                 Tcl-Core mailing list
>>
>>                 Tcl...@li...
>>
>>                 https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>
>>
>>
>>             _______________________________________________
>>
>>             Tcl-Core mailing list
>>
>>             Tcl...@li...
>>
>>             https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>         _______________________________________________
>>         Tcl-Core mailing list
>>         Tcl...@li...
>>         https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>
>>
>>     _______________________________________________
>>     Tcl-Core mailing list
>>     Tcl...@li...
>>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li...
>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] TIP 726

[<apn...@ya...>]

Harald,

I will make a note of the alternative of adding commands to the [string] ensemble instead (as you mentioned on the chat).

Regarding your suggestion of "compose/decompose" those operations are not identical to normalization. Also, I prefer the use of the terms defined in the standard (like NFC) so as to reflect the exact semantics. Users who care will likely know the terms as they are also used in other languages. Still, I will make a note of this suggestion as well.

Thanks

/Ashok

-----Original Message-----
From: Harald Oehlmann <har...@el...> 
Sent: Monday, June 30, 2025 6:38 PM
To: Tcl Core List <tcl...@li...>
Subject: [TCLCORE] TIP 726

Ashok,
thanks for authoring TIP 726, this is welcomed !

The covered normalization functions are:
D118 Normalization Form D (NFD): The Canonical Decomposition of a coded 
character sequence.
D119 Normalization Form KD (NFKD): The Compatibility Decomposition of a 
coded character sequence.
D120 Normalization Form C (NFC): The Canonical Composition of the 
Canonical Decomposition of a coded character sequence.
D121 Normalization Form KC (NFKC): The Canonical Composition of the 
Compatibility Decomposition of a coded character sequence.

So, two are decompositions, two are compositions.
The first two basically decompose a Unicode to multiple others, the 2nd 
two compose multiple Unicodes to one (simply speaking) (it is much much 
more difficult).

I would name them in a more verbose way, like decompose and compose.

The "NF" meanes "Normalizes form". D/C is for decompose or compose and K 
is for compatibility.

Thanks for all,
Harald

Re: [TCLCORE] TkPath 0.4.1

[Marc C. <cul...@gm...>]

Tk 9 uses updateLayer instead of drawRect. (!!!!!!!!!!!!!)

That means that the process for getting a working CGContextRef needs to be
different.

I will submit a PR.

- Marc


On Mon, Jun 30, 2025 at 8:05 AM Paul Obermeier <pa...@po...> wrote:

> Thanks Nicolas for testing and reporting.
>
> I got the same warnings when compiling on MacOS.
> I checked the first warning with the suspicious pointer cast,
> but found out that the corresponding code is not called when running the
> "Apple" demo.
> So this warning does not seem to be the primary case, that demos do not
> run with Tk9.
>
> Paul
>
> Am 30.06.2025 um 08:20 schrieb nicolas bats:
>
> Hi Paul, Ashok,
>
> I've compiled tkPath on macOS15 and here's reported warnings:
>
> *./macosx/tkMacOSXPath.c:113:50: **warning: **incompatible pointer types
> passing 'TkWindow *' (aka 'struct TkWindow *') to parameter of type
> 'Tk_Window' (aka 'struct Tk_Window_ *') [-Wincompatible-pointer-types]*
>
>   113 |         Tk_Window contWinPtr =
> Tk_GetOtherWindow(macWin->toplevel->winPtr);
>
>       | *
> ^~~~~~~~~~~~~~~~~~~~~~~~*
>
> *./macosx/tkMacOSXPath.c:244:24: **warning: **'disableFlushWindow' is
> deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext
> runAnimationGroup:completionHandler:] to perform atomic updates across
> runloop invocations. [-Wdeprecated-declarations]*
>
>   244 |         [[view window] disableFlushWindow];
>
>       | *                       ^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1010:1:
> **note: *'disableFlushWindow' has been explicitly marked deprecated here
>
>  1010 | - (void)disableFlushWindow API_DEPRECATED("Use
> +[NSAnimationContext runAnimationGroup:completionHandler:] to perform
> atomic updates across runloop invocations.", macos(10.0,10.14));
>
>       | *^*
>
> *./macosx/tkMacOSXPath.c:247:53: **warning: **'graphicsPort' is
> deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]*
>
>   247 |         context->c = (CGContextRef)[currentGraphicsContext
> graphicsPort];
>
>       | *
> ^~~~~~~~~~~~*
>
>       |
> CGContext
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28:
> **note: *property 'graphicsPort' is declared deprecated here
>
>   107 | @property (readonly) void *graphicsPort NS_RETURNS_INNER_POINTER
> API_DEPRECATED_WITH_REPLACEMENT("CGContext", macos(10.0,10.14));
>
>       | *                           ^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28:
> **note: *'graphicsPort' has been explicitly marked deprecated here
>
> *./macosx/tkMacOSXPath.c:295:30: **warning: **'enableFlushWindow' is
> deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext
> runAnimationGroup:completionHandler:] to perform atomic updates across
> runloop invocations. [-Wdeprecated-declarations]*
>
>   295 |             [[context->view window] enableFlushWindow];
>
>       | *                                    ^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1011:1:
> **note: *'enableFlushWindow' has been explicitly marked deprecated here
>
>  1011 | - (void)enableFlushWindow API_DEPRECATED("Use
> +[NSAnimationContext runAnimationGroup:completionHandler:] to perform
> atomic updates across runloop invocations.", macos(10.0,10.14));
>
>       | *^*
>
> 4 warnings generated.
>
>
>
> should I open a ticket on gitHub?
>
> best regards,
>
> nicolas
>
> Le jeu. 26 juin 2025 à 05:06, apnmbx-public--- via Tcl-Core <
> tcl...@li...> a écrit :
>
>> Thanks Paul. I overlooked checking the demos. Committed a fix and they
>> should be working now. Verified 9.0 and 8.6 with Ubuntu and 9.0 with VC++.
>> Missed a structure field initializer during the merge though I’m not sure
>> why it only impacted 9.0 and not 8.6.
>>
>>
>>
>> Also, I noticed the TkPathItemType and TkPathCanvas structure no longer
>> match the corresponding types in Tk. I presume that is ok since they are
>> only used internally.
>>
>>
>>
>> Hope someone will look at macos errors.
>>
>>
>>
>> /Ashok
>>
>>
>>
>> *From:* Paul Obermeier <pa...@po...> <pa...@po...>
>> *Sent:* Thursday, June 26, 2025 1:22 AM
>> *To:* tcl...@li...
>> *Subject:* Re: [TCLCORE] TkPath 0.4.1
>>
>>
>>
>> Thanks Ashok for caring.
>>
>> I tested the tcltk-depot version on Windows (gcc), several Linux distros,
>> Raspi and RiscV
>> using Tcl/Tk 8.6.16 and 9.0.1.
>> With the exception of MacOS the test suite runs without errors.
>> On MacOS 15.5 there is 1 test suite error (both using 8.6.16 and 9.0.1),
>> see below.
>> The demos work fine using 8.6.16, but do not work using 9.0.1.
>>
>> I created issues for the 2 MacOS problems in case one of the Mac gurus
>> wants to take a closer look.
>>
>> Regards,
>> Paul
>>
>> Am 25.06.2025 um 17:30 schrieb apnmbx-public--- via Tcl-Core:
>>
>> https://github.com/tcltk-depot/tkpath now (purportedly) holds the merge
>> of all the tkpath forks, versioned 0.4.1. There were more diffs w.r.t.
>> Paul’s 0.4.0 than I expected so it would be nice if someone reviewed the
>> merge.
>>
>>
>>
>> I’ve run the test suite on Windows 64 (VC++) and Ubuntu 20 (WSL).
>> Volunteer needed to test on macOS (at least) and confirm.
>>
>>
>>
>> I do not plan further work on it myself.
>>
>>
>>
>> /Ashok
>>
>>
>>
>> *From:* Paul Obermeier <pa...@po...> <pa...@po...>
>> *Sent:* Thursday, June 19, 2025 12:55 AM
>> *To:* apn...@ya...; tcl...@li...
>> *Subject:* Re: [TCLCORE] tclx, tktreectrl and tkpath repositories and a
>> request
>>
>>
>>
>> Some history.
>> I originally had Rene's tkpath version in BAWT (last update was in 2018),
>> which does not compile on Mac.
>> Manfred Rosenberger (author of tkpath based RattleCAD) asked me to add
>> Christian Werner's version of tkpath, because his version runs on Mac and
>> has several other fixes.
>> After Tcl9 release Steve Shaw sent me a Tcl9 ready version of tkpath.
>> Unfortunately this version was based on Rene's version (no Mac) and did
>> only
>> work with Tcl9, but not Tcl8.
>> I then merged the Tcl9 changes into Christian's version, which is the
>> version 0.4.0
>> available with BAWT.
>>
>> So in my point of view, the BAWT version is the most advanced one.
>> It runs the test suite without errors on Windows and Linux using Tcl/Tk
>> 8.6.16 and Tcl/Tk 9.0.1
>> The test suite runs on Mac with 1 error both using Tcl/Tk 8.6.16 and
>> 9.0.1, see below.
>>
>> Paul
>>
>> ==== canvText-1.12 configuration options: bad value for -stipple FAILED
>> ==== Contents of test case:
>>
>>     .c create text 20 20 -tag test
>>     .c itemconfigure test $name $badValue
>>
>> ---- Test completed normally; Return code was: 0
>> ---- Return code should have been one of: 1
>> ==== canvText-1.12 FAILED
>>
>>
>> Am 18.06.2025 um 05:26 schrieb apnmbx-public--- via Tcl-Core:
>>
>> Thanks Paul. Do you know if your version of tkpath also incorporates
>> Rene’s changes from chiselapp?
>>
>>
>>
>> I hope someone picks up tkpath, else I will make an attempt at a merge at
>> some point. For the macOS issues, I’m afraid I have no way of testing
>> GUI’s. At least for console only, Github actions can be used (painfully).
>>
>>
>>
>> /Ashok
>>
>>
>>
>> *From:* Paul Obermeier <pa...@po...> <pa...@po...>
>>
>> I do have a version of tkpath, which is a merge of Christian's and
>> Steve's work and compiles
>> using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
>> See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z
>>
>> It works on Windows and Linux using Tcl 8.6 and 9.0.
>> It works on Mac using 8.6, but does not work with Tcl 9.0.
>>
>>
>>
>>
>> tktreectrl and tkpath have been tested on Windows and Linux. Someone
>> testing on macOS would be helpful.
>>
>> Repository version of tktreectrl works on Windows, Linux, Mac using Tcl
>> 8.6 and 9.0.
>>
>> Note, that I tested the packages only by using the simple scripts
>> contained in the BAWT framework.
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Tcl-Core mailing list
>>
>> Tcl...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>>
>> Tcl-Core mailing list
>>
>> Tcl...@li...
>>
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>
>
> _______________________________________________
> Tcl-Core mailing lis...@li...https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] TkPath 0.4.1

[Paul O. <pa...@po...>]

Thanks Nicolas for testing and reporting.

I got the same warnings when compiling on MacOS.
I checked the first warning with the suspicious pointer cast,
but found out that the corresponding code is not called when running the "Apple" demo.
So this warning does not seem to be the primary case, that demos do not run with Tk9.

Paul

Am 30.06.2025 um 08:20 schrieb nicolas bats:
> Hi Paul, Ashok,
>
> I've compiled tkPath on macOS15 and here's reported warnings:
>
> *./macosx/tkMacOSXPath.c:113:50: **warning: **incompatible pointer types passing 'TkWindow *' (aka 'struct TkWindow *') to parameter of type 'Tk_Window' (aka 'struct Tk_Window_ *') [-Wincompatible-pointer-types]*
>
> 113 | Tk_Window contWinPtr = Tk_GetOtherWindow(macWin->toplevel->winPtr);
>
> |*^~~~~~~~~~~~~~~~~~~~~~~~*
>
> *./macosx/tkMacOSXPath.c:244:24: **warning: **'disableFlushWindow' is deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations. [-Wdeprecated-declarations]*
>
> 244 | [[view window] disableFlushWindow];
>
> |*^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1010:1: **note: *'disableFlushWindow' has been explicitly marked deprecated here
>
> 1010 | - (void)disableFlushWindow API_DEPRECATED("Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations.", macos(10.0,10.14));
>
> | *^*
>
> *./macosx/tkMacOSXPath.c:247:53: **warning: **'graphicsPort' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]*
>
> 247 | context->c = (CGContextRef)[currentGraphicsContext graphicsPort];
>
> |*^~~~~~~~~~~~*
>
> |CGContext
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28: **note: *property 'graphicsPort' is declared deprecated here
>
> 107 | @property (readonly) void*graphicsPort NS_RETURNS_INNER_POINTER API_DEPRECATED_WITH_REPLACEMENT("CGContext", macos(10.0,10.14));
>
> |*^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28: **note: *'graphicsPort' has been explicitly marked deprecated here
>
> *./macosx/tkMacOSXPath.c:295:30: **warning: **'enableFlushWindow' is deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations. [-Wdeprecated-declarations]*
>
> 295 | [[context->view window] enableFlushWindow];
>
> | *^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1011:1: **note: *'enableFlushWindow' has been explicitly marked deprecated here
>
> 1011 | - (void)enableFlushWindow API_DEPRECATED("Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations.", macos(10.0,10.14));
>
> | *^*
>
> 4 warnings generated.
>
>
>
> should I open a ticket on gitHub?
>
> best regards,
>
> nicolas
>
>
> Le jeu. 26 juin 2025 à 05:06, apnmbx-public--- via Tcl-Core <tcl...@li...> a écrit :
>
>     Thanks Paul. I overlooked checking the demos. Committed a fix and they should be working now. Verified 9.0 and 8.6 with Ubuntu and 9.0 with VC++. Missed a structure field initializer during the merge though I’m not sure why it only impacted 9.0 and not 8.6.
>
>     Also, I noticed the TkPathItemType and TkPathCanvas structure no longer match the corresponding types in Tk. I presume that is ok since they are only used internally.
>
>     Hope someone will look at macos errors.
>
>     /Ashok
>
>     *From:*Paul Obermeier <pa...@po...>
>     *Sent:* Thursday, June 26, 2025 1:22 AM
>     *To:* tcl...@li...
>     *Subject:* Re: [TCLCORE] TkPath 0.4.1
>
>     Thanks Ashok for caring.
>
>     I tested the tcltk-depot version on Windows (gcc), several Linux distros, Raspi and RiscV
>     using Tcl/Tk 8.6.16 and 9.0.1.
>     With the exception of MacOS the test suite runs without errors.
>     On MacOS 15.5 there is 1 test suite error (both using 8.6.16 and 9.0.1), see below.
>     The demos work fine using 8.6.16, but do not work using 9.0.1.
>
>     I created issues for the 2 MacOS problems in case one of the Mac gurus
>     wants to take a closer look.
>
>     Regards,
>     Paul
>
>     Am 25.06.2025 um 17:30 schrieb apnmbx-public--- via Tcl-Core:
>
>         https://github.com/tcltk-depot/tkpath now (purportedly) holds the merge of all the tkpath forks, versioned 0.4.1. There were more diffs w.r.t. Paul’s 0.4.0 than I expected so it would be nice if someone reviewed the merge.
>
>         I’ve run the test suite on Windows 64 (VC++) and Ubuntu 20 (WSL). Volunteer needed to test on macOS (at least) and confirm.
>
>         I do not plan further work on it myself.
>
>         /Ashok
>
>         *From:*Paul Obermeier <pa...@po...> <mailto:pa...@po...>
>         *Sent:* Thursday, June 19, 2025 12:55 AM
>         *To:* apn...@ya...; tcl...@li...
>         *Subject:* Re: [TCLCORE] tclx, tktreectrl and tkpath repositories and a request
>
>         Some history.
>         I originally had Rene's tkpath version in BAWT (last update was in 2018),
>         which does not compile on Mac.
>         Manfred Rosenberger (author of tkpath based RattleCAD) asked me to add
>         Christian Werner's version of tkpath, because his version runs on Mac and
>         has several other fixes.
>         After Tcl9 release Steve Shaw sent me a Tcl9 ready version of tkpath.
>         Unfortunately this version was based on Rene's version (no Mac) and did only
>         work with Tcl9, but not Tcl8.
>         I then merged the Tcl9 changes into Christian's version, which is the version 0.4.0
>         available with BAWT.
>
>         So in my point of view, the BAWT version is the most advanced one.
>         It runs the test suite without errors on Windows and Linux using Tcl/Tk 8.6.16 and Tcl/Tk 9.0.1
>         The test suite runs on Mac with 1 error both using Tcl/Tk 8.6.16 and 9.0.1, see below.
>
>         Paul
>
>         ==== canvText-1.12 configuration options: bad value for -stipple FAILED
>         ==== Contents of test case:
>
>             .c create text 20 20 -tag test
>             .c itemconfigure test $name $badValue
>
>         ---- Test completed normally; Return code was: 0
>         ---- Return code should have been one of: 1
>         ==== canvText-1.12 FAILED
>
>
>         Am 18.06.2025 um 05:26 schrieb apnmbx-public--- via Tcl-Core:
>
>             Thanks Paul. Do you know if your version of tkpath also incorporates Rene’s changes from chiselapp?
>
>             I hope someone picks up tkpath, else I will make an attempt at a merge at some point. For the macOS issues, I’m afraid I have no way of testing GUI’s. At least for console only, Github actions can be used (painfully).
>
>             /Ashok
>
>             *From:*Paul Obermeier <pa...@po...> <mailto:pa...@po...>
>
>             I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles
>             using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
>             See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z
>
>             It works on Windows and Linux using Tcl 8.6 and 9.0.
>             It works on Mac using 8.6, but does not work with Tcl 9.0.
>
>
>
>
>                 tktreectrl and tkpath have been tested on Windows and Linux. Someone testing on macOS would be helpful.
>
>             Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.
>
>             Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.
>
>
>
>
>
>             _______________________________________________
>
>             Tcl-Core mailing list
>
>             Tcl...@li...
>
>             https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
>
>         _______________________________________________
>
>         Tcl-Core mailing list
>
>         Tcl...@li...
>
>         https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>     _______________________________________________
>     Tcl-Core mailing list
>     Tcl...@li...
>     https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] ETCL conference Program online 10/11 of July in Bologna/Italy

[Colin M. <col...@ya...>]

Yes, that works, and the Program link from the home page has been 
corrected too!

Thanks,
Colin.

On 30/06/2025 14:46, Paul Obermeier wrote:
> The correct link to the program (without logging in) is: 
> https://openacs.km.at/evaluate/org/129998253/companyhelp/schedule
>
> Am 30.06.2025 um 09:30 schrieb Harald Oehlmann:
>> Dear OpenACS/Tcl/Tk friends,
>>
>> the Bologna conference program is here:
>>
>> https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/static/xolrn/schedule 
>>
>>
>> Thomas Wunderlich was late, but got 10 minutes from Colin (thanks !), 
>> following the principle:
>> EHAT: Everyboady has a talk
>>
>> Official registration of on site participation will close today.
>>
>> Later registrations will be late registrations with extra penalty 
>> like less coffee ;-)
>>
>> There will probably no remote participation, but recording of the talks.
>>
>> I am happy to see you all !
>> Harald
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] ETCL conference Program online 10/11 of July in Bologna/Italy

[Paul O. <pa...@po...>]

The correct link to the program (without logging in) is: https://openacs.km.at/evaluate/org/129998253/companyhelp/schedule

Am 30.06.2025 um 09:30 schrieb Harald Oehlmann:
> Dear OpenACS/Tcl/Tk friends,
>
> the Bologna conference program is here:
>
> https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/static/xolrn/schedule
>
> Thomas Wunderlich was late, but got 10 minutes from Colin (thanks !), following the principle:
> EHAT: Everyboady has a talk
>
> Official registration of on site participation will close today.
>
> Later registrations will be late registrations with extra penalty like less coffee ;-)
>
> There will probably no remote participation, but recording of the talks.
>
> I am happy to see you all !
> Harald
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] TIP 726

[Harald O. <har...@el...>]

Ashok,
thanks for authoring TIP 726, this is welcomed !

The covered normalization functions are:
D118 Normalization Form D (NFD): The Canonical Decomposition of a coded 
character sequence.
D119 Normalization Form KD (NFKD): The Compatibility Decomposition of a 
coded character sequence.
D120 Normalization Form C (NFC): The Canonical Composition of the 
Canonical Decomposition of a coded character sequence.
D121 Normalization Form KC (NFKC): The Canonical Composition of the 
Compatibility Decomposition of a coded character sequence.

So, two are decompositions, two are compositions.
The first two basically decompose a Unicode to multiple others, the 2nd 
two compose multiple Unicodes to one (simply speaking) (it is much much 
more difficult).

I would name them in a more verbose way, like decompose and compose.

The "NF" meanes "Normalizes form". D/C is for decompose or compose and K 
is for compatibility.

Thanks for all,
Harald

[TCLCORE] Report of TCL/Tk biweekly telco on 30 of June, 2025 12:00 UTC

[Harald O. <har...@el...>]

Dear Tcl/Tk team,

please allow me to present this informal report on the biweekly telco 
2025-06-30 12:00 UTC.

Agenda:

Possible agenda:
1) Release items for TCL/Tk 9.0.2
There are a couple of new commits to branch core-9-0-branch. The 
question is which to include? -> include them all.
rc1 later today, with intended release on Wednsday.
Changes file pass and get to release notes.

2) Release items for Tcl/Tk 9.1.0a0
What gets in?

3) TIP 649: list API for lreverse ....
Not many votes. High performance for extensions. No brainer
4) TIP 700: documentation reform
Chat with Steve: All Section n of TCL are done.
Each time a new "source variant" is found, the converter script is changed.
Question was, if parts may be merged?
Answer: clear yes, ewview of smaller parts is more easy.
In addition, better work-flow.

5) TIP 726: unicode normalization
-> proposal by Ashok.
Is welcomed!

5) Conference status
Will be great!

AOB)
X.org was forked. Wayland only? Will this impact Tk?
Answer was, that the discussion looks bigger form the outside, than from 
the inside?
Wayland is an open question. Christian Werner has a Tk for Wayland.
Main issue is, that tTk also have to draw the Windows decoration (Task 
bar etc).

Other meetings:
8th of July 1:00 UTC: TCL meetup on same Jitsi
14th of July 12:00 UTC: UTC Monthly Virtual Meetup on same jitsi

Thank you all,
Harald

Re: [TCLCORE] TkPath 0.4.1

[nicolas b. <sl1...@gm...>]

results is the same while running demo, a white canvas is displayed

++

Le lun. 30 juin 2025 à 13:11, <apn...@ya...> a écrit :

> Nicolas,
>
>
>
> Thanks for testing. Please do file a ticket at
> https://github.com/tcltk-depot/tkpath/issues. If you are conversant
> enough with MacOS to suggest patch, a pull request would be even better.
>
>
>
> Did you run the test suite and / or demos after compilation? If so, were
> the result any different from what Paul reported?
>
>
>
> /Ashok
>
>
>
> *From:* nicolas bats <sl1...@gm...>
> *Sent:* Monday, June 30, 2025 11:51 AM
> *To:* apn...@ya...
> *Cc:* tcl...@li...
> *Subject:* Re: [TCLCORE] TkPath 0.4.1
>
>
>
> Hi Paul, Ashok,
>
>
>
> I've compiled tkPath on macOS15 and here's reported warnings:
>
>
>
> *./macosx/tkMacOSXPath.c:113:50: **warning: **incompatible pointer types
> passing 'TkWindow *' (aka 'struct TkWindow *') to parameter of type
> 'Tk_Window' (aka 'struct Tk_Window_ *') [-Wincompatible-pointer-types]*
>
>   113 |         Tk_Window contWinPtr =
> Tk_GetOtherWindow(macWin->toplevel->winPtr);
>
>       |
> *^~~~~~~~~~~~~~~~~~~~~~~~*
>
> *./macosx/tkMacOSXPath.c:244:24: **warning: **'disableFlushWindow' is
> deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext
> runAnimationGroup:completionHandler:] to perform atomic updates across
> runloop invocations. [-Wdeprecated-declarations]*
>
>   244 |         [[view window] disableFlushWindow];
>
>       |                        *^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1010:1:
> **note: *'disableFlushWindow' has been explicitly marked deprecated here
>
>  1010 | - (void)disableFlushWindow API_DEPRECATED("Use
> +[NSAnimationContext runAnimationGroup:completionHandler:] to perform
> atomic updates across runloop invocations.", macos(10.0,10.14));
>
>       | *^*
>
> *./macosx/tkMacOSXPath.c:247:53: **warning: **'graphicsPort' is
> deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]*
>
>   247 |         context->c = (CGContextRef)[currentGraphicsContext
> graphicsPort];
>
>       |
> *^~~~~~~~~~~~*
>
>       |
> CGContext
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28:
> **note: *property 'graphicsPort' is declared deprecated here
>
>   107 | @property (readonly) void *graphicsPort NS_RETURNS_INNER_POINTER
> API_DEPRECATED_WITH_REPLACEMENT("CGContext", macos(10.0,10.14));
>
>       |                            *^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28:
> **note: *'graphicsPort' has been explicitly marked deprecated here
>
> *./macosx/tkMacOSXPath.c:295:30: **warning: **'enableFlushWindow' is
> deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext
> runAnimationGroup:completionHandler:] to perform atomic updates across
> runloop invocations. [-Wdeprecated-declarations]*
>
>   295 |             [[context->view window] enableFlushWindow];
>
>       |                                     *^*
>
> */Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1011:1:
> **note: *'enableFlushWindow' has been explicitly marked deprecated here
>
>  1011 | - (void)enableFlushWindow API_DEPRECATED("Use
> +[NSAnimationContext runAnimationGroup:completionHandler:] to perform
> atomic updates across runloop invocations.", macos(10.0,10.14));
>
>       | *^*
>
> 4 warnings generated.
>
>
>
>
>
> should I open a ticket on gitHub?
>
> best regards,
>
> nicolas
>
>
>
> Le jeu. 26 juin 2025 à 05:06, apnmbx-public--- via Tcl-Core <
> tcl...@li...> a écrit :
>
> Thanks Paul. I overlooked checking the demos. Committed a fix and they
> should be working now. Verified 9.0 and 8.6 with Ubuntu and 9.0 with VC++.
> Missed a structure field initializer during the merge though I’m not sure
> why it only impacted 9.0 and not 8.6.
>
>
>
> Also, I noticed the TkPathItemType and TkPathCanvas structure no longer
> match the corresponding types in Tk. I presume that is ok since they are
> only used internally.
>
>
>
> Hope someone will look at macos errors.
>
>
>
> /Ashok
>
>
>
> *From:* Paul Obermeier <pa...@po...>
> *Sent:* Thursday, June 26, 2025 1:22 AM
> *To:* tcl...@li...
> *Subject:* Re: [TCLCORE] TkPath 0.4.1
>
>
>
> Thanks Ashok for caring.
>
> I tested the tcltk-depot version on Windows (gcc), several Linux distros,
> Raspi and RiscV
> using Tcl/Tk 8.6.16 and 9.0.1.
> With the exception of MacOS the test suite runs without errors.
> On MacOS 15.5 there is 1 test suite error (both using 8.6.16 and 9.0.1),
> see below.
> The demos work fine using 8.6.16, but do not work using 9.0.1.
>
> I created issues for the 2 MacOS problems in case one of the Mac gurus
> wants to take a closer look.
>
> Regards,
> Paul
>
> Am 25.06.2025 um 17:30 schrieb apnmbx-public--- via Tcl-Core:
>
> https://github.com/tcltk-depot/tkpath now (purportedly) holds the merge
> of all the tkpath forks, versioned 0.4.1. There were more diffs w.r.t.
> Paul’s 0.4.0 than I expected so it would be nice if someone reviewed the
> merge.
>
>
>
> I’ve run the test suite on Windows 64 (VC++) and Ubuntu 20 (WSL).
> Volunteer needed to test on macOS (at least) and confirm.
>
>
>
> I do not plan further work on it myself.
>
>
>
> /Ashok
>
>
>
> *From:* Paul Obermeier <pa...@po...> <pa...@po...>
> *Sent:* Thursday, June 19, 2025 12:55 AM
> *To:* apn...@ya...; tcl...@li...
> *Subject:* Re: [TCLCORE] tclx, tktreectrl and tkpath repositories and a
> request
>
>
>
> Some history.
> I originally had Rene's tkpath version in BAWT (last update was in 2018),
> which does not compile on Mac.
> Manfred Rosenberger (author of tkpath based RattleCAD) asked me to add
> Christian Werner's version of tkpath, because his version runs on Mac and
> has several other fixes.
> After Tcl9 release Steve Shaw sent me a Tcl9 ready version of tkpath.
> Unfortunately this version was based on Rene's version (no Mac) and did
> only
> work with Tcl9, but not Tcl8.
> I then merged the Tcl9 changes into Christian's version, which is the
> version 0.4.0
> available with BAWT.
>
> So in my point of view, the BAWT version is the most advanced one.
> It runs the test suite without errors on Windows and Linux using Tcl/Tk
> 8.6.16 and Tcl/Tk 9.0.1
> The test suite runs on Mac with 1 error both using Tcl/Tk 8.6.16 and
> 9.0.1, see below.
>
> Paul
>
> ==== canvText-1.12 configuration options: bad value for -stipple FAILED
> ==== Contents of test case:
>
>     .c create text 20 20 -tag test
>     .c itemconfigure test $name $badValue
>
> ---- Test completed normally; Return code was: 0
> ---- Return code should have been one of: 1
> ==== canvText-1.12 FAILED
>
> Am 18.06.2025 um 05:26 schrieb apnmbx-public--- via Tcl-Core:
>
> Thanks Paul. Do you know if your version of tkpath also incorporates
> Rene’s changes from chiselapp?
>
>
>
> I hope someone picks up tkpath, else I will make an attempt at a merge at
> some point. For the macOS issues, I’m afraid I have no way of testing
> GUI’s. At least for console only, Github actions can be used (painfully).
>
>
>
> /Ashok
>
>
>
> *From:* Paul Obermeier <pa...@po...> <pa...@po...>
>
> I do have a version of tkpath, which is a merge of Christian's and Steve's
> work and compiles
> using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
> See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z
>
> It works on Windows and Linux using Tcl 8.6 and 9.0.
> It works on Mac using 8.6, but does not work with Tcl 9.0.
>
>
>
> tktreectrl and tkpath have been tested on Windows and Linux. Someone
> testing on macOS would be helpful.
>
> Repository version of tktreectrl works on Windows, Linux, Mac using Tcl
> 8.6 and 9.0.
>
> Note, that I tested the packages only by using the simple scripts
> contained in the BAWT framework.
>
>
>
>
> _______________________________________________
>
> Tcl-Core mailing list
>
> Tcl...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
>
>
> _______________________________________________
>
> Tcl-Core mailing list
>
> Tcl...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>

Re: [TCLCORE] ETCL conference Program online 10/11 of July in Bologna/Italy

[Torsten B. <be...@ty...>]

Wow, so many interesting topics and talks ... and I cannot be there, sniff.

> Am 30.06.2025 um 12:56 schrieb Colin Macleod via Tcl-Core <tcl...@li...>:
> 
> I made a copy at https://cmacleod.me.uk/tcl/bologna/program.htm so that I could post links to it.
> 
> I hope this is ok.
> 
> Colin.
> 
> On 30/06/2025 09:27, Colin Macleod via Tcl-Core wrote:
>> Thanks. If you try to open the program link in a private/anonymous browser window you will see that it just goes to a login page.  People who are just interested in taking a look at the program are likely to give up if faced with this extra complication.
>> 
>> Colin.
>> 
>> On 30/06/2025 09:20, Harald Oehlmann wrote:
>>> It was told to me, that it is now available without login.
>>> I also considered to make a copy to the wiki due to that.
>>> We have a coordination telco today 17:00.
>>> Maybe, something may happen.
>>> 
>>> And yes, if you don't need coffee, you can register late ;-).
>>> 
>>> Sorry,
>>> Harald
>>> 
>>> Am 30.06.2025 um 09:58 schrieb Colin Macleod:
>>>> Thanks for this Harald, also you suggest that late registration may be possible, so it may still be worth publicising the event more.
>>>> 
>>>> Is there any reason why the program is still only accessible after logging in?
>>>> 
>>>> Would there be any objection to me making a copy of the program and posting it publicly?
>>>> 
>>>> Colin.
>>>> 
>>>> On 30/06/2025 08:30, Harald Oehlmann wrote:
>>>>> Dear OpenACS/Tcl/Tk friends,
>>>>> 
>>>>> the Bologna conference program is here:
>>>>> 
>>>>> https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/ static/xolrn/schedule
>>>>> 
>>>>> Thomas Wunderlich was late, but got 10 minutes from Colin (thanks !), following the principle:
>>>>> EHAT: Everyboady has a talk
>>>>> 
>>>>> Official registration of on site participation will close today.
>>>>> 
>>>>> Later registrations will be late registrations with extra penalty like less coffee ;-)
>>>>> 
>>>>> There will probably no remote participation, but recording of the talks.
>>>>> 
>>>>> I am happy to see you all !
>>>>> Harald
>> 
>> 
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] TkPath 0.4.1

[<apn...@ya...>]

Nicolas,

 

Thanks for testing. Please do file a ticket at https://github.com/tcltk-depot/tkpath/issues. If you are conversant enough with MacOS to suggest patch, a pull request would be even better.

 

Did you run the test suite and / or demos after compilation? If so, were the result any different from what Paul reported?

 

/Ashok

 

From: nicolas bats <sl1...@gm...> 
Sent: Monday, June 30, 2025 11:51 AM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] TkPath 0.4.1

 

Hi Paul, Ashok,

 

I've compiled tkPath on macOS15 and here's reported warnings:

 

./macosx/tkMacOSXPath.c:113:50: warning: incompatible pointer types passing 'TkWindow *' (aka 'struct TkWindow *') to parameter of type 'Tk_Window' (aka 'struct Tk_Window_ *') [-Wincompatible-pointer-types]

  113 |         Tk_Window contWinPtr = Tk_GetOtherWindow(macWin->toplevel->winPtr);

      |                                                  ^~~~~~~~~~~~~~~~~~~~~~~~

./macosx/tkMacOSXPath.c:244:24: warning: 'disableFlushWindow' is deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations. [-Wdeprecated-declarations]

  244 |         [[view window] disableFlushWindow];

      |                        ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1010:1: note: 'disableFlushWindow' has been explicitly marked deprecated here

 1010 | - (void)disableFlushWindow API_DEPRECATED("Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations.", macos(10.0,10.14));

      | ^

./macosx/tkMacOSXPath.c:247:53: warning: 'graphicsPort' is deprecated: first deprecated in macOS 10.14 [-Wdeprecated-declarations]

  247 |         context->c = (CGContextRef)[currentGraphicsContext graphicsPort];

      |                                                            ^~~~~~~~~~~~

      |                                                            CGContext

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28: note: property 'graphicsPort' is declared deprecated here

  107 | @property (readonly) void *graphicsPort NS_RETURNS_INNER_POINTER API_DEPRECATED_WITH_REPLACEMENT("CGContext", macos(10.0,10.14));

      |                            ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28: note: 'graphicsPort' has been explicitly marked deprecated here

./macosx/tkMacOSXPath.c:295:30: warning: 'enableFlushWindow' is deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations. [-Wdeprecated-declarations]

  295 |             [[context->view window] enableFlushWindow];

      |                                     ^

/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1011:1: note: 'enableFlushWindow' has been explicitly marked deprecated here

 1011 | - (void)enableFlushWindow API_DEPRECATED("Use +[NSAnimationContext runAnimationGroup:completionHandler:] to perform atomic updates across runloop invocations.", macos(10.0,10.14));

      | ^

4 warnings generated.

 

 

should I open a ticket on gitHub?

best regards,

nicolas

 

Le jeu. 26 juin 2025 à 05:06, apnmbx-public--- via Tcl-Core <tcl...@li... <mailto:tcl...@li...> > a écrit :

Thanks Paul. I overlooked checking the demos. Committed a fix and they should be working now. Verified 9.0 and 8.6 with Ubuntu and 9.0 with VC++. Missed a structure field initializer during the merge though I’m not sure why it only impacted 9.0 and not 8.6.

 

Also, I noticed the TkPathItemType and TkPathCanvas structure no longer match the corresponding types in Tk. I presume that is ok since they are only used internally.

 

Hope someone will look at macos errors.

 

/Ashok

 

From: Paul Obermeier <pa...@po... <mailto:pa...@po...> > 
Sent: Thursday, June 26, 2025 1:22 AM
To: tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] TkPath 0.4.1

 

Thanks Ashok for caring.

I tested the tcltk-depot version on Windows (gcc), several Linux distros, Raspi and RiscV
using Tcl/Tk 8.6.16 and 9.0.1.
With the exception of MacOS the test suite runs without errors. 
On MacOS 15.5 there is 1 test suite error (both using 8.6.16 and 9.0.1), see below.
The demos work fine using 8.6.16, but do not work using 9.0.1.

I created issues for the 2 MacOS problems in case one of the Mac gurus
wants to take a closer look.

Regards,
Paul

Am 25.06.2025 um 17:30 schrieb apnmbx-public--- via Tcl-Core:

https://github.com/tcltk-depot/tkpath now (purportedly) holds the merge of all the tkpath forks, versioned 0.4.1. There were more diffs w.r.t. Paul’s 0.4.0 than I expected so it would be nice if someone reviewed the merge.

 

I’ve run the test suite on Windows 64 (VC++) and Ubuntu 20 (WSL). Volunteer needed to test on macOS (at least) and confirm.

 

I do not plan further work on it myself.

 

/Ashok

 

From: Paul Obermeier  <mailto:pa...@po...> <pa...@po...> 
Sent: Thursday, June 19, 2025 12:55 AM
To: apn...@ya... <mailto:apn...@ya...> ; tcl...@li... <mailto:tcl...@li...> 
Subject: Re: [TCLCORE] tclx, tktreectrl and tkpath repositories and a request

 

Some history.
I originally had Rene's tkpath version in BAWT (last update was in 2018),
which does not compile on Mac.
Manfred Rosenberger (author of tkpath based RattleCAD) asked me to add 
Christian Werner's version of tkpath, because his version runs on Mac and
has several other fixes.
After Tcl9 release Steve Shaw sent me a Tcl9 ready version of tkpath.
Unfortunately this version was based on Rene's version (no Mac) and did only
work with Tcl9, but not Tcl8.
I then merged the Tcl9 changes into Christian's version, which is the version 0.4.0
available with BAWT.

So in my point of view, the BAWT version is the most advanced one.
It runs the test suite without errors on Windows and Linux using Tcl/Tk 8.6.16 and Tcl/Tk 9.0.1
The test suite runs on Mac with 1 error both using Tcl/Tk 8.6.16 and 9.0.1, see below.

Paul

==== canvText-1.12 configuration options: bad value for -stipple FAILED
==== Contents of test case:

    .c create text 20 20 -tag test
    .c itemconfigure test $name $badValue

---- Test completed normally; Return code was: 0
---- Return code should have been one of: 1
==== canvText-1.12 FAILED



Am 18.06.2025 um 05:26 schrieb apnmbx-public--- via Tcl-Core:

Thanks Paul. Do you know if your version of tkpath also incorporates Rene’s changes from chiselapp?

 

I hope someone picks up tkpath, else I will make an attempt at a merge at some point. For the macOS issues, I’m afraid I have no way of testing GUI’s. At least for console only, Github actions can be used (painfully).

 

/Ashok

 

From: Paul Obermeier  <mailto:pa...@po...> <pa...@po...> 

I do have a version of tkpath, which is a merge of Christian's and Steve's work and compiles  
using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z

It works on Windows and Linux using Tcl 8.6 and 9.0.
It works on Mac using 8.6, but does not work with Tcl 9.0.





tktreectrl and tkpath have been tested on Windows and Linux. Someone testing on macOS would be helpful.

Repository version of tktreectrl works on Windows, Linux, Mac using Tcl 8.6 and 9.0.

Note, that I tested the packages only by using the simple scripts contained in the BAWT framework.






_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...> 
https://lists.sourceforge.net/lists/listinfo/tcl-core

 





_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...> 
https://lists.sourceforge.net/lists/listinfo/tcl-core

 

_______________________________________________
Tcl-Core mailing list
Tcl...@li... <mailto:Tcl...@li...> 
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] ETCL conference Program online 10/11 of July in Bologna/Italy

[Colin M. <col...@ya...>]

I made a copy at https://cmacleod.me.uk/tcl/bologna/program.htm so that 
I could post links to it.

I hope this is ok.

Colin.

On 30/06/2025 09:27, Colin Macleod via Tcl-Core wrote:
> Thanks. If you try to open the program link in a private/anonymous 
> browser window you will see that it just goes to a login page.  People 
> who are just interested in taking a look at the program are likely to 
> give up if faced with this extra complication.
>
> Colin.
>
> On 30/06/2025 09:20, Harald Oehlmann wrote:
>> It was told to me, that it is now available without login.
>> I also considered to make a copy to the wiki due to that.
>> We have a coordination telco today 17:00.
>> Maybe, something may happen.
>>
>> And yes, if you don't need coffee, you can register late ;-).
>>
>> Sorry,
>> Harald
>>
>> Am 30.06.2025 um 09:58 schrieb Colin Macleod:
>>> Thanks for this Harald, also you suggest that late registration may 
>>> be possible, so it may still be worth publicising the event more.
>>>
>>> Is there any reason why the program is still only accessible after 
>>> logging in?
>>>
>>> Would there be any objection to me making a copy of the program and 
>>> posting it publicly?
>>>
>>> Colin.
>>>
>>> On 30/06/2025 08:30, Harald Oehlmann wrote:
>>>> Dear OpenACS/Tcl/Tk friends,
>>>>
>>>> the Bologna conference program is here:
>>>>
>>>> https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/ 
>>>> static/xolrn/schedule
>>>>
>>>> Thomas Wunderlich was late, but got 10 minutes from Colin (thanks 
>>>> !), following the principle:
>>>> EHAT: Everyboady has a talk
>>>>
>>>> Official registration of on site participation will close today.
>>>>
>>>> Later registrations will be late registrations with extra penalty 
>>>> like less coffee ;-)
>>>>
>>>> There will probably no remote participation, but recording of the 
>>>> talks.
>>>>
>>>> I am happy to see you all !
>>>> Harald
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] ETCL conference Program online 10/11 of July in Bologna/Italy

[Colin M. <col...@ya...>]

Thanks.  If you try to open the program link in a private/anonymous 
browser window you will see that it just goes to a login page.  People 
who are just interested in taking a look at the program are likely to 
give up if faced with this extra complication.

Colin.

On 30/06/2025 09:20, Harald Oehlmann wrote:
> It was told to me, that it is now available without login.
> I also considered to make a copy to the wiki due to that.
> We have a coordination telco today 17:00.
> Maybe, something may happen.
>
> And yes, if you don't need coffee, you can register late ;-).
>
> Sorry,
> Harald
>
> Am 30.06.2025 um 09:58 schrieb Colin Macleod:
>> Thanks for this Harald, also you suggest that late registration may 
>> be possible, so it may still be worth publicising the event more.
>>
>> Is there any reason why the program is still only accessible after 
>> logging in?
>>
>> Would there be any objection to me making a copy of the program and 
>> posting it publicly?
>>
>> Colin.
>>
>> On 30/06/2025 08:30, Harald Oehlmann wrote:
>>> Dear OpenACS/Tcl/Tk friends,
>>>
>>> the Bologna conference program is here:
>>>
>>> https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/ 
>>> static/xolrn/schedule
>>>
>>> Thomas Wunderlich was late, but got 10 minutes from Colin (thanks 
>>> !), following the principle:
>>> EHAT: Everyboady has a talk
>>>
>>> Official registration of on site participation will close today.
>>>
>>> Later registrations will be late registrations with extra penalty 
>>> like less coffee ;-)
>>>
>>> There will probably no remote participation, but recording of the 
>>> talks.
>>>
>>> I am happy to see you all !
>>> Harald

Re: [TCLCORE] ETCL conference Program online 10/11 of July in Bologna/Italy

[Harald O. <har...@el...>]

It was told to me, that it is now available without login.
I also considered to make a copy to the wiki due to that.
We have a coordination telco today 17:00.
Maybe, something may happen.

And yes, if you don't need coffee, you can register late ;-).

Sorry,
Harald

Am 30.06.2025 um 09:58 schrieb Colin Macleod:
> Thanks for this Harald, also you suggest that late registration may be 
> possible, so it may still be worth publicising the event more.
> 
> Is there any reason why the program is still only accessible after 
> logging in?
> 
> Would there be any objection to me making a copy of the program and 
> posting it publicly?
> 
> Colin.
> 
> On 30/06/2025 08:30, Harald Oehlmann wrote:
>> Dear OpenACS/Tcl/Tk friends,
>>
>> the Bologna conference program is here:
>>
>> https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/ 
>> static/xolrn/schedule
>>
>> Thomas Wunderlich was late, but got 10 minutes from Colin (thanks !), 
>> following the principle:
>> EHAT: Everyboady has a talk
>>
>> Official registration of on site participation will close today.
>>
>> Later registrations will be late registrations with extra penalty like 
>> less coffee ;-)
>>
>> There will probably no remote participation, but recording of the talks.
>>
>> I am happy to see you all !
>> Harald

Re: [TCLCORE] ETCL conference Program online 10/11 of July in Bologna/Italy

[Colin M. <col...@ya...>]

Thanks for this Harald, also you suggest that late registration may be 
possible, so it may still be worth publicising the event more.

Is there any reason why the program is still only accessible after 
logging in?

Would there be any objection to me making a copy of the program and 
posting it publicly?

Colin.

On 30/06/2025 08:30, Harald Oehlmann wrote:
> Dear OpenACS/Tcl/Tk friends,
>
> the Bologna conference program is here:
>
> https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/static/xolrn/schedule 
>
>
> Thomas Wunderlich was late, but got 10 minutes from Colin (thanks !), 
> following the principle:
> EHAT: Everyboady has a talk
>
> Official registration of on site participation will close today.
>
> Later registrations will be late registrations with extra penalty like 
> less coffee ;-)
>
> There will probably no remote participation, but recording of the talks.
>
> I am happy to see you all !
> Harald
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] ETCL conference Program online 10/11 of July in Bologna/Italy

[Harald O. <har...@el...>]

Dear OpenACS/Tcl/Tk friends,

the Bologna conference program is here:

https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/static/xolrn/schedule

Thomas Wunderlich was late, but got 10 minutes from Colin (thanks !), 
following the principle:
EHAT: Everyboady has a talk

Official registration of on site participation will close today.

Later registrations will be late registrations with extra penalty like 
less coffee ;-)

There will probably no remote participation, but recording of the talks.

I am happy to see you all !
Harald

Re: [TCLCORE] TkPath 0.4.1

[nicolas b. <sl1...@gm...>]

Hi Paul, Ashok,

I've compiled tkPath on macOS15 and here's reported warnings:

*./macosx/tkMacOSXPath.c:113:50: **warning: **incompatible pointer types
passing 'TkWindow *' (aka 'struct TkWindow *') to parameter of type
'Tk_Window' (aka 'struct Tk_Window_ *') [-Wincompatible-pointer-types]*

  113 |         Tk_Window contWinPtr =
Tk_GetOtherWindow(macWin->toplevel->winPtr);

      | *
^~~~~~~~~~~~~~~~~~~~~~~~*

*./macosx/tkMacOSXPath.c:244:24: **warning: **'disableFlushWindow' is
deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext
runAnimationGroup:completionHandler:] to perform atomic updates across
runloop invocations. [-Wdeprecated-declarations]*

  244 |         [[view window] disableFlushWindow];

      | *                       ^*

*/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1010:1:
**note: *'disableFlushWindow' has been explicitly marked deprecated here

 1010 | - (void)disableFlushWindow API_DEPRECATED("Use +[NSAnimationContext
runAnimationGroup:completionHandler:] to perform atomic updates across
runloop invocations.", macos(10.0,10.14));

      | *^*

*./macosx/tkMacOSXPath.c:247:53: **warning: **'graphicsPort' is deprecated:
first deprecated in macOS 10.14 [-Wdeprecated-declarations]*

  247 |         context->c = (CGContextRef)[currentGraphicsContext
graphicsPort];

      | *
^~~~~~~~~~~~*

      |                                                            CGContext

*/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28:
**note: *property 'graphicsPort' is declared deprecated here

  107 | @property (readonly) void *graphicsPort NS_RETURNS_INNER_POINTER
API_DEPRECATED_WITH_REPLACEMENT("CGContext", macos(10.0,10.14));

      | *                           ^*

*/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSGraphicsContext.h:107:28:
**note: *'graphicsPort' has been explicitly marked deprecated here

*./macosx/tkMacOSXPath.c:295:30: **warning: **'enableFlushWindow' is
deprecated: first deprecated in macOS 10.14 - Use +[NSAnimationContext
runAnimationGroup:completionHandler:] to perform atomic updates across
runloop invocations. [-Wdeprecated-declarations]*

  295 |             [[context->view window] enableFlushWindow];

      | *                                    ^*

*/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks/AppKit.framework/Headers/NSWindow.h:1011:1:
**note: *'enableFlushWindow' has been explicitly marked deprecated here

 1011 | - (void)enableFlushWindow API_DEPRECATED("Use +[NSAnimationContext
runAnimationGroup:completionHandler:] to perform atomic updates across
runloop invocations.", macos(10.0,10.14));

      | *^*

4 warnings generated.



should I open a ticket on gitHub?

best regards,

nicolas

Le jeu. 26 juin 2025 à 05:06, apnmbx-public--- via Tcl-Core <
tcl...@li...> a écrit :

> Thanks Paul. I overlooked checking the demos. Committed a fix and they
> should be working now. Verified 9.0 and 8.6 with Ubuntu and 9.0 with VC++.
> Missed a structure field initializer during the merge though I’m not sure
> why it only impacted 9.0 and not 8.6.
>
>
>
> Also, I noticed the TkPathItemType and TkPathCanvas structure no longer
> match the corresponding types in Tk. I presume that is ok since they are
> only used internally.
>
>
>
> Hope someone will look at macos errors.
>
>
>
> /Ashok
>
>
>
> *From:* Paul Obermeier <pa...@po...>
> *Sent:* Thursday, June 26, 2025 1:22 AM
> *To:* tcl...@li...
> *Subject:* Re: [TCLCORE] TkPath 0.4.1
>
>
>
> Thanks Ashok for caring.
>
> I tested the tcltk-depot version on Windows (gcc), several Linux distros,
> Raspi and RiscV
> using Tcl/Tk 8.6.16 and 9.0.1.
> With the exception of MacOS the test suite runs without errors.
> On MacOS 15.5 there is 1 test suite error (both using 8.6.16 and 9.0.1),
> see below.
> The demos work fine using 8.6.16, but do not work using 9.0.1.
>
> I created issues for the 2 MacOS problems in case one of the Mac gurus
> wants to take a closer look.
>
> Regards,
> Paul
>
> Am 25.06.2025 um 17:30 schrieb apnmbx-public--- via Tcl-Core:
>
> https://github.com/tcltk-depot/tkpath now (purportedly) holds the merge
> of all the tkpath forks, versioned 0.4.1. There were more diffs w.r.t.
> Paul’s 0.4.0 than I expected so it would be nice if someone reviewed the
> merge.
>
>
>
> I’ve run the test suite on Windows 64 (VC++) and Ubuntu 20 (WSL).
> Volunteer needed to test on macOS (at least) and confirm.
>
>
>
> I do not plan further work on it myself.
>
>
>
> /Ashok
>
>
>
> *From:* Paul Obermeier <pa...@po...> <pa...@po...>
> *Sent:* Thursday, June 19, 2025 12:55 AM
> *To:* apn...@ya...; tcl...@li...
> *Subject:* Re: [TCLCORE] tclx, tktreectrl and tkpath repositories and a
> request
>
>
>
> Some history.
> I originally had Rene's tkpath version in BAWT (last update was in 2018),
> which does not compile on Mac.
> Manfred Rosenberger (author of tkpath based RattleCAD) asked me to add
> Christian Werner's version of tkpath, because his version runs on Mac and
> has several other fixes.
> After Tcl9 release Steve Shaw sent me a Tcl9 ready version of tkpath.
> Unfortunately this version was based on Rene's version (no Mac) and did
> only
> work with Tcl9, but not Tcl8.
> I then merged the Tcl9 changes into Christian's version, which is the
> version 0.4.0
> available with BAWT.
>
> So in my point of view, the BAWT version is the most advanced one.
> It runs the test suite without errors on Windows and Linux using Tcl/Tk
> 8.6.16 and Tcl/Tk 9.0.1
> The test suite runs on Mac with 1 error both using Tcl/Tk 8.6.16 and
> 9.0.1, see below.
>
> Paul
>
> ==== canvText-1.12 configuration options: bad value for -stipple FAILED
> ==== Contents of test case:
>
>     .c create text 20 20 -tag test
>     .c itemconfigure test $name $badValue
>
> ---- Test completed normally; Return code was: 0
> ---- Return code should have been one of: 1
> ==== canvText-1.12 FAILED
>
>
> Am 18.06.2025 um 05:26 schrieb apnmbx-public--- via Tcl-Core:
>
> Thanks Paul. Do you know if your version of tkpath also incorporates
> Rene’s changes from chiselapp?
>
>
>
> I hope someone picks up tkpath, else I will make an attempt at a merge at
> some point. For the macOS issues, I’m afraid I have no way of testing
> GUI’s. At least for console only, Github actions can be used (painfully).
>
>
>
> /Ashok
>
>
>
> *From:* Paul Obermeier <pa...@po...> <pa...@po...>
>
> I do have a version of tkpath, which is a merge of Christian's and Steve's
> work and compiles
> using Tcl 8.6 and 9.0 on Windows, Linux and Mac.
> See https://www.bawt.tcl3d.org/download/InputLibs/tkpath-0.4.0.7z
>
> It works on Windows and Linux using Tcl 8.6 and 9.0.
> It works on Mac using 8.6, but does not work with Tcl 9.0.
>
>
>
>
> tktreectrl and tkpath have been tested on Windows and Linux. Someone
> testing on macOS would be helpful.
>
> Repository version of tktreectrl works on Windows, Linux, Mac using Tcl
> 8.6 and 9.0.
>
> Note, that I tested the packages only by using the simple scripts
> contained in the BAWT framework.
>
>
>
>
>
> _______________________________________________
>
> Tcl-Core mailing list
>
> Tcl...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
>
>
>
>
> _______________________________________________
>
> Tcl-Core mailing list
>
> Tcl...@li...
>
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV

[Kevin W. <kw...@co...>]

<html><head><meta http-equiv="content-type" content="text/html; charset=utf-8"></head><body dir="auto"><img width="1" height="1" src="https://fedbdhd.r.af.d.sendibt2.com/tr/op/ia5UHg7mYrX2dbL9Z7O8N7nArZ4CknLKZra1l7EqRT_pwp7RSR3DBEpXxmH2OXyJCiINKqRbNL02jLkOAhe4eV8Dz1r3_9BABu8RzqpmxVbQ56hVo2wJsOIyVidDQp2rT0XGW0D5dmGN3nEHWOXdbTtADsnGGSrgaXOCaiMGqqtvYTiZg-xFaUGYiFnqiutq2HqX45v7XLIBbZ1hGS0sr0ZmwhpC4VLI" style="mso-hide:all"/><div dir="ltr"></div><div dir="ltr">TIP 725: &nbsp;YES</div><div dir="ltr"><br><blockquote type="cite">On Jun 29, 2025, at 12:00 PM, Marc Culler &lt;cul...@gm...&gt; wrote:<br><br></blockquote></div><blockquote type="cite"><div dir="ltr"><div dir="ltr"><div>It has now been 2 weeks, rather than 2 days, so I think it is time to call for votes on TIP #725.</div><div><br></div><div>Recall that this TIP targets Tk 9.1 and only affects the macOS port.&nbsp; It adds one new command in the ::tk::mac namespace.&nbsp; The new command GetInfoAsJSON is analogous to the existing command GetAppPath but provides much more information, namely the entire contents of the Info.plist file, allowing Tcl code running within a macOS Application to obtain information about its host Application without enraging Apple's gatekeeper.&nbsp; The NSDicitionary&nbsp;represented by the Info.plist file is serialized as a JSON-encoded string which is the return value of the command.&nbsp; The json package provided by Tcllib can be used to deserialize the JSON data as a Tcl dict.</div><div><br></div><div>The voting period will be about two weeks, ending at 2025-07-13T00:00:00 UTC, which has unix timestamp&nbsp;1752386400.</div><div><br></div><div>My vote:</div><div>TIP #725: YES</div><div><br></div><div>- Marc</div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Sun, Jun 15, 2025 at 9:01 AM Marc Culler &lt;<a href="mailto:cul...@gm...">cul...@gm...</a>&gt; wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div>This TIP was discussed quite a bit on this list, and the discussion now seems to have run its course without any objections having been raised.&nbsp; So I intend to call for a vote in a day or two.</div><div><br></div><div>- Marc</div></div>
</blockquote></div></div>
<span>_______________________________________________</span><br><span>Tcl-Core mailing list</span><br><span>Tcl...@li...</span><br><span>https://lists.sourceforge.net/lists/listinfo/tcl-core</span><br></div></blockquote></body></html>

Re: [TCLCORE] TIP #725 (::tk::mac::GetInfoAsJSON): CFV

[Marc C. <cul...@gm...>]

It has now been 2 weeks, rather than 2 days, so I think it is time to call
for votes on TIP #725.

Recall that this TIP targets Tk 9.1 and only affects the macOS port.  It
adds one new command in the ::tk::mac namespace.  The new command
GetInfoAsJSON is analogous to the existing command GetAppPath but provides
much more information, namely the entire contents of the Info.plist file,
allowing Tcl code running within a macOS Application to obtain information
about its host Application without enraging Apple's gatekeeper.  The
NSDicitionary represented by the Info.plist file is serialized as a
JSON-encoded string which is the return value of the command.  The json
package provided by Tcllib can be used to deserialize the JSON data as a
Tcl dict.

The voting period will be about two weeks, ending at 2025-07-13T00:00:00
UTC, which has unix timestamp 1752386400.

My vote:
TIP #725: YES

- Marc

On Sun, Jun 15, 2025 at 9:01 AM Marc Culler <cul...@gm...> wrote:

> This TIP was discussed quite a bit on this list, and the discussion now
> seems to have run its course without any objections having been raised.  So
> I intend to call for a vote in a day or two.
>
> - Marc
>

Re: [TCLCORE] Tcl 9.0.2 Release Candidate

[<apn...@ya...>]

The Windows exec-bug-4f0b5767ac error Paul reports can probably be ignored. The test constraint checks for presence of the winget file but not whether it is on the PATH. My guess is the MSYS environment Paul is running scrubs the Windows PATH and therefore does not find winget.

I've tested Tcl Windows 10+VS 2022 x64 combinations of shared, static, with and without embedded zipfs. Same results as Paul except for the winget failure which I don't see.

For Tk, have only tested the shared build so far and I see the usual 3 clipboard test failures (clipboard cannot be opened, another application grabbed it) that have been present on my system since 8.6 and can be ignored. I have never been able to figure out what application is grabbing the clipboard.

/Ashok

-----Original Message-----
From: Paul Obermeier <pa...@po...> 
Sent: Friday, June 27, 2025 11:21 PM
To: tcl...@li...
Subject: Re: [TCLCORE] Tcl 9.0.2 Release Candidate

Here are the results of the Tcl 9.0.2 test suite using my BAWT build environments.
No show-stoppers detected.

Operating system        Arch. Compiler Errors
-----------------------------------------------------
MacOS 15.5              M2      clang 17.0.0    0
Suse 15.6               x64     gcc 7.5.0       0
Raspberry Pi OS         arm64   gcc 12.2.0      0
Debian (StarFive)       RiscV   gcc 12.2.0      1
Windows 11              x86     gcc 7.2.0       4
Windows 11              x64     gcc 7.2.0       4
Windows 11              x64     VS2022          4

Windows tests include the usual 3 failures:
==== fCmd-9.3 file rename: comprehensive: file to new name FAILED
==== fCmd-9.10 file rename: comprehensive: file to new name and dir FAILED
==== winFCmd-3.10 TclpDeleteFile: path is readonly FAILED

Additional bug when running tests on Windows using MSys environment:

==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
==== Contents of test case:

     exec winget --info

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't execute "winget": no such file or directory
     while executing
"exec winget --info"
     ("uplevel" body line 2)
     invoked from within
"uplevel 1 $script"
---- errorCode: POSIX ENOENT {no such file or directory}
==== exec-bug-4f0b5767ac FAILED

StarFive failure (was already in Tcl 9.0.0):

==== binary-40.3 ScanNumber: NaN FAILED
==== Contents of test case:

     unset -nocomplain arg1
     list [binary scan \xFF\xFF\xFF\xFF f1 arg1] $arg1

---- Result was:
1 NaN
---- Result should have been (glob matching):
1 -NaN*
==== binary-40.3 FAILED

Am 26.06.2025 um 20:15 schrieb Donald G Porter via Tcl-Core:
>
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/9.0.2/
>
> is an RC0 candidate source code distribution pre-release of Tcl 9.0.2
>
> This is the first candidate release leading to the release of Tcl 9.0.2. Testing of builds
> and operations on multiple platforms is invited.  Any critical problem that should block
> the release should be reported immediately.
>
> The Tcl pre-release includes pre-releases of the packages Itcl 4.3.3, Thread 3.0.2,
> and TDBC* 1.1.11.  The same level of vetting on them is also appreciated.  The
> released package sqlite 3.49.1 is also included.
>
> Release notes are under development, and will be available in an RC1 release to follow.
>
> Thank you for your contributions and assistance.
>



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Tk 9.0.2 Release Candidate

[Paul O. <pa...@po...>]

Here are the results of the Tk 9.0.2 test suite using my BAWT build environments.
No show-stoppers detected.

Operating system        Arch. Compiler Errors
-----------------------------------------------------
MacOS 15.5              M2      clang 17.0.0    0
Suse 15.6               x64     gcc 7.5.0      60
Raspberry Pi OS         arm64   gcc 12.2.0     64
Debian (StarFive)       RiscV   gcc 12.2.0     39
Windows 11              x86     gcc 7.2.0       0
Windows 11              x64     gcc 7.2.0       0
Windows 11              x64     VS2022          0

Note, that Windows and Mac tests were executed on laptops.
To get zero failures, the system scaling had to be set to 100 %.

Paul

Am 26.06.2025 um 20:16 schrieb Donald G Porter via Tcl-Core:
>
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/9.0.2/
>
> is an RC0 candidate source code distribution pre-release of Tk 9.0.2
>
> This is the first candidate release leading to the release of Tk 9.0.2. Testing of builds
> and operations on multiple platforms is invited.  Any critical problem that should block
> the release should be reported immediately.
>
> Release notes are under development, and will be available in an RC1 release to follow.
>
> Thank you for your contributions and assistance.
>

Re: [TCLCORE] Tcl 9.0.2 Release Candidate

[Paul O. <pa...@po...>]

Here are the results of the Tcl 9.0.2 test suite using my BAWT build environments.
No show-stoppers detected.

Operating system        Arch. Compiler Errors
-----------------------------------------------------
MacOS 15.5              M2      clang 17.0.0    0
Suse 15.6               x64     gcc 7.5.0       0
Raspberry Pi OS         arm64   gcc 12.2.0      0
Debian (StarFive)       RiscV   gcc 12.2.0      1
Windows 11              x86     gcc 7.2.0       4
Windows 11              x64     gcc 7.2.0       4
Windows 11              x64     VS2022          4

Windows tests include the usual 3 failures:
==== fCmd-9.3 file rename: comprehensive: file to new name FAILED
==== fCmd-9.10 file rename: comprehensive: file to new name and dir FAILED
==== winFCmd-3.10 TclpDeleteFile: path is readonly FAILED

Additional bug when running tests on Windows using MSys environment:

==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
==== Contents of test case:

     exec winget --info

---- Test generated error; Return code was: 1
---- Return code should have been one of: 0 2
---- errorInfo: couldn't execute "winget": no such file or directory
     while executing
"exec winget --info"
     ("uplevel" body line 2)
     invoked from within
"uplevel 1 $script"
---- errorCode: POSIX ENOENT {no such file or directory}
==== exec-bug-4f0b5767ac FAILED

StarFive failure (was already in Tcl 9.0.0):

==== binary-40.3 ScanNumber: NaN FAILED
==== Contents of test case:

     unset -nocomplain arg1
     list [binary scan \xFF\xFF\xFF\xFF f1 arg1] $arg1

---- Result was:
1 NaN
---- Result should have been (glob matching):
1 -NaN*
==== binary-40.3 FAILED

Am 26.06.2025 um 20:15 schrieb Donald G Porter via Tcl-Core:
>
> Now available at
>
> https://sourceforge.net/projects/tcl/files/Tcl/9.0.2/
>
> is an RC0 candidate source code distribution pre-release of Tcl 9.0.2
>
> This is the first candidate release leading to the release of Tcl 9.0.2. Testing of builds
> and operations on multiple platforms is invited.  Any critical problem that should block
> the release should be reported immediately.
>
> The Tcl pre-release includes pre-releases of the packages Itcl 4.3.3, Thread 3.0.2,
> and TDBC* 1.1.11.  The same level of vetting on them is also appreciated.  The
> released package sqlite 3.49.1 is also included.
>
> Release notes are under development, and will be available in an RC1 release to follow.
>
> Thank you for your contributions and assistance.
>

Re: [TCLCORE] Tk 9.0.2 Release Candidate

[<apn...@ya...>]

Fixed the test to just check Windows*. Any further detail might just cause test failures
in other locales. Also, the actual text is really not important as the test is to ensure exec
handles app execution aliases correctly. Failures are detected by error exceptions.

-----Original Message-----
From: Paul Obermeier <pa...@po...> 
Sent: Friday, June 27, 2025 3:52 AM
To: tcl...@li...
Subject: Re: [TCLCORE] Tk 9.0.2 Release Candidate

Quick comments on the reported Windows failures:
1. winget failure: Maybe a "Windows*Manager*" match would be better than just "Windows*".
2. Tk failures: I do not get any failures, if scaling is set to 100%.

More results regarding the platforms supported by BAWT presumably tomorrow.

Paul


Am 26.06.2025 um 23:13 schrieb Harald Oehlmann:
> Am 26.06.2025 um 20:16 schrieb Donald G Porter via Tcl-Core:
>>
>> Now available at
>>
>> https://sourceforge.net/projects/tcl/files/Tcl/9.0.2/
>>
>> is an RC0 candidate source code distribution pre-release of Tk 9.0.2
> Thanks, great. Here is the test result with:
> MS-WIN 11 64bit GER,MS-VS2022.
>
> TCL&Tk&bundled packages:Build and install: clean
> Test with large application: ok
>
> Test suite:
> TCL: only test exec-bug-4f0b5767ac fails.
>
> This is due to a localization issue.
> The winget returns a German message, while the test result expects an English one, see below. Probably, only the word "Windows" may be tested...
>
> ==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
> ==== Contents of test case:
>
>     exec winget --info
>
> ---- Result was:
> Windows-Paket-Manager v1.11.400
> ...
> ---- Result should have been (glob matching):
> Windows Package Manager*
> ==== exec-bug-4f0b5767ac FAILED
>
> Tk test is more complicated.
> I had to press the enter button in one dialog test and there was a bg error message box. 18 tests failed.
> I suppose, I am working on my laptop in a hotel and the scaling factor is quite custom. The scaling is set in the windows system to 150%.
>
> The test report is as follows:
>
> ==== frame-12.3 FrameWorldChanged procedure FAILED
> ==== Contents of test case:
>
>     # Check reaction on font change
>     font create myfont -family courier -size 10
>     labelframe .f -font myfont -text Mupp
>     place .f -x 0 -y 0 -width 40 -height 40
>     pack [frame .f.f] -fill both -expand 1
>     update
>     set h1 [font metrics myfont -linespace]
>     set y1 [winfo y .f.f]
>     font configure myfont -size 20
>     update  ; # services the "TheWorldHasChanged" event, queues "TkWorldChanged" events
>     update  ; # services the queued "TkWorldChanged" events
>     set h2 [font metrics myfont -linespace]
>     set y2 [winfo y .f.f]
>     expr {($h2 - $h1) - ($y2 - $y1)}
>
> ---- Result was:
> 20
> ---- Result should have been (exact matching):
> 0
> ==== frame-12.3 FAILED
>
> ==== frame-14.1 labelframe labelwidget option FAILED
> ==== Contents of test case:
>
>     # Test that label is moved in stacking order
>     label .l -text Mupp -font {helvetica 8}
>     labelframe .f -labelwidget .l
>     pack .f
>     frame .f.f -width 50 -height 50
>     pack .f.f
>     update
>     list [winfo children .] [winfo width .f]  [expr {[winfo height .f] - [winfo height .l]}]
>
> ---- Result was:
> {.f .l} 57 52
> ---- Result should have been (exact matching):
> {.f .l} 54 52
> ==== frame-14.1 FAILED
>
> ==== grid-16.11 layout uniform (shrink) FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 75 -height 50
>     frame .f2 -width 100 -height 95
>     grid .f1 .f2 -sticky news
>     grid columnconfigure . {0 1} -uniform a
>     grid columnconfigure . 0 -weight 1
>     update
>     set res {}
>     lappend res [grid bbox . 0 0] [grid bbox . 1 0]
>     grid propagate . 0
>     . configure -width 150 -height 95
>     update
>     lappend res [grid bbox . 0 0] [grid bbox . 1 0]
>
> ---- Result was:
> {0 0 100 95} {100 0 100 95} {0 0 76 95} {76 0 100 95}
> ---- Result should have been (exact matching):
> {0 0 100 95} {100 0 100 95} {0 0 50 95} {50 0 100 95}
> ==== grid-16.11 FAILED
>
> ==== grid-16.13 layout span FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 24 -height 20
>     frame .f2 -width 38 -height 20
>     frame .f3 -width 150 -height 20
>     grid .f1 - - .f2
>     grid .f3 - - -
>     set res {}
>     foreach w {{0 1 0 0} {0 0 1 0} {1 3 4 0} {1 2 1 2} {1 1 1 12}} {
>     for {set c 0} {$c < 4} {incr c} {
>         grid columnconfigure . $c -weight [lindex $w $c]
>     }
>     update
>     set res2 {}
>     for {set c 0} {$c <= 4} {incr c} {
>         lappend res2 [lindex [grid bbox . $c 0] 2]
>     }
>     lappend res $res2
>     }
>     return $res
>     # The last result below should ideally be 8 8 8 126 but the current
>     # implementation is not exact enough.
>
> ---- Result was:
> {0 138 0 38 0} {0 0 138 38 0} {17 52 69 38 0} {22 47 22 85 0} {8 10 11 147 0}
> ---- Result should have been (exact matching):
> {0 112 0 38 0} {0 0 112 38 0} {14 42 56 38 0} {18 38 18 76 0} {7 8 9 126 0}
> ==== grid-16.13 FAILED
>
> ==== grid-16.14 layout span FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 110 -height 20
>     frame .f2 -width 38 -height 20
>     frame .f3 -width 150 -height 20
>     grid .f1 - - .f2
>     grid .f3 - - -
>     set res {}
>     foreach w {{0 1 0 0} {0 0 1 0} {1 3 4 0} {1 2 1 3} {1 1 1 12}} {
>     for {set c 0} {$c < 4} {incr c} {
>         grid columnconfigure . $c -weight [lindex $w $c]
>     }
>     update
>     set res2 {}
>     for {set c 0} {$c <= 4} {incr c} {
>         lappend res2 [lindex [grid bbox . $c 0] 2]
>     }
>     lappend res $res2
>     }
>     return $res
>
> ---- Result was:
> {0 138 0 38 0} {0 0 138 38 0} {17 52 69 38 0} {30 63 31 52 0} {37 39 39 61 0}
> ---- Result should have been (exact matching):
> {0 112 0 38 0} {0 0 112 38 0} {14 42 56 38 0} {27 55 28 40 0} {36 37 37 40 0}
> ==== grid-16.14 FAILED
>
> ==== grid-16.15 layout span FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 24 -height 20
>     frame .f2 -width 38 -height 20
>     frame .f3 -width 150 -height 20
>     grid .f1 - - .f2
>     grid x .f3 - -
>     set res {}
>     foreach w {{0 1 0 0} {0 0 1 0} {1 0 1 0} {0 0 0 0} {1 0 0 6}} {
>     for {set c 0} {$c < 4} {incr c} {
>         grid columnconfigure . $c -weight [lindex $w $c]
>     }
>     update
>     set res2 {}
>     for {set c 0} {$c <= 4} {incr c} {
>         lappend res2 [lindex [grid bbox . $c 0] 2]
>     }
>     lappend res $res2
>     }
>     return $res
>
> ---- Result was:
> {0 138 0 38 0} {0 0 138 38 0} {13 0 125 38 0} {0 37 37 76 0} {3 12 12 149 0}
> ---- Result should have been (exact matching):
> {0 112 0 38 0} {0 0 112 38 0} {0 0 112 38 0} {0 37 37 76 0} {0 12 12 126 0}
> ==== grid-16.15 FAILED
>
> ==== grid-16.16 layout span FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 64 -height 20
>     frame .f2 -width 38 -height 20
>     frame .f3 -width 150 -height 20
>     frame .f4 -width 15 -height 20
>     frame .f5 -width 18 -height 20
>     frame .f6 -width 20 -height 20
>     grid .f1 - x .f2
>     grid .f3 - - -
>     grid .f4 .f5 .f6
>     set res {}
>     foreach w {{1 1 5 1} {0 0 1 0} {1 3 4 0} {1 2 1 2} {1 1 1 12}} {
>     for {set c 0} {$c < 4} {incr c} {
>         grid columnconfigure . $c -weight [lindex $w $c]
>     }
>     update
>     set res2 {}
>     for {set c 0} {$c <= 4} {incr c} {
>         lappend res2 [lindex [grid bbox . $c 0] 2]
>     }
>     lappend res $res2
>     }
>     return $res
>
> ---- Result was:
> {33 37 59 47 0} {30 34 74 38 0} {25 52 61 38 0} {29 48 33 66 0} {31 36 24 85 0}
> ---- Result should have been (exact matching):
> {30 34 43 43 0} {30 34 48 38 0} {22 42 48 38 0} {25 39 29 57 0} {30 34 22 64 0}
> ==== grid-16.16 FAILED
>
> ==== grid-18.2 test support for minreqsize FAILED
> ==== Contents of test case:
>
>     toplevel .pack
>     wm geometry .pack {}
>     frame .pack.l -width 150 -height 100
>     labelframe .pack.lf -labelwidget .pack.l
>     pack .pack.lf -fill both -expand 1
>     frame .pack.lf.f -width 20 -height 25
>     grid .pack.lf.f
>     update
>     set res [list [winfo geometry .pack.lf]]
>     .pack.lf configure -labelanchor ws
>     update
>     lappend res [winfo geometry .pack.lf]
>     destroy .pack
>     return $res
>
> ---- Result was:
> 176x127+0+0 176x112+0+0
> ---- Result should have been (exact matching):
> 162x127+0+0 172x112+0+0
> ==== grid-18.2 FAILED
>
> ==== pack-19.2 test support for minreqsize FAILED
> ==== Contents of test case:
>
>     wm geometry .pack {}
>     frame .pack.l -width 150 -height 100
>     labelframe .pack.lf -labelwidget .pack.l
>     pack .pack.lf -fill both -expand 1
>     frame .pack.lf.f -width 20 -height 25
>     pack .pack.lf.f
>     update
>     set res [list [winfo geometry .pack.lf]]
>     .pack.lf configure -labelanchor ws
>     update
>     lappend res [winfo geometry .pack.lf]
>
> ---- Result was:
> 176x127+0+0 176x112+0+0
> ---- Result should have been (exact matching):
> 162x127+0+0 172x112+0+0
> ==== pack-19.2 FAILED
>
> ==== scrollbar-3.35 ScrollbarWidgetCmd procedure, "fraction" option FAILED
> ==== Contents of test case:
>
>     format {%.6g} [.s fraction 4 21]
>
> ---- Result was:
> 0
> ---- Result should have been (exact matching):
> -0.0340136
> ==== scrollbar-3.35 FAILED
>
> ==== scrollbar-3.36 ScrollbarWidgetCmd procedure, "fraction" option FAILED
> ==== Contents of test case:
>
>     format {%.6g} [.s fraction 4 179]
>
> ---- Result was:
> 1
> ---- Result should have been (exact matching):
> 1.04082
> ==== scrollbar-3.36 FAILED
>
> ==== scrollbar-3.38 ScrollbarWidgetCmd procedure, "fraction" option FAILED
> ==== Contents of test case:
>
>     format {%.6g} [.s fraction 4 178]
>
> ---- Result was:
> 1
> ---- Result should have been (exact matching):
> 1.03401
> ==== scrollbar-3.38 FAILED
>
> ==== scrollbar-6.27 ScrollbarPosition procedure FAILED
> ==== Contents of test case:
>
>     .s identify [expr {[winfo width .s] / 2}] [expr {int(.4 / [.s delta 0 1])
>                          + [testmetrics cyvscroll .s]}]
>
> ---- Result was:
> slider
> ---- Result should have been (exact matching):
> trough2
> ==== scrollbar-6.27 FAILED
>
> ==== textImage-4.2 alignment checking - baseline FAILED
> ==== Contents of test case:
>
>     catch {
>     image create photo small -width 5 -height 5
>     small put red -to 0 0 4 4
>     image create photo large -width 50 -height 50
>     large put green -to 0 0 50 50
>     }
>     font create test_font2 -size 5
>     text .t -font test_font2 -bd 0 -highlightthickness 0 -padx 0 -pady 0
>     pack .t
>     .t image create end -image large
>     .t image create end -image small -align baseline
>     .t insert end test
>     update
>     # Sizes larger than 25 can be too big and lead to a negative 'norm',
>     # at least on Windows XP with certain settings.
>     foreach size {10 15 20 25} {
>     font configure test_font2 -size $size
>     array set Metrics [font metrics test_font2]
>     update  ; # services the idle "TheWorldHasChanged" event, queues "TkWorldChanged" events
>     update  ; # services the queued "TkWorldChanged" events
>     foreach {x y w h} [.t bbox small] {}
>     set norm [expr {
>         (([image height large] - $Metrics(-linespace))/2
>         + $Metrics(-ascent) - [image height small] - $y)
>     }]
>     lappend result "$size $norm"
>     }
>     return $result
>
> ---- Result was:
> {10 0} {15 0} {20 0} {25 -4}
> ---- Result should have been (exact matching):
> {10 0} {15 0} {20 0} {25 0}
> ==== textImage-4.2 FAILED
>
> ==== winDialog-5.16 GetFileName: parent FAILED
> ==== Contents of test case:
>
> #        case FILE_PARENT:
>
>     toplevel .t
>     set x 0
>     testDialog launch {tk_getOpenFile -parent .t -title Parent; set x 1}
>     testDialog onDisplay {
>     destroy .t
>     }
>     return $x
>
> ---- Result was:
> 0
> ---- Result should have been (exact matching):
> 1
> ==== winDialog-5.16 FAILED
>
> ==== winWm-2.4 TkpWmSetState FAILED
> ==== Contents of test case:
>
>     toplevel .t
>     wm geometry .t 150x50+10+10
>     update
>     lappend result [list [wm state .t] [wm geometry .t]]
>     wm iconify .t
>     update
>     lappend result [list [wm state .t] [wm geometry .t]]
>     wm geometry .t 200x50+10+10
>     update
>     lappend result [list [wm state .t] [wm geometry .t]]
>     wm deiconify .t
>     update
>     lappend result [list [wm state .t] [wm geometry .t]]
>
> ---- Result was:
> {normal 176x50+10+10} {iconic 176x50+10+10} {iconic 176x50+10+10} {normal 200x50+10+10}
> ---- Result should have been (exact matching):
> {normal 150x50+10+10} {iconic 150x50+10+10} {iconic 150x50+10+10} {normal 200x50+10+10}
> ==== winWm-2.4 FAILED
>
> ==== winWm-5.1 UpdateGeometryInfo: menu resizing FAILED
> ==== Contents of test case:
>
>     toplevel .t
>     frame .t.f -width 150 -height 50 -background red
>     pack .t.f
>     update
>     set result [winfo height .t]
>     menu .t.m
>     .t.m add command -label foo
>     .t configure -menu .t.m
>     update
>     lappend result [winfo height .t]
>     .t.m add command -label "thisisreallylong"
>     .t.m add command -label "thisisreallylong"
>     update
>     lappend result [winfo height .t]
>
> ---- Result was:
> 50 50 0
> ---- Result should have been (exact matching):
> 50 50 31
> ==== winWm-5.1 FAILED
>
> ==== wm-geometry-2.1 setting values FAILED
> ==== Contents of test case:
>
>     wm geometry .t 150x150+50+50
>     update
>     set result [wm geometry .t]
>     wm geometry .t {}
>     update
>     return [list $result [string equal [wm geometry .t] $result]]
>
> ---- Result was:
> 176x150+50+50 0
> ---- Result should have been (glob matching):
> 150x150+*+* 0
> ==== wm-geometry-2.1 FAILED
>
> Sorry,
> Harald
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core



_______________________________________________
Tcl-Core mailing list
Tcl...@li...
https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Bologna/Italy conference 9/10th of July program published, registration still open

[Torsten B. <be...@ty...>]

Hi,

yes, totally agree. This would also be good for a repeated announcement on Mastodon and X/Twitter, trying to get some more people to attend.


Torsten


> Am 26.06.2025 um 16:12 schrieb Colin Macleod via Tcl-Core <tcl...@li...>:
> 
> Hi, it's good to get this update.
> 
> But why is the program only accessible after logging in?  I have already posted reminders about the conference in a few places, e.g. https://www.linkedin.com/posts/colin-macleod-099a1713_last-chance-to-register-for-the-2025-openacs-activity-7343924691171962881-wY0d. I would like to update these reminders with a link to the program, but that's not possible if it's not publicly accessible.  In previous years the program was also made public while registration was still open.
> 
> Colin.
> 
> On 26/06/2025 14:54, Harald Oehlmann wrote:
>> Dear OpenACS/TCL/Tk enthusiasts,
>> 
>> the conference program is now online:
>> 
>> https://openacs.km.at/evaluate/org/129998253/courses/event_130001647/static/xolrn/schedule 
>> 
>> Please feel invited to the conference in Bologna/Italy 9th to 10th of July 2025. The registration is still open until next Monday:
>> 
>> https://openacs.km.at
>> 
>> Best regards,
>> Antonio, Gustaf, Bernd, Stefan and Harald
>> 
>> 
>> 
>> _______________________________________________
>> Tcl-Core mailing list
>> Tcl...@li...
>> https://lists.sourceforge.net/lists/listinfo/tcl-core
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

Re: [TCLCORE] Tk 9.0.2 Release Candidate

[Paul O. <pa...@po...>]

Quick comments on the reported Windows failures:
1. winget failure: Maybe a "Windows*Manager*" match would be better than just "Windows*".
2. Tk failures: I do not get any failures, if scaling is set to 100%.

More results regarding the platforms supported by BAWT presumably tomorrow.

Paul


Am 26.06.2025 um 23:13 schrieb Harald Oehlmann:
> Am 26.06.2025 um 20:16 schrieb Donald G Porter via Tcl-Core:
>>
>> Now available at
>>
>> https://sourceforge.net/projects/tcl/files/Tcl/9.0.2/
>>
>> is an RC0 candidate source code distribution pre-release of Tk 9.0.2
> Thanks, great. Here is the test result with:
> MS-WIN 11 64bit GER,MS-VS2022.
>
> TCL&Tk&bundled packages:Build and install: clean
> Test with large application: ok
>
> Test suite:
> TCL: only test exec-bug-4f0b5767ac fails.
>
> This is due to a localization issue.
> The winget returns a German message, while the test result expects an English one, see below. Probably, only the word "Windows" may be tested...
>
> ==== exec-bug-4f0b5767ac exec App Execution Alias FAILED
> ==== Contents of test case:
>
>     exec winget --info
>
> ---- Result was:
> Windows-Paket-Manager v1.11.400
> ...
> ---- Result should have been (glob matching):
> Windows Package Manager*
> ==== exec-bug-4f0b5767ac FAILED
>
> Tk test is more complicated.
> I had to press the enter button in one dialog test and there was a bg error message box. 18 tests failed.
> I suppose, I am working on my laptop in a hotel and the scaling factor is quite custom. The scaling is set in the windows system to 150%.
>
> The test report is as follows:
>
> ==== frame-12.3 FrameWorldChanged procedure FAILED
> ==== Contents of test case:
>
>     # Check reaction on font change
>     font create myfont -family courier -size 10
>     labelframe .f -font myfont -text Mupp
>     place .f -x 0 -y 0 -width 40 -height 40
>     pack [frame .f.f] -fill both -expand 1
>     update
>     set h1 [font metrics myfont -linespace]
>     set y1 [winfo y .f.f]
>     font configure myfont -size 20
>     update  ; # services the "TheWorldHasChanged" event, queues "TkWorldChanged" events
>     update  ; # services the queued "TkWorldChanged" events
>     set h2 [font metrics myfont -linespace]
>     set y2 [winfo y .f.f]
>     expr {($h2 - $h1) - ($y2 - $y1)}
>
> ---- Result was:
> 20
> ---- Result should have been (exact matching):
> 0
> ==== frame-12.3 FAILED
>
> ==== frame-14.1 labelframe labelwidget option FAILED
> ==== Contents of test case:
>
>     # Test that label is moved in stacking order
>     label .l -text Mupp -font {helvetica 8}
>     labelframe .f -labelwidget .l
>     pack .f
>     frame .f.f -width 50 -height 50
>     pack .f.f
>     update
>     list [winfo children .] [winfo width .f]  [expr {[winfo height .f] - [winfo height .l]}]
>
> ---- Result was:
> {.f .l} 57 52
> ---- Result should have been (exact matching):
> {.f .l} 54 52
> ==== frame-14.1 FAILED
>
> ==== grid-16.11 layout uniform (shrink) FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 75 -height 50
>     frame .f2 -width 100 -height 95
>     grid .f1 .f2 -sticky news
>     grid columnconfigure . {0 1} -uniform a
>     grid columnconfigure . 0 -weight 1
>     update
>     set res {}
>     lappend res [grid bbox . 0 0] [grid bbox . 1 0]
>     grid propagate . 0
>     . configure -width 150 -height 95
>     update
>     lappend res [grid bbox . 0 0] [grid bbox . 1 0]
>
> ---- Result was:
> {0 0 100 95} {100 0 100 95} {0 0 76 95} {76 0 100 95}
> ---- Result should have been (exact matching):
> {0 0 100 95} {100 0 100 95} {0 0 50 95} {50 0 100 95}
> ==== grid-16.11 FAILED
>
> ==== grid-16.13 layout span FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 24 -height 20
>     frame .f2 -width 38 -height 20
>     frame .f3 -width 150 -height 20
>     grid .f1 - - .f2
>     grid .f3 - - -
>     set res {}
>     foreach w {{0 1 0 0} {0 0 1 0} {1 3 4 0} {1 2 1 2} {1 1 1 12}} {
>     for {set c 0} {$c < 4} {incr c} {
>         grid columnconfigure . $c -weight [lindex $w $c]
>     }
>     update
>     set res2 {}
>     for {set c 0} {$c <= 4} {incr c} {
>         lappend res2 [lindex [grid bbox . $c 0] 2]
>     }
>     lappend res $res2
>     }
>     return $res
>     # The last result below should ideally be 8 8 8 126 but the current
>     # implementation is not exact enough.
>
> ---- Result was:
> {0 138 0 38 0} {0 0 138 38 0} {17 52 69 38 0} {22 47 22 85 0} {8 10 11 147 0}
> ---- Result should have been (exact matching):
> {0 112 0 38 0} {0 0 112 38 0} {14 42 56 38 0} {18 38 18 76 0} {7 8 9 126 0}
> ==== grid-16.13 FAILED
>
> ==== grid-16.14 layout span FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 110 -height 20
>     frame .f2 -width 38 -height 20
>     frame .f3 -width 150 -height 20
>     grid .f1 - - .f2
>     grid .f3 - - -
>     set res {}
>     foreach w {{0 1 0 0} {0 0 1 0} {1 3 4 0} {1 2 1 3} {1 1 1 12}} {
>     for {set c 0} {$c < 4} {incr c} {
>         grid columnconfigure . $c -weight [lindex $w $c]
>     }
>     update
>     set res2 {}
>     for {set c 0} {$c <= 4} {incr c} {
>         lappend res2 [lindex [grid bbox . $c 0] 2]
>     }
>     lappend res $res2
>     }
>     return $res
>
> ---- Result was:
> {0 138 0 38 0} {0 0 138 38 0} {17 52 69 38 0} {30 63 31 52 0} {37 39 39 61 0}
> ---- Result should have been (exact matching):
> {0 112 0 38 0} {0 0 112 38 0} {14 42 56 38 0} {27 55 28 40 0} {36 37 37 40 0}
> ==== grid-16.14 FAILED
>
> ==== grid-16.15 layout span FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 24 -height 20
>     frame .f2 -width 38 -height 20
>     frame .f3 -width 150 -height 20
>     grid .f1 - - .f2
>     grid x .f3 - -
>     set res {}
>     foreach w {{0 1 0 0} {0 0 1 0} {1 0 1 0} {0 0 0 0} {1 0 0 6}} {
>     for {set c 0} {$c < 4} {incr c} {
>         grid columnconfigure . $c -weight [lindex $w $c]
>     }
>     update
>     set res2 {}
>     for {set c 0} {$c <= 4} {incr c} {
>         lappend res2 [lindex [grid bbox . $c 0] 2]
>     }
>     lappend res $res2
>     }
>     return $res
>
> ---- Result was:
> {0 138 0 38 0} {0 0 138 38 0} {13 0 125 38 0} {0 37 37 76 0} {3 12 12 149 0}
> ---- Result should have been (exact matching):
> {0 112 0 38 0} {0 0 112 38 0} {0 0 112 38 0} {0 37 37 76 0} {0 12 12 126 0}
> ==== grid-16.15 FAILED
>
> ==== grid-16.16 layout span FAILED
> ==== Contents of test case:
>
>     frame .f1 -width 64 -height 20
>     frame .f2 -width 38 -height 20
>     frame .f3 -width 150 -height 20
>     frame .f4 -width 15 -height 20
>     frame .f5 -width 18 -height 20
>     frame .f6 -width 20 -height 20
>     grid .f1 - x .f2
>     grid .f3 - - -
>     grid .f4 .f5 .f6
>     set res {}
>     foreach w {{1 1 5 1} {0 0 1 0} {1 3 4 0} {1 2 1 2} {1 1 1 12}} {
>     for {set c 0} {$c < 4} {incr c} {
>         grid columnconfigure . $c -weight [lindex $w $c]
>     }
>     update
>     set res2 {}
>     for {set c 0} {$c <= 4} {incr c} {
>         lappend res2 [lindex [grid bbox . $c 0] 2]
>     }
>     lappend res $res2
>     }
>     return $res
>
> ---- Result was:
> {33 37 59 47 0} {30 34 74 38 0} {25 52 61 38 0} {29 48 33 66 0} {31 36 24 85 0}
> ---- Result should have been (exact matching):
> {30 34 43 43 0} {30 34 48 38 0} {22 42 48 38 0} {25 39 29 57 0} {30 34 22 64 0}
> ==== grid-16.16 FAILED
>
> ==== grid-18.2 test support for minreqsize FAILED
> ==== Contents of test case:
>
>     toplevel .pack
>     wm geometry .pack {}
>     frame .pack.l -width 150 -height 100
>     labelframe .pack.lf -labelwidget .pack.l
>     pack .pack.lf -fill both -expand 1
>     frame .pack.lf.f -width 20 -height 25
>     grid .pack.lf.f
>     update
>     set res [list [winfo geometry .pack.lf]]
>     .pack.lf configure -labelanchor ws
>     update
>     lappend res [winfo geometry .pack.lf]
>     destroy .pack
>     return $res
>
> ---- Result was:
> 176x127+0+0 176x112+0+0
> ---- Result should have been (exact matching):
> 162x127+0+0 172x112+0+0
> ==== grid-18.2 FAILED
>
> ==== pack-19.2 test support for minreqsize FAILED
> ==== Contents of test case:
>
>     wm geometry .pack {}
>     frame .pack.l -width 150 -height 100
>     labelframe .pack.lf -labelwidget .pack.l
>     pack .pack.lf -fill both -expand 1
>     frame .pack.lf.f -width 20 -height 25
>     pack .pack.lf.f
>     update
>     set res [list [winfo geometry .pack.lf]]
>     .pack.lf configure -labelanchor ws
>     update
>     lappend res [winfo geometry .pack.lf]
>
> ---- Result was:
> 176x127+0+0 176x112+0+0
> ---- Result should have been (exact matching):
> 162x127+0+0 172x112+0+0
> ==== pack-19.2 FAILED
>
> ==== scrollbar-3.35 ScrollbarWidgetCmd procedure, "fraction" option FAILED
> ==== Contents of test case:
>
>     format {%.6g} [.s fraction 4 21]
>
> ---- Result was:
> 0
> ---- Result should have been (exact matching):
> -0.0340136
> ==== scrollbar-3.35 FAILED
>
> ==== scrollbar-3.36 ScrollbarWidgetCmd procedure, "fraction" option FAILED
> ==== Contents of test case:
>
>     format {%.6g} [.s fraction 4 179]
>
> ---- Result was:
> 1
> ---- Result should have been (exact matching):
> 1.04082
> ==== scrollbar-3.36 FAILED
>
> ==== scrollbar-3.38 ScrollbarWidgetCmd procedure, "fraction" option FAILED
> ==== Contents of test case:
>
>     format {%.6g} [.s fraction 4 178]
>
> ---- Result was:
> 1
> ---- Result should have been (exact matching):
> 1.03401
> ==== scrollbar-3.38 FAILED
>
> ==== scrollbar-6.27 ScrollbarPosition procedure FAILED
> ==== Contents of test case:
>
>     .s identify [expr {[winfo width .s] / 2}] [expr {int(.4 / [.s delta 0 1])
>                          + [testmetrics cyvscroll .s]}]
>
> ---- Result was:
> slider
> ---- Result should have been (exact matching):
> trough2
> ==== scrollbar-6.27 FAILED
>
> ==== textImage-4.2 alignment checking - baseline FAILED
> ==== Contents of test case:
>
>     catch {
>     image create photo small -width 5 -height 5
>     small put red -to 0 0 4 4
>     image create photo large -width 50 -height 50
>     large put green -to 0 0 50 50
>     }
>     font create test_font2 -size 5
>     text .t -font test_font2 -bd 0 -highlightthickness 0 -padx 0 -pady 0
>     pack .t
>     .t image create end -image large
>     .t image create end -image small -align baseline
>     .t insert end test
>     update
>     # Sizes larger than 25 can be too big and lead to a negative 'norm',
>     # at least on Windows XP with certain settings.
>     foreach size {10 15 20 25} {
>     font configure test_font2 -size $size
>     array set Metrics [font metrics test_font2]
>     update  ; # services the idle "TheWorldHasChanged" event, queues "TkWorldChanged" events
>     update  ; # services the queued "TkWorldChanged" events
>     foreach {x y w h} [.t bbox small] {}
>     set norm [expr {
>         (([image height large] - $Metrics(-linespace))/2
>         + $Metrics(-ascent) - [image height small] - $y)
>     }]
>     lappend result "$size $norm"
>     }
>     return $result
>
> ---- Result was:
> {10 0} {15 0} {20 0} {25 -4}
> ---- Result should have been (exact matching):
> {10 0} {15 0} {20 0} {25 0}
> ==== textImage-4.2 FAILED
>
> ==== winDialog-5.16 GetFileName: parent FAILED
> ==== Contents of test case:
>
> #        case FILE_PARENT:
>
>     toplevel .t
>     set x 0
>     testDialog launch {tk_getOpenFile -parent .t -title Parent; set x 1}
>     testDialog onDisplay {
>     destroy .t
>     }
>     return $x
>
> ---- Result was:
> 0
> ---- Result should have been (exact matching):
> 1
> ==== winDialog-5.16 FAILED
>
> ==== winWm-2.4 TkpWmSetState FAILED
> ==== Contents of test case:
>
>     toplevel .t
>     wm geometry .t 150x50+10+10
>     update
>     lappend result [list [wm state .t] [wm geometry .t]]
>     wm iconify .t
>     update
>     lappend result [list [wm state .t] [wm geometry .t]]
>     wm geometry .t 200x50+10+10
>     update
>     lappend result [list [wm state .t] [wm geometry .t]]
>     wm deiconify .t
>     update
>     lappend result [list [wm state .t] [wm geometry .t]]
>
> ---- Result was:
> {normal 176x50+10+10} {iconic 176x50+10+10} {iconic 176x50+10+10} {normal 200x50+10+10}
> ---- Result should have been (exact matching):
> {normal 150x50+10+10} {iconic 150x50+10+10} {iconic 150x50+10+10} {normal 200x50+10+10}
> ==== winWm-2.4 FAILED
>
> ==== winWm-5.1 UpdateGeometryInfo: menu resizing FAILED
> ==== Contents of test case:
>
>     toplevel .t
>     frame .t.f -width 150 -height 50 -background red
>     pack .t.f
>     update
>     set result [winfo height .t]
>     menu .t.m
>     .t.m add command -label foo
>     .t configure -menu .t.m
>     update
>     lappend result [winfo height .t]
>     .t.m add command -label "thisisreallylong"
>     .t.m add command -label "thisisreallylong"
>     update
>     lappend result [winfo height .t]
>
> ---- Result was:
> 50 50 0
> ---- Result should have been (exact matching):
> 50 50 31
> ==== winWm-5.1 FAILED
>
> ==== wm-geometry-2.1 setting values FAILED
> ==== Contents of test case:
>
>     wm geometry .t 150x150+50+50
>     update
>     set result [wm geometry .t]
>     wm geometry .t {}
>     update
>     return [list $result [string equal [wm geometry .t] $result]]
>
> ---- Result was:
> 176x150+50+50 0
> ---- Result should have been (glob matching):
> 150x150+*+* 0
> ==== wm-geometry-2.1 FAILED
>
> Sorry,
> Harald
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core