tcl-core — Tcl Core Team discussions about Tcl development

Re: [TCLCORE] About TIPs 727 and 729

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

As announced below, a few days ago I committed a thoroughly updated 
implementation of the element creation for ttk::toggleswitch widgets 
(TIP 727).  The new version contains both generic code for arbitrary 
themes and theme-specific one for a few built-in themes.

Today I committed a revisited version of TIP 729, whose title now reads 
"Add a tk attribtable command to the core" (the initial one was "Add a 
tk_cargo procedure to the core").  The new version made it necessary to 
rework large parts of the implementation, which I committed today, too.

Comments on both TIPs are highly appreciated.

Best regards,

Csaba


Am 13.09.25 um 14:38 schrieb Csaba Nemethi:
> I would like to thank all who have posted comments regarding TIP 727 
> ("Add a ttk::toggleswitch widget to the core") and TIP 729 ("Add a 
> tk_cargo procedure to the core").
> 
> I am now in a position to commit an updated implementation of the 
> ttk::toggleswitch widget very soon.  In the new version, the elements 
> for third-party themes will be created by generic procedures rather than 
> theme-specific ones.
> 
> After that I will start to rework the cargo-related stuff, taking into 
> account the comments posted by Emiliano and the others who have 
> expressed their opinions regarding this subject.  That work will 
> probably take somewhat longer.
> 
> Best regards,
> 
> Csaba
> 

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

Re: [TCLCORE] Add support for Copy/Cut/Paste keys in X11

[da S. P. J <pet...@fl...>]

Personally I would call this a no-brainer and an unqualified win. It breaks nothing and adds support for these legacy keycodes.

From: Yaacov Akiba Slama <ya...@sl...>
Date: Thursday, September 18, 2025 at 05:24
To: tcl...@li... <tcl...@li...>
Subject: [TCLCORE] Add support for Copy/Cut/Paste keys in X11
Hi, I created a ticket at https: //urldefense. us/v2/url?u=https-3A__core. tcl-2Dlang. org_tk_tktview_04e1735b86&d=DwICAg&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=7ILjDduFiRN-fWIOt63jGJiPzUS569BvCc8Zn84RA7Q0b5wu1ucYiHph3gHB_sxc&s=F4T9vhf7wvGda73G-eNGUwSJOhkyP4p7okyN-RXmUjY&e=


Hi,



I created a ticket at https://urldefense.us/v2/url?u=https-3A__core.tcl-2Dlang.org_tk_tktview_04e1735b86&d=DwICAg&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=7ILjDduFiRN-fWIOt63jGJiPzUS569BvCc8Zn84RA7Q0b5wu1ucYiHph3gHB_sxc&s=F4T9vhf7wvGda73G-eNGUwSJOhkyP4p7okyN-RXmUjY&e= to

support physical Copy/Cut/Paste keys but I am not sure that it's the

right way to contribute.



Do I have to do something else?



Thanks a lot.



--yas







_______________________________________________

Tcl-Core mailing list

Tcl...@li...

https://urldefense.us/v2/url?u=https-3A__lists.sourceforge.net_lists_listinfo_tcl-2Dcore&d=DwICAg&c=MASr1KIcYm9UGIT-jfIzwQg1YBeAkaJoBtxV_4o83uQ&r=BRyGRggIJd8TmKOhvEmGElFuDuCl3O5mT8opva3f-Uc&m=7ILjDduFiRN-fWIOt63jGJiPzUS569BvCc8Zn84RA7Q0b5wu1ucYiHph3gHB_sxc&s=GumDLvI8vDx5-jBhUvcT_WmqW60bebYP7lzKhNb8juA&e=

Re: [TCLCORE] Merge intention for project uniform_test_file_structure

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

On 10/09/2025 14:28, Erik Leunissen via Tcl-Core wrote:
> 
> Unless someone raises founded objections in the meantime, I will carry 
> out the
> intended merge one week after the date of this post.
> 

Now done.

Erik Leunissen.
--

Re: [TCLCORE] CFV: TIP 728, 730

[Jan N. <jan...@gm...>]

Op do 18 sep 2025 om 14:15 schreef Jan Nijtmans <jan...@gm...>:
>
> Op do 18 sep 2025 om 13:39 schreef apnmbx-public--- via Tcl-Core
> <tcl...@li...>:
> > One very, very minor nit. Clarify in manpage that “integer” means as in “string is wideinteger” and not “string is integer”.
>
> In Tcl9 “string is wideinteger” and “string is integer” are exactly the same ;-)

Hm ....   I'm mistaken.  Please ignore my comment

Regards,
         Jan Nijtmans

Re: [TCLCORE] CFV: TIP 728, 730

[Jan N. <jan...@gm...>]

Op do 18 sep 2025 om 13:39 schreef apnmbx-public--- via Tcl-Core
<tcl...@li...>:
> One very, very minor nit. Clarify in manpage that “integer” means as in “string is wideinteger” and not “string is integer”.

In Tcl9 “string is wideinteger” and “string is integer” are exactly the same ;-)

Regards,
       Jan Nijtmans

Re: [TCLCORE] CFV: TIP 728, 730

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

TIP 730: Yes. Long awaited.

 

One very, very minor nit. Clarify in manpage that "integer" means as in
"string is wideinteger" and not "string is integer".

 

And one question arising from experimentation (actually nothing to do with
730, applies to -glob etc. as well). Consider the following disassembly. The
following is not bytecompiled:

 

% 'dis script {switch -integer  $x {0 {puts 0} 1 {puts 1}}}

ByteCode 0x2c7743e0750, refCt 1, epoch 21, interp 0x2c774362be0 (epoch 21)

  Source "switch -integer  $x {0 {puts 0} 1 {puts 1}}"

  Cmds 1, src 43, inst 27, litObjs 4, aux 0, stkDepth 4, code/src 0.00

  Commands 1:

      1: pc 0-25, src 0-42

  Command 1: "switch -integer  $x {0 {puts 0} 1 {puts 1}}"

    (0) push 0  # "switch"

    (5) push 1  # "-integer"

    (10) push 2         # "x"

    (15) loadStk

    (16) push 3         # "0 {puts 0} 1 {puts 1}"

    (21) invokeStk 4

    (26) done

 

while on the other hand the following is:

 

% 'dis script {switch -integer -- $x {0 {puts 0} 1 {puts 1}}}

ByteCode 0x2c7743e0550, refCt 1, epoch 21, interp 0x2c774362be0 (epoch 21)

  Source "switch -integer -- $x {0 {puts 0} 1 {puts 1}}"

  Cmds 3, src 45, inst 62, litObjs 5, aux 1, stkDepth 2, code/src 0.00

  Commands 3:

      1: pc 0-60, src 0-44        2: pc 16-30, src 26-31

      3: pc 36-50, src 37-42

  Command 1: "switch -integer -- $x {0 {puts 0} 1 {puts 1}}"

    (0) push 0  # "x"

    (5) loadStk

    (6) jumpTableNum 0

                [1->pc 36, 0->pc 16]

    (11) jump +45       # pc 56

  Command 2: "puts 0..."

    (16) push 1         # "puts"

    (21) push 2         # "0"

    (26) invokeStk 2

    (31) jump +30       # pc 61

  Command 3: "puts 1..."

    (36) push 1         # "puts"

    (41) push 3         # "1"

    (46) invokeStk 2

    (51) jump +10       # pc 61

    (56) push 4         # ""

    (61) done

 

The difference is the presence of "-" and presumably arises because of
ambiguity. Does that mean in order to get a byte compiled switch one should
always specify "-" ?

 

/Ashok

 

From: Donal Fellows <don...@ma...> 
Sent: Monday, September 15, 2025 7:21 PM
To: Tcl Core <tcl...@li...>
Subject: [TCLCORE] CFV: TIP 728, 730

 

Hi everyone 

 

This a CFV on two small feature TIPs:

 

  TIP 728: Reliable Read and Write of Child Interpreter Variables (aka
interp set)

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

 

  TIP 730: Switching by Integers (aka switch -integer)

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

 

Please send your votes to this list (preferably in reply to this message so
I stand a chance of finding them in my inbox!) by [clock format 1758538800]
(12:00 my time, next Monday).

 

My votes follow:

 

TIP 728: YES

TIP 730: YES

 

Also, let it be known that I have seen Harald's votes for both of these, and
that I've seen Ashok's concerns, but aren't going to delay; I feel quite
strongly that having some TIPs in discussion shouldn't be a reason for
blocking votes on other TIPs, as that would be a recipe for stasis just by
having a discussion open.

 

I've added some compatibility notes to the TIPs. (They were originally in
this email, but I think they're better in the TIPs themselves.)

 

Donal.

[TCLCORE] Add support for Copy/Cut/Paste keys in X11

[Yaacov A. S. <ya...@sl...>]

Hi,

I created a ticket at https://core.tcl-lang.org/tk/tktview/04e1735b86 to 
support physical Copy/Cut/Paste keys but I am not sure that it's the 
right way to contribute.

Do I have to do something else?

Thanks a lot.

--yas

Re: [TCLCORE] CFV: TIP 728, 730

[Brian G. <bri...@ea...>]

Got it. Thanks!
-Brian
(from mobile device)

On Sep 16, 2025, at 07:05, Donal Fellows <don...@ma...> wrote:


One of those values was the value that you're switching on, not the arm label. Whether you want those values to be equal or not is a semantic decision, and something the user should have control over.

These will print different things:
  switch -exact   -- 0x1f {0b111111 {puts foo} default {puts bar}}
  switch -integer -- 0x1f {0b111111 {puts foo} default {puts bar}}

Donal.

-------- Original message --------
From: Brian Griffin <bri...@ea...>
Date: 16/09/2025 13:48 (GMT+00:00)
To: Donal Fellows <don...@ma...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 728, 730

The case where you have 0x1f and 0b11111, fails the uniqueness test, forcing the decision to use strings.

What am I missing?

Re: [TCLCORE] CFV: TIP 728, 730

[Brian G. <bri...@ea...>]

On Sep 16, 2025, at 00:04, Donal Fellows <don...@ma...> wrote:


They're semantically different. In particular, having it explicit allows the use of other representations of integers while having them be equal, which the existing string comparison rules definitely forbid. (For example, 0x1f and 0b111111 are equal integers but different strings.) That in turn admits a different implementation strategy; the jump table uses integer keys rather than string keys.

Donal.

But if all the cases parse out as valid integer numbers, and all the cases are unique numbers, why not decide then to use number keys?

The case where you have 0x1f and 0b11111, fails the uniqueness test, forcing the decision to use strings.

What am I missing?
 -Brian


-------- Original message --------
From: Brian Griffin <bri...@ea...>
Date: 15/09/2025 22:10 (GMT+00:00)
To: Donal Fellows <don...@ma...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 728, 730

Why is this not just an internal optimization performed the first time a switch is entered?  It would add a 1 time cost, but after that the gain should be good. Why must the coder decide?

Re: [TCLCORE] CFV: TIP 728, 730

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

One of those values was the value that you're switching on, not the arm label. Whether you want those values to be equal or not is a semantic decision, and something the user should have control over.

These will print different things:
  switch -exact   -- 0x1f {0b111111 {puts foo} default {puts bar}}
  switch -integer -- 0x1f {0b111111 {puts foo} default {puts bar}}

Donal.

-------- Original message --------
From: Brian Griffin <bri...@ea...>
Date: 16/09/2025 13:48 (GMT+00:00)
To: Donal Fellows <don...@ma...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 728, 730

The case where you have 0x1f and 0b11111, fails the uniqueness test, forcing the decision to use strings.

What am I missing?

Re: [TCLCORE] CFV: TIP 728, 730

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

They're semantically different. In particular, having it explicit allows the use of other representations of integers while having them be equal, which the existing string comparison rules definitely forbid. (For example, 0x1f and 0b111111 are equal integers but different strings.) That in turn admits a different implementation strategy; the jump table uses integer keys rather than string keys.

Donal.

-------- Original message --------
From: Brian Griffin <bri...@ea...>
Date: 15/09/2025 22:10 (GMT+00:00)
To: Donal Fellows <don...@ma...>
Cc: Tcl Core List <tcl...@li...>
Subject: Re: [TCLCORE] CFV: TIP 728, 730

Why is this not just an internal optimization performed the first time a switch is entered?  It would add a 1 time cost, but after that the gain should be good. Why must the coder decide?

Re: [TCLCORE] CFV: TIP 728, 730

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

Donal,

 

As a point of clarification, I certainly did not say, or at least mean to
say, that CFV's should be held up while other TIP's are in discussion. That
would be.absurd! My point was 5 days between announcement of a TIP to a CFV
was too short (for 730, a couple of days more for 728) even in an absolute
sense. The reference to the other TIP's was only to point out that the
limited time people have for OSS was further reduced by discussions already
ongoing and other work that might be in progress. I didn't think any TIP
could get anything more than a cursory review in such a short time frame.

 

No matter, folks will review to the extent they feel necessary to form an
opinion and vote accordingly.

 

/Ashok

 

From: Donal Fellows <don...@ma...> 
Sent: Monday, September 15, 2025 7:21 PM
To: Tcl Core <tcl...@li...>
Subject: [TCLCORE] CFV: TIP 728, 730

 

Hi everyone 

 

This a CFV on two small feature TIPs:

 

  TIP 728: Reliable Read and Write of Child Interpreter Variables (aka
interp set)

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

 

  TIP 730: Switching by Integers (aka switch -integer)

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

 

Please send your votes to this list (preferably in reply to this message so
I stand a chance of finding them in my inbox!) by [clock format 1758538800]
(12:00 my time, next Monday).

 

My votes follow:

 

TIP 728: YES

TIP 730: YES

 

Also, let it be known that I have seen Harald's votes for both of these, and
that I've seen Ashok's concerns, but aren't going to delay; I feel quite
strongly that having some TIPs in discussion shouldn't be a reason for
blocking votes on other TIPs, as that would be a recipe for stasis just by
having a discussion open.

 

I've added some compatibility notes to the TIPs. (They were originally in
this email, but I think they're better in the TIPs themselves.)

 

Donal.

Re: [TCLCORE] CFV: TIP 728, 730

[Brian G. <bri...@ea...>]

On Sep 15, 2025, at 06:50, Donal Fellows <don...@ma...> wrote:

Hi everyone

This a CFV on two small feature TIPs:

  TIP 728: Reliable Read and Write of Child Interpreter Variables (aka interp set)
    https://core.tcl-lang.org/tips/doc/trunk/tip/728.md

  TIP 730: Switching by Integers (aka switch -integer)
    https://core.tcl-lang.org/tips/doc/trunk/tip/730.md

I should have comment on this earlier.

Why is this not just an internal optimization performed the first time a switch is entered?  It would add a 1 time cost, but after that the gain should be good. Why must the coder decide?

-Brian


Please send your votes to this list (preferably in reply to this message so I stand a chance of finding them in my inbox!) by [clock format 1758538800] (12:00 my time, next Monday).

My votes follow:

TIP 728: YES
TIP 730: YES

Also, let it be known that I have seen Harald's votes for both of these, and that I've seen Ashok's concerns, but aren't going to delay; I feel quite strongly that having some TIPs in discussion shouldn't be a reason for blocking votes on other TIPs, as that would be a recipe for stasis just by having a discussion open.

I've added some compatibility notes to the TIPs. (They were originally in this email, but I think they're better in the TIPs themselves.)

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

Re: [TCLCORE] we are moving core away from Roy's infrastructure

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

> It looks like the sync of Tk from 12/09 onwards hasn't run (or has
> failed), and all commits to normally-buildable branches in the past
> week have been since then.
 
> Andreas runs the sync, IIRC. He'll have to investigate; it's
> probably a fairly trivial fix.

Re-added the gh credentials to the ssh-agent of the www user. That
should have fixed it.

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

[TCLCORE] CFV: TIP 728, 730

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

Hi everyone

This a CFV on two small feature TIPs:

  TIP 728: Reliable Read and Write of Child Interpreter Variables (aka interp set)
    https://core.tcl-lang.org/tips/doc/trunk/tip/728.md

  TIP 730: Switching by Integers (aka switch -integer)
    https://core.tcl-lang.org/tips/doc/trunk/tip/730.md

Please send your votes to this list (preferably in reply to this message so I stand a chance of finding them in my inbox!) by [clock format 1758538800] (12:00 my time, next Monday).

My votes follow:

TIP 728: YES
TIP 730: YES

Also, let it be known that I have seen Harald's votes for both of these, and that I've seen Ashok's concerns, but aren't going to delay; I feel quite strongly that having some TIPs in discussion shouldn't be a reason for blocking votes on other TIPs, as that would be a recipe for stasis just by having a discussion open.

I've added some compatibility notes to the TIPs. (They were originally in this email, but I think they're better in the TIPs themselves.)

Donal.

Re: [TCLCORE] we are moving core away from Roy's infrastructure

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

It looks like the sync of Tk from 12/09 onwards hasn't run (or has failed), and all commits to normally-buildable branches in the past week have been since then.

Andreas runs the sync, IIRC. He'll have to investigate; it's probably a fairly trivial fix.

Donal.

-------- Original message --------
From: Jan Nijtmans <jan...@gm...>
Date: 15/09/2025 09:49 (GMT+00:00)
To: Steve Landers <st...@di...>
Cc: "Porter, Don (Fed) via Tcl-Core" <tcl...@li...>
Subject: Re: [TCLCORE] we are moving core away from Roy's infrastructure

Note also that there haven't been any Tk builds last week, even though
there were
commits to the Tk repository. No hurry, but can someone have a look at that too
(if it's runrelated)?  (Tcl builds are fine, it's only Tk)

Re: [TCLCORE] we are moving core away from Roy's infrastructure

[Jan N. <jan...@gm...>]

Op ma 15 sep 2025 om 03:23 schreef Steve Landers <st...@di...>:
> I write to inform you that this is going on and that the transfer will be largely transparent nor should it involve any effort from you.

Great to hear that!

Note also that there haven't been any Tk builds last week, even though
there were
commits to the Tk repository. No hurry, but can someone have a look at that too
(if it's runrelated)?  (Tcl builds are fine, it's only Tk)

Thanks!
      Jan Nijtmans

[TCLCORE] we are moving core away from Roy's infrastructure

[Steve L. <st...@di...>]

Hi Don,

Last week the core server was unavailable for extended periods of time.  I contacted Roy Keene but, as always, was ignored.  Richard Hipp kindly took a look and couldn't figure out what was going on, but the problem seemed to resolve over time.  My theory is that we were hit with a new type of DDoS caused by AI scrapers where millions of individual hosts make a single request  - you can read about this type of problem here https://blog.cloudflare.com/perplexity-is-using-stealth-undeclared-crawlers-to-evade-website-no-crawl-directives/.   It seems that Cloudflare's AI-based bot mitigation kicked in and started blocking connections because the core server became responsive again part way through the attached graph from Thu/Fri last and concurrently note that the number of verified bots increased significantly.

In my opinion it is untenable that we have a core Tcl community resource dependent on a single person who goes absent for extended periods of time.  So for the last few days several of us have been discussing moving core.tcl-lang.org from Roy's infrastructure to a Linode owned by the Tcl Community Association, and concurrently building a team of people around the world who can manage it.   We will eventually consolidate www.tcl-lang.org and wiki.tcl-lang.org onto the same Linode.  Those involved in the discussions include myself, Philip Brooks (the new TCA chair), Clif Flynt, Donal Fellows, Andreas Kupries and Richard Hipp.

I write to inform you that this is going on and that the transfer will be largely transparent nor should it involve any effort from you. Since you are the release manager we will try to time the switchover for a period that isn't going to clash with your efforts.

I'm happy to discuss this at any time if you wish.

-- Steve

[TCLCORE] About TIPs 727 and 729

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

I would like to thank all who have posted comments regarding TIP 727 
("Add a ttk::toggleswitch widget to the core") and TIP 729 ("Add a 
tk_cargo procedure to the core").

I am now in a position to commit an updated implementation of the 
ttk::toggleswitch widget very soon.  In the new version, the elements 
for third-party themes will be created by generic procedures rather than 
theme-specific ones.

After that I will start to rework the cargo-related stuff, taking into 
account the comments posted by Emiliano and the others who have 
expressed their opinions regarding this subject.  That work will 
probably take somewhat longer.

Best regards,

Csaba

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

[TCLCORE] tclcompiler / tbcload

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

Miguel Bagnon’s port of tclcompiler and tbcload to Tcl 9 are now in the tcltk-depot <https://github.com/tcltk-depot>  repository and have been updated to support both Tcl 8 and 9. Note however, byte code compiled under Tcl 8 will be rejected in Tcl 9 and vice versa. There is a special check added for this as Tcl8 byte compiled files will crash Tcl9. This still means there is a bug somewhere that does not do sufficient validation to guard against possible corrupted files and needs to be fixed.

 

Github workflows have been set up for CI.

 

Pending work:

 

- Support for Tcl 9.1 (I believe Miguel is working on this but with uncertain schedule)

- Test suite is very parse. I could not locate any more extensive tests in older repositories.

- Documentation relies on an old ActiveState PDF. It would be nice to bring this up to date.

 

Hope someone (in addition to Miguel) who uses these packages will volunteer to finish up and maintain these packages. I do not use them and do not have time to work on them further.

 

/Ashok

Re: [TCLCORE] Ticket [6c149127]

[Christian W. <Chr...@t-...>]

On 09/12/2025 02:59 AM, Marc Culler wrote:
> Christian,
>
> Would you please explain why your patch adds two null characters at the ends of those strings, instead of just 1?

Pure paranoia, the DString is made up of Win32 wchar_t items, not chars. So a NUL termination
consists of two 0 bytes, isn't it?

BR,
Christian

Re: [TCLCORE] TIP 730: Switching by Integers

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

While both 728 and730 feel like no-brainers, please allow more time for
review. A few days is not enough given real life commitments, one's own
ongoing Tcl projects, and in the current situation, five TIP's in
discussion.

 

From: Donal Fellows <don...@ma...> 
Sent: Wednesday, September 10, 2025 1:33 AM
To: Tcl Core <tcl...@li...>
Subject: [TCLCORE] TIP 730: Switching by Integers

 

Another TIP, this for the feature I've been muttering about doing for ages;
adding a -integer option to switch. It does what it says on the tin. I'm
pretty happy with how this one's come together; it feels like a natural
extension of what we had and took little code to bring to fruition, so I'll
probably call a vote on it at the same time as 728.

 

Donal.

Re: [TCLCORE] About tip#729

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

Irrespective of the comments below, the general proposal is useful and I would be in favor of adding it in some form.

 

Names: Some alternatives to “cargo” (I don’t know if Tk already uses these in other contexts)

 

tk_datum

tk_property

 

Prefix vs namespace: I don’t think in this context namespaces offer any significant advantages over prefixes. In my mind, the primary purpose of namespaces was not to reduce conflicts. After all, two package developers could each decide to use the same namespace (examples: csv, www, http). The main benefit of namespaces is to permit use of the shorter form of names within that namespace scope. I don’t think that is very valuable in this context. Caveat: I have not looked at Emiliano’s proposal in detail as yet to know if there are other benefits to namespace use.

 

tk_cargo vs tk::cargo vs “tk cargo”: Tk seems to have all three forms so none seem to have a leg up in terms of consistency. I do feel that for the most part the tk command ensemble mostly deals with information that is not window specific (with exceptions). However, I didn’t see mention of *winfo* which seems like the best fit as it pertains to retrieving window-specific information. Some possibilities to consider,

 

winfo propertyget $path PROPERTYNAME, or

winfo property get $path PROPERTYNAME, 

 

or even, flattening the commands,

 

winfo set $path PROPERTYNAME …

winfo unset $path PROPERTYNAME …

…

 

etc.

 

Regarding TIP functionality itself,

 

I find the ability to specify a default with dicts (in Tcl 9) very convenient. Correspondingly, I would like the equivalent here as well. So (with DEFAULT defaulting to empty string),

 

tk_cargo set $path ?KEY ?DEFAULT??

 

Also, the idiom of no arguments meaning *all* keys in unset is not intuitive to me, even if it mirrors the set behavior. It has potential for surprises when used with expansion

 

tcl_cargo unset $path {*}$keysToUnset

 

and keysToUnset is empty. If needed, I’d rather see an “unsetall” or “clear” command instead to delete all content.

 

/Ashok

 

From: Emiliano <emi...@gm...> 
Sent: Thursday, September 11, 2025 5:32 AM
To: tcl...@li...
Subject: Re: [TCLCORE] About tip#729

 

+1

Finding a good name is still one of the hardest problems in programming. I've thought 'widgetdata' or 'widgetstore', but I'll leave this to native speakers.

Regards

Emiliano

 

El 10 de septiembre de 2025 5:56:26 p. m. GMT-03:00, Marc Culler <cul...@gm... <mailto:cul...@gm...> > escribió:

When I see the word "cargo" it does not bring to mind setting extra attributes for widgets. It brings to mind the package manager for the Rust language.

 

Any chance that "cargo" could be changed, maybe to "attributes" or "attrs"?

 

-Marc

 

 

 

On Wed, Sep 10, 2025, 9:25 AM Csaba Nemethi <csa...@t-... <mailto:csa...@t-...> > wrote:

Hi Emiliano,

Many thanks for your comments!  Right now I am about to leave, but 
tomorrow I will send you (and the list) a detailed answer.

Best regards,

Csaba


Am 10.09.25 um 16:08 schrieb Emiliano G:
> Csaba, all:
> 
> I think the functionality proposed in TIP 729 "Add a tk_cargo procedure
> to the core" is welcomed but I think it falls short for the reasons explained
> below.
> 
> Consider this scenario: programmer 1 implements a fancy widget as
> a megawidget, a graph widget, using a canvas. The fancy graph widget
> has a -title option. "Fine", she says, "I'll use tk_cargo to store my
> fancy graph title, as well as all other widget specific data".
> She goes ahead and use
> 
> tk_cargo $graph set -title $graphtitle ...
> 
> Unknowingly, programmer 2 is implementing just another fancy tooltip
> with all the bells and whistles all modern tooltips are supposed to
> have, including a title. Of course it uses tk_cargo to store its data!
> So she wrotes
> 
> tk_cargo $widget set -title $title ...
> 
> Now, programmer 1 discovers the Fancytooltip package and decides to
> use it along with his own Fancygraph. She will be very puzzled when
> setting the tooltip changes its graph title upon redraw ...
> 
> This is why tkcargo[1] implements tk_cargo as, well, cargotables.
> This way each megawidget author can use his own table without fear to
> step into each other toes. They just create the table (or tables) they
> need in his private namespace and get along with them. No more
> Average Joe Programmer being puzzled (or worse, upset).
> 
> Now, some points about the functionality that are worth considering
> IMHO (here, tk_cargo is the name of the cargo command):
> 
> * Optionally set, on creation, a list of valid keys for a given
>    cargo table for automatic validation. This is already implemented
>    in tkcargo (the exact API can be adjusted).
> 
>    % tk::cargotable tk_cargo {-title -foo -bar}
>    ::tk_cargo
>    % tk_cargo set . -title foo
>    -title foo
>    tk_cargo set . -wrongswitch foo
>    bad key "-wrongswitch": must be -title, -foo, or -bar
> 
> * Optionally set a command prefix to run when a value is set, get or
>    unset (traces). An (unbaked) example can be
> 
>    tk_cargo trace $window $cmdprefix
> 
>    and when the data is modified call
> 
>    {*}$cmdprefix $window $operation
> 
>    This allows for automatic actions when the values are modified.
> 
> * Perhaps a bit too complex, but a "would be nice to have": a binding
>    table. Another unbaked example
> 
>    tk_cargo bind $window $sequence $script
> 
>    The implementation will rely on Tk_CreateBindingTable and friends.
>    This will allow private bindings not interacting with the more general
>    [bind] mechanism.
> 
> 
> Regards
> 
> Emiliano
> 
> [1] https://chiselapp.com/user/egavilan/repository/tkcargo
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li... <mailto:Tcl...@li...> 
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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



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

-- 
Enviado desde mi dispositivo Android con K-9 Mail. Por favor, disculpa mi brevedad.

Re: [TCLCORE] Ticket [6c149127]

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

Christian,

Would you please explain why your patch adds two null characters at the
ends of those strings, instead of just 1?

- Marc

On Thu, Sep 11, 2025 at 2:50 PM Christian Werner <
Chr...@t-...> wrote:

> May I bring the Tk experts this ticket to attention:
>
>    https://core.tcl-lang.org/tk/info/6c149127b59e968b
>
> The "tk sysnotify" things amongst the tray things could be
> a cause of crashes caused by stack smashing. Only triggered
> by a slightly longer string presented to a command.
>
> Not good,
> Christian
>
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] Ticket [6c149127]

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

I will try to take a look next week. 

> On Sep 11, 2025, at 4:50 PM, Christian Werner <Chr...@t-...> wrote:
> 
> May I bring the Tk experts this ticket to attention:
> 
>  https://core.tcl-lang.org/tk/info/6c149127b59e968b
> 
> The "tk sysnotify" things amongst the tray things could be
> a cause of crashes caused by stack smashing. Only triggered
> by a slightly longer string presented to a command.
> 
> Not good,
> Christian
> 
> 
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core