tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] TIP 733: Add accessibility/screen reader support to Tk

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

Hi,
I can test your code but you'll need to teach me a little bit what to test
I don't do any voiceOver on my machine or things like that...
so if you tell me what to test and how to test, I can.

++

Le ven. 3 oct. 2025 à 17:55, Kevin Walzer <kw...@co...> a écrit :

> Hi folks,
>
> Just a follow-up request for feedback on this TIP. Jan has done a bit of
> cleanup of my code (thanks Jan!) and I’ve had a bit of user feedback from
> the Python/Tkinter community. But I was hoping to see a bit of discussion
> before calling for a vote.
>
> Thanks!
>
> Kevin
>
> > On Sep 24, 2025, at 10:15 PM, Kevin Walzer <kw...@co...> wrote:
> >
> > Hi all,
> >
> > After 18 months of work, I am ready to invite review and testing of TIP
> 733, adding accessibility/screen reader support to Tk:
> https://core.tcl-lang.org/tips/doc/trunk/tip/733.md. This TIP proposes to
> provide out-of-the-box accessibility in Tk on all three major platforms -
> X11, Windows and macOS. There is a detailed API for customization, but the
> design of the tk accessible command set is intended to make accessibility
> "just work" with little effort required by the developer.
> >
> > This feature has long been requested in Tk - I found mailing list and
> Wiki entries going back two decades - but no one has implemented it. It's
> been a long-standing wish of mine to tackle this project, but I did not
> feel capable of completing the project until the past year because of its
> complexity. My experience level, understanding of Tk and various platform
> API's, and the emergence of new developer tools have made it possible for
> me to finally take this on.
> >
> > The goal is to integrate this new command set into Tk 9.1, and I hope I
> have completed this project draft in time for consideration. Because this
> is a large addition to Tk, I am not looking for a rapid TIP process - I'd
> love feedback and, especially, suggestions (and code to implement suggested
> changes if possible).
> >
> > Looking forward to your feedback.
> >
> > Thanks,
> >
> > Kevin
> >
> >
> >
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] TIP 733: Add accessibility/screen reader support to Tk

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

Hi folks,

Just a follow-up request for feedback on this TIP. Jan has done a bit of cleanup of my code (thanks Jan!) and I’ve had a bit of user feedback from the Python/Tkinter community. But I was hoping to see a bit of discussion before calling for a vote. 

Thanks!

Kevin

> On Sep 24, 2025, at 10:15 PM, Kevin Walzer <kw...@co...> wrote:
> 
> Hi all,
> 
> After 18 months of work, I am ready to invite review and testing of TIP 733, adding accessibility/screen reader support to Tk: https://core.tcl-lang.org/tips/doc/trunk/tip/733.md. This TIP proposes to provide out-of-the-box accessibility in Tk on all three major platforms - X11, Windows and macOS. There is a detailed API for customization, but the design of the tk accessible command set is intended to make accessibility "just work" with little effort required by the developer.
> 
> This feature has long been requested in Tk - I found mailing list and Wiki entries going back two decades - but no one has implemented it. It's been a long-standing wish of mine to tackle this project, but I did not feel capable of completing the project until the past year because of its complexity. My experience level, understanding of Tk and various platform API's, and the emergence of new developer tools have made it possible for me to finally take this on.
> 
> The goal is to integrate this new command set into Tk 9.1, and I hope I have completed this project draft in time for consideration. Because this is a large addition to Tk, I am not looking for a rapid TIP process - I'd love feedback and, especially, suggestions (and code to implement suggested changes if possible).
> 
> Looking forward to your feedback.
> 
> Thanks,
> 
> Kevin
> 
> 
> 

Re: [TCLCORE] Reminder: Voting on TIPs 727 and 729

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

TIP 729: YES

> On Oct 3, 2025, at 7:02 AM, Csaba Nemethi <csa...@t-...> wrote:
> 
> This is just to remind you that:
> 
> - The voting on TIP 727 (Add a ttk::toggleswitch widget to the core) will end tomorrow (Sunday) at 24:00 UTC.
> 
>    https://core.tcl-lang.org/tips/doc/trunk/tip/727.md
> 
> - The voting on TIP 729 (Add a tk attribtable command to the core) is in progress and will end on next Friday at 24:00 UTC.
> 
>    https://core.tcl-lang.org/tips/doc/trunk/tip/729.md
> 
> Best regards,
> 
> Csaba
> 
> --
> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
> 
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] Tk project simplify_test_file_init: invitation for final review

[Erik L. <el...@xs...>]

L.S.

The Tk project "simplify_test_file_init" is ready for a final review,
a review leading up to a merge into the target branches trunk and core-9-0 branch.

The primary goal of the project is to simplify the initialization of test files.

A summary of the project's results is appended to this message.

I'm welcoming comments from maintainers, TCT-members and other knowledgeable
developers frequenting this mailing list, especially those who are concerned
with Tk. The project's ticket holds further useful information for reviewers:

     https://core.tcl-lang.org/tk/tktview/4f9946f4f3

I'm asking that you direct your response to this mailing list's thread, or to
the project's ticket before Monday, October 13, 12PM UTC.

Of course, I'm prepared to provide clarification where needed.

Thanks for your attention,
Erik Leunissen.
--

Summary of project results
--------------------------
* Replace the convoluted -loadfile/loadTestedCommands mechanism with a simple,
   straight forward source command.
* Streamline code in main.tcl, amongst others:
   - add utility proc "resetWindows" to testutils domain "generic".
   - removed code that is never executed
   - work around an issue regarding "winfo interps", that formed an obstacle for
     simplification/cleanup. See ticket: https://core.tcl-lang.org/tk/tktview/280189e35d
* Restore support for the tcltest option "-singleproc 0", keeping "-singleproc 1" as the default.
* Add some simple command line handling for invocation of the Tk test suite.
   Write error message to stderr and exit when:
   • passing invalid options or an uneven number of arguments
   • passing options that the Tk test suite sets for itself
   Remove option "-geometry +0+0" from the test suite invocation by unix/Makefie.in
--

Re: [TCLCORE] Reminder: Voting on TIPs 727 and 729

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

727: YES (already voted)
729: YES

-----Original Message-----
From: Csaba Nemethi <csa...@t-...> 
Sent: Friday, October 3, 2025 4:32 PM
To: tcl...@li...
Subject: [TCLCORE] Reminder: Voting on TIPs 727 and 729

This is just to remind you that:

- The voting on TIP 727 (Add a ttk::toggleswitch widget to the core) 
will end tomorrow (Sunday) at 24:00 UTC.

     https://core.tcl-lang.org/tips/doc/trunk/tip/727.md

- The voting on TIP 729 (Add a tk attribtable command to the core) is in 
progress and will end on next Friday at 24:00 UTC.

     https://core.tcl-lang.org/tips/doc/trunk/tip/729.md

Best regards,

Csaba

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...



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

[TCLCORE] Reminder: Voting on TIPs 727 and 729

[Csaba N. <csa...@t-...>]

This is just to remind you that:

- The voting on TIP 727 (Add a ttk::toggleswitch widget to the core) 
will end tomorrow (Sunday) at 24:00 UTC.

     https://core.tcl-lang.org/tips/doc/trunk/tip/727.md

- The voting on TIP 729 (Add a tk attribtable command to the core) is in 
progress and will end on next Friday at 24:00 UTC.

     https://core.tcl-lang.org/tips/doc/trunk/tip/729.md

Best regards,

Csaba

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

[TCLCORE] CFV: TIP 729

[Csaba N. <csa...@t-...>]

Attn. TCT members,

This is a CFV for TIP 729: Add a tk attribtable command to the core.

     https://core.tcl-lang.org/tips/doc/trunk/tip/729.md

After long, intensive, and very fruitful discussions with Emiliano and a 
few other members of the Community, with several iterations regarding 
the specification and implementation of the tk attribtable command, it 
is now time to vote on the inclusion of this command in the Tk core.

Please send your votes to this list until 2025-10-11 00:00 UTC.

Harald voted already with "yes" on 2025-09-09.

Best regards,

Csaba

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

[TCLCORE] Replying to Andrew C.'s recent posts

[Christopher C. <chr...@gm...>]

Hello Andrew,

I am just a Tk Aqua contributor (I can't answer authoritatively as Tk Aqua maintainers Marc Culler and Kevin Walzer can), but this is still an interesting question.

I think an approach which might work in the short term would be to create a pixmap, get the CGContext for the pixmap using Tk_MacOSXGetCGContextForDrawable(), do the necessary drawing into the pixmap's CGContext, then use XCopyArea() to copy the pixmap into the widget. I am aware there are currently some issues with e.g. XCopyArea(), however I am not aware what could be causing Tk_MacOSXGetCGContextForDrawable() to segfault in your case.

While there is currently not any intention to expose pixmap or window CGContexts to extensions, having a useful API to access them should not be too difficult either. Also be aware that Tk Aqua 8.6 will soon be end-of-life, and Tk Aqua 9.0 will probably accommodate your use case better anyway, especially if a new or revised API is needed, or if you want Retina-aware drawing directly into a window rather than through a pixmap.

If you can share your project code, I would be interested in taking a look or giving it a try.

Hope this helps

Christopher




Links to Andrew's messages and StackOverflow question, for reference:

https://sourceforge.net/p/tcl/mailman/tcl-core/thread/CAOWyT84LoZkW%2BNENLr3Ppn7-oHmhf6V-XgT7uoQ5hX%3D8-CWREw%40mail.gmail.com/

https://sourceforge.net/p/tcl/mailman/tcl-core/thread/818dac7a-08cb-4df6-b1e9-856b2b6d39c7%40gmail.com/#msg59239381

https://stackoverflow.com/q/79774074/4896937

Re: [TCLCORE] CFV: TIP 727

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

TIP #727        YES

- Marc

On Thu, Sep 25, 2025 at 12:13 PM Csaba Nemethi <csa...@t-...>
wrote:

> Attn. TCT members,
>
> This is a CFV for TIP 727: Add a ttk::toggleswitch widget to the core.
>
>      https://core.tcl-lang.org/tips/doc/trunk/tip/727.md
>
> Please send your votes to this list until 2025-10-05 00:00 UTC.
>
> Harald sent already his "yes" vote on 2025-09-09.
>
> Best regards,
>
> Csaba
>
> --
> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
>
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] CFV: TIP 727

[Andreas K. <and...@gm...>]

> Attn. TCT members,
> 
> This is a CFV for TIP 727: Add a ttk::toggleswitch widget to the core.
> 
>      https://core.tcl-lang.org/tips/doc/trunk/tip/727.md

TIP #727	YES

-- 
Happy Tcling,
	Andreas Kupries <and...@gm...>
			<https://core.tcl-lang.org/akupries/>
			<https://akupries.tclers.tk/>
	Developer @	SUSE Software Solutions Germany GmbH
-------------------------------------------------------------------------------

Re: [TCLCORE] TIP 733: Add accessibility/screen reader support to Tk

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

Hi Mike,

I've added a call that explicitly pulls the preferred language 
configuration from the system preferences - that *should* prevent the 
double-reading. Let me know how it works for you.

Thanks,

Kevin

On 9/28/25 8:08 AM, Kevin Walzer wrote:
>
> Hi Mike,
>
> Thanks for reaching out. I'm glad that the Python team has taken 
> notice, and I greatly appreciate the feedback. Adding the Tcl Core 
> list back in because this discussion definitely belongs there.
>
> I'm not sure about VoiceOver speaking text twice, once in English and 
> one in the localized text of the specific machine. Tk doesn't use 
> Apple's localization API for the most part so this may or may not be 
> something we can address. I'll do some research on that.
>
> However, Accessibility Inspector is working for me per the screenshot 
> from the latest Xcode tools on Taho. You'll see that the selected 
> highlighted text is correctly show to be a child of the "Label 
> Demonstration" window. The design of the accessibility on macOS 
> involves a fairly flat hierarchy - things like frames and other 
> containers are ignored. In most cases, widgets are children of the 
> toplevel windows's NSView (TKContentView, specifically). So I believe 
> things are working as designed. I'd be interested to see a screenshot 
> that shows what you are seeing.
>
> Thanks again!
> --Kevin
>
>
> On 9/28/25 4:25 AM, Mike Hommey wrote:
>> Hi Kevin,
>>
>> I'm replying off-list because I'm not sure whether this is fully
>> relevant there.
>>
>> I was at a sprint at Pycon JP 2025, on a team focused on accessibility
>> and one of the topics we covered was python's tkinter problems with
>> a11y.
>>
>> By chance, you submitted your branch only a few days before the event,
>> which was very timely. I managed to build your branch and a cpython
>> using it, and as a result, got somewhat better coverage with voiceover
>> on mac.
>>
>> However, for some reason, Xcode accessibility inspector is unable to see
>> the hierarchy at all. I originally thought that might have been related
>> to the cpython code, but it turns out the same problem is reproducible
>> with the tk widget demos.
>>
>> I figured I should make you aware of the issue. This is with macos
>> 15.6.1 and Xcode 16.1. Please tell me if you need me to run some more
>> tests or whatever might help you debug the issue.
>>
>> Voiceover does work on the widget demos too, but for some reason, it
>> reads the introduction text from the individual tests twice: once with
>> a Japanese accent, and once with an English accent. (macos is configured
>> with Japanese as its main language)
>>
>> Cheers,
>>
>> Mike

Re: [TCLCORE] Questions about Tcl{Get, Set}ProcessGlobalValue functions

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

Thanks Sergey, that corroborates what I kind of surmised. The doubt I have is what you mention at the bottom – the point of conversion between external and internal does not matter. Once the conversion is done, so is the damage (in the case the assumed system encoding was wrong). But shall wait for Don, I’m sure there was a good reason at the time that may still hold. It’s not the kind of thing that can be an inadvertent error.

 

/Ashok

 

From: Dipl. Ing. Sergey G. Brester <se...@us...> 
Sent: Thursday, September 25, 2025 5:54 PM
To: apn...@ya...
Cc: tcl...@li...
Subject: Re: [TCLCORE] Questions about Tcl{Get, Set}ProcessGlobalValue functions

 

IIRC, the encoding argument was added some day to satisfy the needs of TclpFindExecutable (for conversion of native executable name), where previously it was privilege of the TclInitProcessGlobalValueProc handler, which returned string and encoding on demand, e. g. used for TclpInitLibraryPath, InitializeEncodingSearchPath etc.
Blame shows [353036774ea2c180] <https://core.tcl-lang.org/tcl/info/353036774ea2c180>  where it was introduced initially.

Few additional points:

1.    Besides TclSetProcessGlobalValue there is also init-handlers TclInitProcessGlobalValueProc that may statically register getter for the PGV.

2.    The conversion with Tcl_UtfToExternal by set was added later in [5de1d4a68b9118b0] <https://core.tcl-lang.org/tcl/info/5de1d4a68b9118b0>  to fix the bug " <https://core.tcl-lang.org/tcl/info/3fc3287497> TclGetProcessGlobalValue encodes information twice on Windows", 
however in my opinion at a bit "wrong" place (not completely compatible and questionable), but they are internal functions, so never mind.

3.    The value would be converted from/to external using encoding, only if it was set.

4.    The primary purposes (initially) were the conversion on demand if system encoding changes between set and get (especially may be important if encoding dir changes).

I think it is more or less a historic thing which grew with the time and got certain "controversial" fixes (that made an initial idea almost redundant).
But because initial concept was a bit "strange" too, the time point of conversion from/to external doesn't really matter. 
In my opinion, it would be fully correct to retain original value unchanged in global storage if encoding argument were the name of encoding, and not the encoding pointer.

Regards,
Serg.

25.09.2025 11:06, apnmbx-public--- via Tcl-Core wrote:

I have a question about the TclGetProcessGlobalValue / TclSetProcessGlobalValue pair of functions that I hope someone can answer. These functions are supposed to store values or settings that are shared across all threads in the process.

 

TL;DR why do the above functions get/set values using the *system* encoding?

 

As currently implemented, TclSetProcessGlobalValue encodes the Tcl_Obj value passed in using the current system encoding and stores it in a global C struct. It also stores the *original* passed in Tcl_Obj in a thread-local cache so that its internal representation is not lost for that thread’s usage. Use of epochs ensure the stale values are not used.

 

When TclGetProcessGlobalValue is called, the encoded value in the global C struct is decoded using the system encoding and the result is passed back to the caller in a new Tcl_Obj which is also stored in that thread’s cache. If this function is called without TclSetProcessGlobalValue having previous set the value, an initializer function is called which returns the initial value along with encoding used. 

 

The code accounts for the fact that system encoding may change (generally only during initialization when all encodings are not immediately available) by tracking the encodings used and converting appropriately as needed.

 

My question is - what the purpose of this encoding / decoding pair when storing and retrieving values? The passed in values are (effectively) internal modified UTF-8 strings. Why not just store return those? This is not just a question of efficiency but correctness. There are several issues with the current implementation:

 

*   A value being stored may not be representable using the current system encoding. Since the encoding is done using TCL_ENCODING_PROFILE_TCL8, essentially a “corrupted” value is stored in the global struct and returned by 

*   Likewise, there is potential for further corruption for similar reasons when the system encoding changes and the new system encoding does not support additional characters.

*   Further, because the *original* Tcl_Obj remains in the thread that called TclSetProcessGlobalValue, that thread’s perception of the “global” value differs from all other threads (which see the “corrupted” value).

 

This seems broken to me if the whole purpose was to have global values shared across threads. It neither preserves values, nor shares them correctly. From my perspective, the global value should directly reflect he string representation of the Tcl_Obj passed in. It is the responsibility of the caller to ensure the value is correct. Once in Tcl’s internal representation, changes in system encoding should not matter.

 

And yet, because there is all this additional explicit machinery for encoding / decoding that has been added, I believe there was some purpose behind it. If so, what was it?

 

As an aside, I think there are bugs with the sequence of encoding operations as well, e.g. it assumes single byte nul terminators, epochs are checked without any thread synchronization etc. but those are secondary to the questions above.

 

Anybody know the answer to the above?

 

/Ashok 

 

PS The context for all this is TIP 732 – trying to fully understand Tcl initialization.

 

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

Re: [TCLCORE] Pain points as a distro maintainer

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

Stu,

Does this mean you expect or plan for only one Tcl version to be installed on the system since the directories are not version-specific? Or that packages are expected to be built so as to be Tcl8 and 9 compatible, loading (in the case of binary extensions) the appropriate shared library (tclfoo.so vs tcl9foo.so)?

/Ashok

-----Original Message-----
From: Stuart Cassoff <exo...@ya...> 
Sent: Saturday, September 27, 2025 2:09 PM
To: tcl...@li...; 'Pietro Cerutti' <ga...@ga...>; apn...@ya...
Subject: Re: [TCLCORE] Pain points as a distro maintainer

Extension home is /usr/local/lib/tcl.

A Tcl-only extension "foo" will be installed in /usr/local/lib/tcl/foo.
Preferentially, install Tcl-only extensions as Tcl Modules, if possible.

A binary loadable-only extension "foo" (ex. dbus) will be installed in /usr/local/lib/tcl/foo.

For a binary linkable-and-loadable extension "foo" (ex. tdbc),
the pkgIndex.tcl will be installed in /usr/local/lib/tcl/foo,
the .so in /usr/local/lib,
and any .h files in /usr/local/include.

Executables are installed in /usr/local/bin.


Stu



On Thursday, August 21, 2025 at 02:09:00 a.m. EDT, <apn...@ya...> wrote: 





Stu,

That was very helpful for me to wrap my head around Unix installs.

One item that was left out (question for both Stu and Pietro) was where do
third party packages like tcllib, critcl etc. get installed? Note these
packages may have Tcl script libraries, shared libraries as well as
"applications" like critcl. Do they go into a common system directory or a
Tcl version-specific location?

/Ashok

-----Original Message-----
From: Stuart Cassoff via Tcl-Core <tcl...@li...> 
Sent: Tuesday, August 19, 2025 12:14 AM
To: tcl...@li...; Pietro Cerutti <ga...@ga...>
Subject: Re: [TCLCORE] Pain points as a distro maintainer

Hi,

On OpenBSD:

My only real concern would be the Thread extension, which, if not made to
work in 8 and 9, would have to be separate extension: tclthread and
tcl9thread. Not great, not terrible.

Right now, everything 8/9 is as integrated as possible but separated where
necessary.

Tcl/Tk 8.5 and 8.6 are installed under dir names "8.5" and "8.6".

Tcl/Tk 9 will simply be "9". When 9.1 is released, it will replace 9.0.

The paths and dirs for 9 will be similar, but I'll be keeping the older
naming convention for libs and maybe other things, ie: libtk90.so instead of
libtcl9tk90.so.

These are the default auto_path and tm paths:
$ tclsh8.6
% set auto_path
/usr/local/lib/tcl/tcl8.6 /usr/local/lib/tcl
% tcl::tm::path list
/usr/local/lib/tcl/modules/85 /usr/local/lib/tcl/modules/86
/usr/local/lib/tcl/tcl8.6/modules

Here's the packing list for 8.6:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/tcl/8.6/pkg/
PLIST?rev=1.17&content-type=text/plain

Here's a snip of the most important bits of the package readme:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/tcl/8.6/pkg/
README?rev=1.8&content-type=text/plain

Tclsh and Wish
--------------
normally
/usr/local/lib/tclsh, /usr/local/lib/wish
now
/usr/local/bin/tclsh8.6, /usr/local/bin/wish8.6

Library files
-------------
scripts, encoding files, etc.
normally in
/usr/local/lib/tcl8.6, /usr/local/lib/tk8.6
now in
/usr/local/lib/tcl/tcl8.6, /usr/local/lib/tcl/tk8.6

Configuration Files
-------------------
tclConfig.sh, tkConfig.sh
normally in
/usr/local/lib
now in
/usr/local/lib/tcl/tcl8.6, /usr/local/lib/tcl/tk8.6

Header Files
------------
*.h
normally in
/usr/local/include
now in
/usr/local/include/tcl8.6, /usr/local/include/tk8.6

Manual Pages
------------
*.1, *.3, *.n
normally in
/usr/local/man
now in
/usr/local/lib/tcl/tcl8.6/man, /usr/local/lib/tcl/tk8.6/man

Demos
-----
*.tcl, *
normally in
/usr/local/lib/tk8.6/demos
now in
/usr/local/share/examples/tk8.6

Bundled Tcl Modules
-------------------
*.tm
normally in
/usr/local/lib/tcl8/...
now in
/usr/local/lib/tcl/tcl8.6/modules

Tcl Module Paths
----------------
normally
/usr/local/lib/tcl8/...
now
/usr/local/lib/tcl/modules/{85,86}

Manual Page Configuration
=========================
Adding the following lines to /etc/man.conf wil enable man(1)
and related commands can find the Tcl and Tk manual pages.

manpath /usr/local/lib/tcl/tcl8.6/man
manpath /usr/local/lib/tcl/tk8.6/man


Stu


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

Re: [TCLCORE] TIP 733: Add accessibility/screen reader support to Tk

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

Hi Mike,

Thanks for reaching out. I'm glad that the Python team has taken notice, 
and I greatly appreciate the feedback. Adding the Tcl Core list back in 
because this discussion definitely belongs there.

I'm not sure about VoiceOver speaking text twice, once in English and 
one in the localized text of the specific machine. Tk doesn't use 
Apple's localization API for the most part so this may or may not be 
something we can address. I'll do some research on that.

However, Accessibility Inspector is working for me per the screenshot 
from the latest Xcode tools on Taho. You'll see that the selected 
highlighted text is correctly show to be a child of the "Label 
Demonstration" window. The design of the accessibility on macOS involves 
a fairly flat hierarchy - things like frames and other containers are 
ignored. In most cases, widgets are children of the toplevel windows's 
NSView (TKContentView, specifically). So I believe things are working as 
designed. I'd be interested to see a screenshot that shows what you are 
seeing.

Thanks again!
--Kevin


On 9/28/25 4:25 AM, Mike Hommey wrote:
> Hi Kevin,
>
> I'm replying off-list because I'm not sure whether this is fully
> relevant there.
>
> I was at a sprint at Pycon JP 2025, on a team focused on accessibility
> and one of the topics we covered was python's tkinter problems with
> a11y.
>
> By chance, you submitted your branch only a few days before the event,
> which was very timely. I managed to build your branch and a cpython
> using it, and as a result, got somewhat better coverage with voiceover
> on mac.
>
> However, for some reason, Xcode accessibility inspector is unable to see
> the hierarchy at all. I originally thought that might have been related
> to the cpython code, but it turns out the same problem is reproducible
> with the tk widget demos.
>
> I figured I should make you aware of the issue. This is with macos
> 15.6.1 and Xcode 16.1. Please tell me if you need me to run some more
> tests or whatever might help you debug the issue.
>
> Voiceover does work on the widget demos too, but for some reason, it
> reads the introduction text from the individual tests twice: once with
> a Japanese accent, and once with an English accent. (macos is configured
> with Japanese as its main language)
>
> Cheers,
>
> Mike

Re: [TCLCORE] About TIPs 727 and 729

[Emiliano <emi...@gm...>]

On Sat, 27 Sep 2025 15:11:04 +0200
Csaba Nemethi <csa...@t-...> wrote:

[...]
> While this is correct, for all but two of the supported subcommands it 
> is important to have the error message in interp, because of the "return 
> TCL_ERROR".

You are right! I had a brain fart, sorry.

As for the other comments, thanks for taking the time to explain them.
I'm completely fine with the current implementation. I have just one
pet project that uses tkcargo but now I can use the core implementation.

Thanks again for your work !!

Regards

-- 
Emiliano <emi...@gm...>

Re: [TCLCORE] About TIPs 727 and 729

[Csaba N. <csa...@t-...>]

Hi Emiliano,

Many thanks for your quick feedback!  See my embedded comments below.


Am 27.09.25 um 02:07 schrieb Emiliano:
> On Fri, 26 Sep 2025 19:53:23 +0200
> Csaba Nemethi <csa...@t-...> wrote:
> 
>> Work completed.  Thanks to Emiliano for his high-quality tkcargo
>> implementation, which the tk attribtable code is based on!
>>
>> Best regards,
>>
>> Csaba
> 
> Great work! Thanks!
> 
> I have a few remarks, none of them critical.
> 
> In the attribtable man page, I think the final remark about the entries
> in the tables being cleared when the widget is destroyed should be before
> the subcommands description. After all, this is the main selling point of
> the functionality, IMO.
> 

Good suggestion!  Done.

> The error result raised by Tcl_WrongNumArgs here
> https://core.tcl-lang.org/tk/file?ci=6a9c2f6168e06a30&name=generic%2FtkCmds.c&ln=802
> is not the same as other tk commands, like the widget themselves. While I have
> no strong preference, I apply the "when in Rome, do as the romans do"
> principle. Example using entry:
> % entry .e
> .e
> % .e
> wrong # args: should be ".e option ?arg ...?"
> % .e asd
> bad option "asd": must be bbox, cget, configure, delete, get, icursor, index, insert, scan, selection, validate, or xview
> 

Instead of the generic word "subcommand" I have written 
"set|get|unset|clear|exists|names|pathnames" because this in addition 
enumerates the supported subcommands.  Compare this to the following 
examples:

% place
wrong # args: should be "place option|pathName args"

% canvas .c; .c yview scroll
wrong # args: should be ".c yview moveto|scroll args"

The "..." in the error message stands for "zero or more additional 
arguments".  An alternative form would be "?arg ...?" (like in the 
tkcargo code), but this would read: The subcommand can *optionally* be 
followed by at least one argument.  However, this is not quite accurate, 
because the "pathnames" subcommand mustn't be followed by anything, 
while all the others expect at least one argument.  Now I have replaced 
the "..." with "args", which suits both cases and is more familiar to 
the users, since in Tcl it means "zero or more arguments".

> In the call to Tk_NameToWindow here
> https://core.tcl-lang.org/tk/file?ci=6a9c2f6168e06a30&name=generic%2FtkCmds.c&ln=813
> the interp argument can be NULL, making the following call to
> Tcl_ResetResult unnecessary. This is not clear in the docs, and I think it
> should be fixed there, making it explicit.
> 

While this is correct, for all but two of the supported subcommands it 
is important to have the error message in interp, because of the "return 
TCL_ERROR".

> Finally, there is an interaction between "unset" and "pathnames". When all
> the names are "unset" and the attributes dictionary becomes empty, the
> widget is not shown in "pathnames", as if "clear" was called on it.

This was a deliberate decision from me, also because of the manual.  It 
is just an *internal* design decision that the attributes are kept in 
dictionaries.  From the user's point of view it should make no 
difference whether for a given widget the table contains no dictionary 
or an empty one instead.  With my version the documentation is fully in 
sync with the code.

BTW: We have the same interaction between "unset" and "exists" without 
the optional "name" argument.

> This has the advantage that further "set" calls are faster, and the
> disadvantage that AttribTableDestroyHandler keep being called for other
> events that match StructureNotifyMask, so it's a tradeoff decision to remove
> the entry or not. My (mild) preference would be to remove it, but it's
> fine as it is.

Your tkcargo implementation doesn't remove the entry either when the 
dictionary gets empty due to "unset" invocations with at least one name 
argument.  (Instead of tkcargo's "unset" subcommand we now have an 
"unset" and a "clear", as suggested by Ashok.)

> 
> Again, thanks for your time and patience!
> 
> Regards

Best regards,

Csaba

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

Re: [TCLCORE] About TIPs 727 and 729

[Csaba N. <csa...@t-...>]

Hi Stu,

Thanks for your feedback!

There have been negative comments about using the word "cargo" from 
Marc, Steve, Emiliano, and (indirectly) Ashok.  I have been using the 
term "attribute" in all my mega-widgets for decades now, and I 
personally like it more than the word "cargo".  Now there seems to be a 
decision in favor of "attribute" and "tk attribtable", sorry!

Best regards,

Csaba


Am 27.09.25 um 10:57 schrieb Stuart Cassoff via Tcl-Core:
> I think "tkcargo" is fine for a name, and wouldn't be concerned about Rust.
> It (cargo) is a term/name that's been used for that sort of thing for a long time, in many places.
> We should feel free to name things as we want and not feel constrained by others.
> 
> My CDN $0.02.
> 
> 
> Stu
> 
> ps. For further bikeshedding, "proptable", "props", and "properties" are shorter.
> 
> 
> On Friday, September 26, 2025 at 01:53:44 p.m. EDT, Csaba Nemethi <csa...@t-...> wrote:
> 
> 
> 
> 
> 
> Work completed.  Thanks to Emiliano for his high-quality tkcargo
> implementation, which the tk attribtable code is based on!
> 
> Best regards,
> 
> Csaba
> 
> 
> Am 26.09.25 um 02:48 schrieb Emiliano:
>> On Thu, 25 Sep 2025 18:27:21 +0200
>> Csaba Nemethi <csa...@t-...> wrote:
>>
>>> Hi Emiliano, hi Eric,
>>>
>>> I just want to let you know that I have started to replace the
>>> implementation of the "tk attribtable" command using Tcl scripts with
>>> one written entirely in C.  Thanks to Emiliano's tkcargo package, from
>>> which I can reuse several ideas and code fragments, I am making good
>>> progress (the set, get, names, and pathnames subcommands already work as
>>> expected), but it will take a few more days to get everything ready.
>>
>> Great. Thanks !! If you need any help, please feel free to contact me.
>> And, if you find any way to make things faster[1], please do.
>>
>> Thanks again for your time and patience!!
>>
>> Regards
>>
> 

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

Re: [TCLCORE] About TIPs 727 and 729

[Stuart C. <exo...@ya...>]

I think "tkcargo" is fine for a name, and wouldn't be concerned about Rust.
It (cargo) is a term/name that's been used for that sort of thing for a long time, in many places.
We should feel free to name things as we want and not feel constrained by others.

My CDN $0.02.


Stu

ps. For further bikeshedding, "proptable", "props", and "properties" are shorter.


On Friday, September 26, 2025 at 01:53:44 p.m. EDT, Csaba Nemethi <csa...@t-...> wrote: 





Work completed.  Thanks to Emiliano for his high-quality tkcargo 
implementation, which the tk attribtable code is based on!

Best regards,

Csaba


Am 26.09.25 um 02:48 schrieb Emiliano:
> On Thu, 25 Sep 2025 18:27:21 +0200
> Csaba Nemethi <csa...@t-...> wrote:
> 
>> Hi Emiliano, hi Eric,
>>
>> I just want to let you know that I have started to replace the
>> implementation of the "tk attribtable" command using Tcl scripts with
>> one written entirely in C.  Thanks to Emiliano's tkcargo package, from
>> which I can reuse several ideas and code fragments, I am making good
>> progress (the set, get, names, and pathnames subcommands already work as
>> expected), but it will take a few more days to get everything ready.
> 
> Great. Thanks !! If you need any help, please feel free to contact me.
> And, if you find any way to make things faster[1], please do.
> 
> Thanks again for your time and patience!!
> 
> Regards
> 

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...




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

Re: [TCLCORE] Pain points as a distro maintainer

[Stuart C. <exo...@ya...>]

Extension home is /usr/local/lib/tcl.

A Tcl-only extension "foo" will be installed in /usr/local/lib/tcl/foo.
Preferentially, install Tcl-only extensions as Tcl Modules, if possible.

A binary loadable-only extension "foo" (ex. dbus) will be installed in /usr/local/lib/tcl/foo.

For a binary linkable-and-loadable extension "foo" (ex. tdbc),
the pkgIndex.tcl will be installed in /usr/local/lib/tcl/foo,
the .so in /usr/local/lib,
and any .h files in /usr/local/include.

Executables are installed in /usr/local/bin.


Stu



On Thursday, August 21, 2025 at 02:09:00 a.m. EDT, <apn...@ya...> wrote: 





Stu,

That was very helpful for me to wrap my head around Unix installs.

One item that was left out (question for both Stu and Pietro) was where do
third party packages like tcllib, critcl etc. get installed? Note these
packages may have Tcl script libraries, shared libraries as well as
"applications" like critcl. Do they go into a common system directory or a
Tcl version-specific location?

/Ashok

-----Original Message-----
From: Stuart Cassoff via Tcl-Core <tcl...@li...> 
Sent: Tuesday, August 19, 2025 12:14 AM
To: tcl...@li...; Pietro Cerutti <ga...@ga...>
Subject: Re: [TCLCORE] Pain points as a distro maintainer

Hi,

On OpenBSD:

My only real concern would be the Thread extension, which, if not made to
work in 8 and 9, would have to be separate extension: tclthread and
tcl9thread. Not great, not terrible.

Right now, everything 8/9 is as integrated as possible but separated where
necessary.

Tcl/Tk 8.5 and 8.6 are installed under dir names "8.5" and "8.6".

Tcl/Tk 9 will simply be "9". When 9.1 is released, it will replace 9.0.

The paths and dirs for 9 will be similar, but I'll be keeping the older
naming convention for libs and maybe other things, ie: libtk90.so instead of
libtcl9tk90.so.

These are the default auto_path and tm paths:
$ tclsh8.6
% set auto_path
/usr/local/lib/tcl/tcl8.6 /usr/local/lib/tcl
% tcl::tm::path list
/usr/local/lib/tcl/modules/85 /usr/local/lib/tcl/modules/86
/usr/local/lib/tcl/tcl8.6/modules

Here's the packing list for 8.6:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/tcl/8.6/pkg/
PLIST?rev=1.17&content-type=text/plain

Here's a snip of the most important bits of the package readme:
https://cvsweb.openbsd.org/cgi-bin/cvsweb/~checkout~/ports/lang/tcl/8.6/pkg/
README?rev=1.8&content-type=text/plain

Tclsh and Wish
--------------
normally
/usr/local/lib/tclsh, /usr/local/lib/wish
now
/usr/local/bin/tclsh8.6, /usr/local/bin/wish8.6

Library files
-------------
scripts, encoding files, etc.
normally in
/usr/local/lib/tcl8.6, /usr/local/lib/tk8.6
now in
/usr/local/lib/tcl/tcl8.6, /usr/local/lib/tcl/tk8.6

Configuration Files
-------------------
tclConfig.sh, tkConfig.sh
normally in
/usr/local/lib
now in
/usr/local/lib/tcl/tcl8.6, /usr/local/lib/tcl/tk8.6

Header Files
------------
*.h
normally in
/usr/local/include
now in
/usr/local/include/tcl8.6, /usr/local/include/tk8.6

Manual Pages
------------
*.1, *.3, *.n
normally in
/usr/local/man
now in
/usr/local/lib/tcl/tcl8.6/man, /usr/local/lib/tcl/tk8.6/man

Demos
-----
*.tcl, *
normally in
/usr/local/lib/tk8.6/demos
now in
/usr/local/share/examples/tk8.6

Bundled Tcl Modules
-------------------
*.tm
normally in
/usr/local/lib/tcl8/...
now in
/usr/local/lib/tcl/tcl8.6/modules

Tcl Module Paths
----------------
normally
/usr/local/lib/tcl8/...
now
/usr/local/lib/tcl/modules/{85,86}

Manual Page Configuration
=========================
Adding the following lines to /etc/man.conf wil enable man(1)
and related commands can find the Tcl and Tk manual pages.

manpath /usr/local/lib/tcl/tcl8.6/man
manpath /usr/local/lib/tcl/tk8.6/man


Stu


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

[TCLCORE] Looking for help accessing TkMacOSXSetupDrawingContext or equivalent

[Andrew <and...@gm...>]

Hello!

I've been working on a custom Tk widget, but I am struggling to make it work on MacOS, and was wondering if anyone had any thoughts:

In this widget, when the viewpoint changes, a Pixmap is created, drawn on, and pasted into the necessary part of the window. However, in some cases I to use more advanced drawing capabilities than Tk provides, so on MacOS I'm looking to draw on the Pixmap using the Quartz API when needed.

My problem stems from the need to get an associated CGContext for the Pixmap.

Supposedly|Tk_MacOSXGetCGContextForDrawable is how to do this. However, it seems 
to always segfault for me. Interestingly, from what I've been told| on Stack Overflow (thank you Donal!) it is only implemented for Pixmaps though it should theoretically also accept Windows. At any rate, I can't get it to work. Apparently Tk uses|TkMacOSXSetupDrawingContext internally, which (and I could be mistaken) 
looks to be exactly |what I need, but it isn't publicly exposed.

I'm not a MacOS nor a C programmer by trade, so my apologies if I am missing something. If not though, is there a way|TkMacOSXSetupDrawingContext or some similar| functionality could be added to the public API?

Many thanks in advance!
Andrew

Re: [TCLCORE] About TIPs 727 and 729

[Emiliano <emi...@gm...>]

On Fri, 26 Sep 2025 19:53:23 +0200
Csaba Nemethi <csa...@t-...> wrote:

> Work completed.  Thanks to Emiliano for his high-quality tkcargo 
> implementation, which the tk attribtable code is based on!
> 
> Best regards,
> 
> Csaba

Great work! Thanks!

I have a few remarks, none of them critical.

In the attribtable man page, I think the final remark about the entries
in the tables being cleared when the widget is destroyed should be before
the subcommands description. After all, this is the main selling point of
the functionality, IMO.

The error result raised by Tcl_WrongNumArgs here
https://core.tcl-lang.org/tk/file?ci=6a9c2f6168e06a30&name=generic%2FtkCmds.c&ln=802
is not the same as other tk commands, like the widget themselves. While I have
no strong preference, I apply the "when in Rome, do as the romans do"
principle. Example using entry:
% entry .e
.e
% .e
wrong # args: should be ".e option ?arg ...?"
% .e asd
bad option "asd": must be bbox, cget, configure, delete, get, icursor, index, insert, scan, selection, validate, or xview

In the call to Tk_NameToWindow here
https://core.tcl-lang.org/tk/file?ci=6a9c2f6168e06a30&name=generic%2FtkCmds.c&ln=813
the interp argument can be NULL, making the following call to
Tcl_ResetResult unnecessary. This is not clear in the docs, and I think it
should be fixed there, making it explicit.

Finally, there is an interaction between "unset" and "pathnames". When all
the names are "unset" and the attributes dictionary becomes empty, the
widget is not shown in "pathnames", as if "clear" was called on it.
This has the advantage that further "set" calls are faster, and the
disadvantage that AttribTableDestroyHandler keep being called for other
events that match StructureNotifyMask, so it's a tradeoff decision to remove
the entry or not. My (mild) preference would be to remove it, but it's
fine as it is.

Again, thanks for your time and patience!

Regards
-- 
Emiliano <emi...@gm...>

Re: [TCLCORE] About TIPs 727 and 729

[Csaba N. <csa...@t-...>]

Work completed.  Thanks to Emiliano for his high-quality tkcargo 
implementation, which the tk attribtable code is based on!

Best regards,

Csaba


Am 26.09.25 um 02:48 schrieb Emiliano:
> On Thu, 25 Sep 2025 18:27:21 +0200
> Csaba Nemethi <csa...@t-...> wrote:
> 
>> Hi Emiliano, hi Eric,
>>
>> I just want to let you know that I have started to replace the
>> implementation of the "tk attribtable" command using Tcl scripts with
>> one written entirely in C.  Thanks to Emiliano's tkcargo package, from
>> which I can reuse several ideas and code fragments, I am making good
>> progress (the set, get, names, and pathnames subcommands already work as
>> expected), but it will take a few more days to get everything ready.
> 
> Great. Thanks !! If you need any help, please feel free to contact me.
> And, if you find any way to make things faster[1], please do.
> 
> Thanks again for your time and patience!!
> 
> Regards
> 

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...

Re: [TCLCORE] CFV: TIP 727

[Rolf A. <tcl...@po...>]

TIP 727: YES

Csaba Nemethi <csa...@pu...>
writes:
> Attn. TCT members,
>
> This is a CFV for TIP 727: Add a ttk::toggleswitch widget to the core.
>
>     https://core.tcl-lang.org/tips/doc/trunk/tip/727.md
>
> Please send your votes to this list until 2025-10-05 00:00 UTC.
>
> Harald sent already his "yes" vote on 2025-09-09.
>
> Best regards,
>
> Csaba

Re: [TCLCORE] CFV: TIP 727

[Donal F. <don...@ma...>]

TIP 727: YES

Donal.

-------- Original message --------
From: Csaba Nemethi <csa...@t-...>
Date: 25/09/2025 18:13 (GMT+00:00)
To: tcl...@li...
Subject: [TCLCORE] CFV: TIP 727

This is a CFV for TIP 727: Add a ttk::toggleswitch widget to the core.

Re: [TCLCORE] CFV: TIP 727

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

TIP 727: YES

-----Original Message-----
From: Csaba Nemethi <csa...@t-...> 
Sent: Thursday, September 25, 2025 10:43 PM
To: tcl...@li...
Subject: [TCLCORE] CFV: TIP 727

Attn. TCT members,

This is a CFV for TIP 727: Add a ttk::toggleswitch widget to the core.

     https://core.tcl-lang.org/tips/doc/trunk/tip/727.md

Please send your votes to this list until 2025-10-05 00:00 UTC.

Harald sent already his "yes" vote on 2025-09-09.

Best regards,

Csaba

-- 
Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...



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