tcl-core — Tcl Core Team discussions about Tcl development

[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

[TCLCORE] Ticket [6c149127]

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

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

Re: [TCLCORE] About tip#729

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

Csaba, all

Se inline answers below

El jue, 11 sept 2025 a las 7:53, Csaba Nemethi
(<csa...@t-...>) escribió:
>
> Hi Emilano,
>
> I have been using an attrib subcommand for all my mega-widgets for
> decades now, and it has always worked as expected without the need for
> several tables.

And they are great. I use them everyday. But the problem here is using
code from several packages, with different programmers, each one using
different coding conventions and techniques, without stepping on each
other.

> In your example it is sufficient to use prefixes to avoid name collisions:
>
>   tk_cargo $graph set graph-title $graphtitle ... ;# programmer 1
>
>   tk_cargo $widget set tooltip-title $title ...  ;# programmer 2
>
> And even if programmer 2 doesn't use the "tooltip" prefix, programmer 1
> won't experience any name collision if he or she does use the "graph"
> prefix. For safety, it is recommended to always prepend some prefix to
> the attribute names, as shown above.

A naming convention can take things far, as long as everyone follows such
convention. That's why Tcl has namespaces, so people is not forced to
follow someone else's. Instead, as is recommended elsewhere in several
places[1][2], a package should provide a namespace as a child of the global
namespace and put all of its commands and variables inside that namespace.
This is what is desired where: each package creates his table(s) inside
their own namespace.

> You are stating that the better solution is to use several cargo tables.
>  But what if in your example both programmers use the same table, say
>
>   tk::cargotable table1
>
> If programmer 1 doesn't know that programmer 2 has already created a
> table of the name "table1" then his or her invocation of the above
> command will again create a table of the name "table1". However, by
> doing this, all the data contained it table1 will get lost (I have
> tested this)! Instead of name collisions there will be a fatal data
> loss! IMHO, this is much worse than an incidental name collision (which
> can be avoided by using a prefix).

Well, the same happens with [proc], and several other command creating
commands. IMO this is a good thing. If I write

proc ::foo::bar::baz {} {#some code}

I want ::foo::bar::baz to be the one I created.

If what's desired is a way to create a table whose name doesn't clash with any
other, it can be implemented easily. It can be modeled after [image create]
or [oo::object new]. My position here is that when a name is given, it should
overwrite whatever is there[3]. If an arbitrary, non clashing name is desired,
it must be generated in the current namespace (preferable) or in a well known
namespace (as TclOO does).

Regards

Emiliano

[1] https://wiki.tcl-lang.org/page/Tcl+Tutorial+Lesson+31
[2] http://www.wjduquette.com/tcl/namespaces.html - It is sad that it is now
    offline. I remember this to be a great document.
[3] Yes, I'm in disagreement with TclOO behaviour here, but such is life.

Re: [TCLCORE] About tip#729

[Eric B. <eri...@gm...>]

Hi,

I think using a prefix or a specific cargo table is similar, both are used
to prevent name clashes between different users.
The prefix doesn't avoid collision if different users use the same prefix.
Also, "tk::cargotable table1" can be changed to raise an error if table1 is
already defined (and a "-force" option added :-)).
The advantage of having different tables is that it is enforced by the API,
unlike the prefix method, and also seems cleaner to me.

Eric

Le jeu. 11 sept. 2025 à 12:53, Csaba Nemethi <csa...@t-...> a
écrit :

> Hi Emilano,
>
> I have been using an attrib subcommand for all my mega-widgets for
> decades now, and it has always worked as expected without the need for
> several tables.
>
> In your example it is sufficient to use prefixes to avoid name collisions:
>
>      tk_cargo $graph set graph-title $graphtitle ...  ;# programmer 1
>
>      tk_cargo $widget set tooltip-title $title ...    ;# programmer 2
>
> And even if programmer 2 doesn't use the "tooltip" prefix, programmer 1
> won't experience any name collision if he or she does use the "graph"
> prefix.  For safety, it is recommended to always prepend some prefix to
> the attribute names, as shown above.
>
> You are stating that the better solution is to use several cargo tables.
>   But what if in your example both programmers use the same table, say
>
>      tk::cargotable table1
>
> If programmer 1 doesn't know that programmer 2 has already created a
> table of the name "table1" then his or her invocation of the above
> command will again create a table of the name "table1".  However, by
> doing this, all the data contained it table1 will get lost (I have
> tested this)!  Instead of name collisions there will be a fatal data
> loss!  IMHO, this is much worse than an incidental name collision (which
> can be avoided by using a prefix).
>
> 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...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> --
> 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] [Ext] Re: About tip#729

[Zaumseil R. <RZa...@kk...>]

Hello

To avoid collisions you could also save internally to p.e. ${graph}-title

-----Ursprüngliche Nachricht-----
Von: Csaba Nemethi <csa...@t-...> 
Gesendet: Donnerstag, 11. September 2025 12:53
An: tcl...@li...
Betreff: [Ext] Re: [TCLCORE] About tip#729

Hi Emilano,

I have been using an attrib subcommand for all my mega-widgets for decades now, and it has always worked as expected without the need for several tables.

In your example it is sufficient to use prefixes to avoid name collisions:

     tk_cargo $graph set graph-title $graphtitle ...  ;# programmer 1

     tk_cargo $widget set tooltip-title $title ...    ;# programmer 2

And even if programmer 2 doesn't use the "tooltip" prefix, programmer 1 won't experience any name collision if he or she does use the "graph" 
prefix.  For safety, it is recommended to always prepend some prefix to the attribute names, as shown above.

You are stating that the better solution is to use several cargo tables. 
  But what if in your example both programmers use the same table, say

     tk::cargotable table1

If programmer 1 doesn't know that programmer 2 has already created a table of the name "table1" then his or her invocation of the above command will again create a table of the name "table1".  However, by doing this, all the data contained it table1 will get lost (I have tested this)!  Instead of name collisions there will be a fatal data loss!  IMHO, this is much worse than an incidental name collision (which can be avoided by using a prefix).

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...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

--
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] About tip#729

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

Hi Emilano,

I have been using an attrib subcommand for all my mega-widgets for 
decades now, and it has always worked as expected without the need for 
several tables.

In your example it is sufficient to use prefixes to avoid name collisions:

     tk_cargo $graph set graph-title $graphtitle ...  ;# programmer 1

     tk_cargo $widget set tooltip-title $title ...    ;# programmer 2

And even if programmer 2 doesn't use the "tooltip" prefix, programmer 1 
won't experience any name collision if he or she does use the "graph" 
prefix.  For safety, it is recommended to always prepend some prefix to 
the attribute names, as shown above.

You are stating that the better solution is to use several cargo tables. 
  But what if in your example both programmers use the same table, say

     tk::cargotable table1

If programmer 1 doesn't know that programmer 2 has already created a 
table of the name "table1" then his or her invocation of the above 
command will again create a table of the name "table1".  However, by 
doing this, all the data contained it table1 will get lost (I have 
tested this)!  Instead of name collisions there will be a fatal data 
loss!  IMHO, this is much worse than an incidental name collision (which 
can be avoided by using a prefix).

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...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

Re: [TCLCORE] fossil server down?

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

The server seems to be working again.

- Marc

On Wed, Sep 10, 2025 at 4:45 PM Kevin Walzer <kw...@co...> wrote:

> Yes, I am seeing the same thing.
>
> > On Sep 10, 2025, at 6:19 PM, Marc Culler <cul...@gm...> wrote:
> >
> > 
> > When I try to pull the Tk repo I am getting a status code of 521, which
> is  a Cloudflare-specific code meaning that Cloudflare cannot contact the
> origin server.
> >
> > - Marc
> > _______________________________________________
> > Tcl-Core mailing list
> > Tcl...@li...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>

Re: [TCLCORE] About tip#729

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

+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...> 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-...>
>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...
>> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>> --
>> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
>>
>>
>>
>> _______________________________________________
>> Tcl-Core mailing list
>> 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] About tip#729

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

My reaction too.

-- Steve
On 11 Sep 2025 at 4:57 AM +0800, Marc Culler <cul...@gm...>, wrote:
> 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-...> 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...
> > > https://lists.sourceforge.net/lists/listinfo/tcl-core
> >
> > --
> > Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
> >
> >
> >
> > _______________________________________________
> > 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] fossil server down?

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

Yes, I am seeing the same thing. 

> On Sep 10, 2025, at 6:19 PM, Marc Culler <cul...@gm...> wrote:
> 
> 
> When I try to pull the Tk repo I am getting a status code of 521, which is  a Cloudflare-specific code meaning that Cloudflare cannot contact the origin server.
> 
> - Marc
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

[TCLCORE] fossil server down?

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

When I try to pull the Tk repo I am getting a status code of 521, which is
a Cloudflare-specific code meaning that Cloudflare cannot contact the
origin server.

- Marc

Re: [TCLCORE] About tip#729

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

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-...>
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...
> > https://lists.sourceforge.net/lists/listinfo/tcl-core
>
> --
> 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] Merge intention for project uniform_test_file_structure

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

On 9/10/25 14:28, Erik Leunissen via Tcl-Core wrote:
> 
>        * the results of Tk test suite runs on Github CI:
> 
>            https://github.com/tclt/tk/actions?query=branch%3Auniform_test_file_structure

That should be:

     https://github.com/tcltk/tk/actions?query=branch%3Auniform_test_file_structure

Re: [TCLCORE] Merge intention for project uniform_test_file_structure

[Donald G P. <don...@ni...>]

On 9/10/25 08:28, Erik Leunissen via Tcl-Core wrote:
> The development branch for the project "uniform_test_file_structure" is now ready
> for merging into the target branches trunk and core-9-0-branch. [*]

I see that `make test` in this branch generates just about the same results as
`make test` does on the current trunk.  Same failing tests.  Similar counts.

Functionally it works.  I don't see anything broken.

I didn't look at any of it to know whether I think it's more pleasing or maintainable.

-- 
| Don Porter            Applied and Computational Mathematics Division |
| don...@ni...             Information Technology Laboratory |
| http://math.nist.gov/~DPorter/                                  NIST |
|______________________________________________________________________|

Re: [TCLCORE] About tip#729

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

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...
> https://lists.sourceforge.net/lists/listinfo/tcl-core

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

Re: [TCLCORE] TIP 727: toggleswitch

[Schelte B. <tc...@tc...>]

The cited commands date back to the Tk 4.2 era. This was before Tcl even 
had a concept of namespaces. I don't think those commands should be used 
as a guide of how to implement new commands nowadays.

Adding a cargo subcommand (whether using Csaba's or Emiliano's 
implementation) to the tk ensemble would be my preference. The manual 
says "most of the information manipulated by this command". That does 
not exclude doing something different if it makes sense. And if this is 
still a concern, the description in the manual page can be adjusted to 
better reflect new developments.


Schelte.


On 10/09/2025 15:31, Csaba Nemethi wrote:
> Regarding tk sysnotify and tk systray that was surely the right 
> decision.  OTOH, tk print expects a widget path name as argument, which 
> doesn't pertain "to the application as a whole, or to a screen or 
> display", as described in the man page.
> 
> 
> Am 10.09.25 um 14:59 schrieb Kevin Walzer:
>> Fine with me. When I was adding the printing and systray commands, I 
>> was strongly urged to put them under the tk ensemble. But I see your 
>> point.
>>
>>> On Sep 10, 2025, at 8:24 AM, Csaba Nemethi <csaba.nemethi@t- 
>>> online.de> wrote:
>>>
>>> That would make it necessary to add a "cargo" subcommand to the 
>>> ensemble of the tk subcommands.  This subcommand would then have to 
>>> execute the Tcl procedure.  IMHO, this is not worth the trouble.  In 
>>> addition, I am not sure that "tk cargo" would be better then 
>>> "tk_cargo".  According to the tk man page,
>>>
>>>        "... Most of the information manipulated by this command pertains
>>>        to the application as a whole, or to a screen or display, 
>>> rather than to
>>>        a particular window. ..."
>>>
>>>
>>>> Am 10.09.25 um 12:07 schrieb Kevin Walzer:
>>>> You could also do “tk cargo,” like “tk busy” or “tk print.”
>>>>>> On Sep 10, 2025, at 4:15 AM, Csaba Nemethi <csaba.nemethi@t- 
>>>>>> online.de> wrote:
>>>>>
>>>>> Hi Harald,
>>>>>
>>>>> I will return soon to your comments concerning the third-party themes.
>>>>>
>>>>> Why tk_cargo rather than tk::cargo?  We have tk_dialog, 
>>>>> tk_messageBox, tk_optionMenu, tk_popup, tk_setPalette, etc. rather 
>>>>> than tk::dialog, tk::messageBox, tk::optionMenu, etc. (to mention 
>>>>> just a few Tk core procs).  I share your opinion that tk::cargo 
>>>>> would be nicer, but OTOH it would break the tradition. :-)
>>>>>
>>>>> Best regards,
>>>>>
>>>>> Csaba
>>>>>
>>>>>
>>>>>> Am 09.09.25 um 21:30 schrieb Harald Oehlmann:
>>>>>> Hi Csaba,
>>>>>> I would prefer, that anything concerning other themes go to this 
>>>>>> theme and not to the core.
>>>>>> I would also love to get awdark and awlight to the tcl-depot 
>>>>>> repository, as they are unmaintained, but so useful.
>>>>>> Can the droid stuff go to the androwish repository?
>>>>>> Thanks for all,
>>>>>> Harald
>>>>>> ---
>>>>>> And thanks for tk_cargo, great ! Great Tip.
>>>>>> May the command name not be named tk::cargo ?
>>>>>> Thanks for all,
>>>>>> Harald
>>>>>>> Am 09.09.2025 um 13:37 schrieb Csaba Nemethi:
>>>>>>> Update:  Before starting the CFV for TIP 727 ("Add a 
>>>>>>> ttk::toggleswitch widget to the core"), I would much appreciate 
>>>>>>> if we could decide which themes should/may be _explicitly_ 
>>>>>>> supported by the ttk::toggleswitch command.
>>>>>>>
>>>>>>> Currently the implementation creates the trough and slider 
>>>>>>> elements when needed not only for the built-in themes, but also 
>>>>>>> for droid (which is the default theme in AndroWish), plastik 
>>>>>>> (which droid is derived from), awarc, awbreeze, awbreezedark, 
>>>>>>> awlight, and awdark.  Any other theme will import these elements 
>>>>>>> from the "default" theme (or a dark variant of it), or the 
>>>>>>> application can add explicit support for it by providing an 
>>>>>>> appropriate command of the name 
>>>>>>> ttk::toggleswitch::CreateElements_<theme>.
>>>>>>>
>>>>>>> Since the TIP proposes to add a new widget _to the core_, I am 
>>>>>>> not sure whether it is OK if the implementation provides 
>>>>>>> _explicit_ support for all these third-party themes.
>>>>>>>
>>>>>>> In case we decide to make the above list of themes smaller, my 
>>>>>>> personal proposal would be to keep the explicit support for the 
>>>>>>> themes droid, awlight, and awdark.  Rationale: droid is the 
>>>>>>> default in AndroWish, and awlight and awdark seem to be the most 
>>>>>>> popular themes of the awthemes package.  The plastik theme has 
>>>>>>> the drawback that it is not scalable, while awarc, awbreeze, and 
>>>>>>> awbreezedark have a suboptimal performance.
>>>>>>>
>>>>>>> Any feedback (not only from TCT members) is highly appreciated.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Csaba
>>>>>>>
>>>>>>>
>>>>>>> Am 08.09.25 um 14:55 schrieb Csaba Nemethi:
>>>>>>>> Hi Harald,
>>>>>>>>
>>>>>>>> I, too, think that the opinion of a few Tk wizards would be 
>>>>>>>> important and highly welcomed.  In the next step we could then 
>>>>>>>> call for vote.
>>>>>>>>
>>>>>>>> Best regards,
>>>>>>>>
>>>>>>>> Csaba
>>>>>>>>
>>>>>>>>
>>>>>>>> Am 08.09.25 um 14:08 schrieb Harald Oehlmann:
>>>>>>>>> Dear Tk team, dear Csaba,
>>>>>>>>>
>>>>>>>>> TIP 727
>>>>>>>>> https://core.tcl-lang.org/tips/doc/trunk/tip/727.md
>>>>>>>>> introduces the new widget "ttk::toggleswitch".
>>>>>>>>> For me, this is a great improvement.
>>>>>>>>> Csaba has developped this IMHO to a mature state.
>>>>>>>>>
>>>>>>>>> Now, Csaba continues with the next project from the conference, 
>>>>>>>>> the "cargo" possibility, that each tk widget may have a 
>>>>>>>>> variable store.
>>>>>>>>>
>>>>>>>>> Csaba, if you intend to call the vote of 727, I am ready to 
>>>>>>>>> sponsor.
>>>>>>>>> Unfortunately, I will be offline from next Saturday until 
>>>>>>>>> 2025-10-07.
>>>>>>>>>
>>>>>>>>> Please ping me, if I can don anything this week.
>>>>>>>>> I am on travel but still reachable.
>>>>>>>>> I would love a 2nd tk Wizard opinion on the TIP and 
>>>>>>>>> implementation like Mark, Brian, Francois or Kevin.
>>>>>>>>>
>>>>>>>>> Thanks for all the action, we all highly appreciate!
>>>>>>>>>
>>>>>>>>> Take care,
>>>>>>>>> Harald
>>>>>>>>>
>>>>>> _______________________________________________
>>>>>> Tcl-Core mailing list
>>>>>> Tcl...@li...
>>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>>
>>>>> -- 
>>>>> Csaba Nemethi  https://www.nemethi.de  mailto:csaba.nemethi@t- 
>>>>> online.de
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Tcl-Core mailing list
>>>>> Tcl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>
>>> -- 
>>> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
>>>
> 

[TCLCORE] About tip#729

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

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

Re: [TCLCORE] TIP 727: toggleswitch

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

Regarding tk sysnotify and tk systray that was surely the right 
decision.  OTOH, tk print expects a widget path name as argument, which 
doesn't pertain "to the application as a whole, or to a screen or 
display", as described in the man page.


Am 10.09.25 um 14:59 schrieb Kevin Walzer:
> Fine with me. When I was adding the printing and systray commands, I was strongly urged to put them under the tk ensemble. But I see your point.
> 
>> On Sep 10, 2025, at 8:24 AM, Csaba Nemethi <csa...@t-...> wrote:
>>
>> That would make it necessary to add a "cargo" subcommand to the ensemble of the tk subcommands.  This subcommand would then have to execute the Tcl procedure.  IMHO, this is not worth the trouble.  In addition, I am not sure that "tk cargo" would be better then "tk_cargo".  According to the tk man page,
>>
>>        "... Most of the information manipulated by this command pertains
>>        to the application as a whole, or to a screen or display, rather than to
>>        a particular window. ..."
>>
>>
>>> Am 10.09.25 um 12:07 schrieb Kevin Walzer:
>>> You could also do “tk cargo,” like “tk busy” or “tk print.”
>>>>> On Sep 10, 2025, at 4:15 AM, Csaba Nemethi <csa...@t-...> wrote:
>>>>
>>>> Hi Harald,
>>>>
>>>> I will return soon to your comments concerning the third-party themes.
>>>>
>>>> Why tk_cargo rather than tk::cargo?  We have tk_dialog, tk_messageBox, tk_optionMenu, tk_popup, tk_setPalette, etc. rather than tk::dialog, tk::messageBox, tk::optionMenu, etc. (to mention just a few Tk core procs).  I share your opinion that tk::cargo would be nicer, but OTOH it would break the tradition. :-)
>>>>
>>>> Best regards,
>>>>
>>>> Csaba
>>>>
>>>>
>>>>> Am 09.09.25 um 21:30 schrieb Harald Oehlmann:
>>>>> Hi Csaba,
>>>>> I would prefer, that anything concerning other themes go to this theme and not to the core.
>>>>> I would also love to get awdark and awlight to the tcl-depot repository, as they are unmaintained, but so useful.
>>>>> Can the droid stuff go to the androwish repository?
>>>>> Thanks for all,
>>>>> Harald
>>>>> ---
>>>>> And thanks for tk_cargo, great ! Great Tip.
>>>>> May the command name not be named tk::cargo ?
>>>>> Thanks for all,
>>>>> Harald
>>>>>> Am 09.09.2025 um 13:37 schrieb Csaba Nemethi:
>>>>>> Update:  Before starting the CFV for TIP 727 ("Add a ttk::toggleswitch widget to the core"), I would much appreciate if we could decide which themes should/may be _explicitly_ supported by the ttk::toggleswitch command.
>>>>>>
>>>>>> Currently the implementation creates the trough and slider elements when needed not only for the built-in themes, but also for droid (which is the default theme in AndroWish), plastik (which droid is derived from), awarc, awbreeze, awbreezedark, awlight, and awdark.  Any other theme will import these elements from the "default" theme (or a dark variant of it), or the application can add explicit support for it by providing an appropriate command of the name ttk::toggleswitch::CreateElements_<theme>.
>>>>>>
>>>>>> Since the TIP proposes to add a new widget _to the core_, I am not sure whether it is OK if the implementation provides _explicit_ support for all these third-party themes.
>>>>>>
>>>>>> In case we decide to make the above list of themes smaller, my personal proposal would be to keep the explicit support for the themes droid, awlight, and awdark.  Rationale: droid is the default in AndroWish, and awlight and awdark seem to be the most popular themes of the awthemes package.  The plastik theme has the drawback that it is not scalable, while awarc, awbreeze, and awbreezedark have a suboptimal performance.
>>>>>>
>>>>>> Any feedback (not only from TCT members) is highly appreciated.
>>>>>>
>>>>>> Best regards,
>>>>>>
>>>>>> Csaba
>>>>>>
>>>>>>
>>>>>> Am 08.09.25 um 14:55 schrieb Csaba Nemethi:
>>>>>>> Hi Harald,
>>>>>>>
>>>>>>> I, too, think that the opinion of a few Tk wizards would be important and highly welcomed.  In the next step we could then call for vote.
>>>>>>>
>>>>>>> Best regards,
>>>>>>>
>>>>>>> Csaba
>>>>>>>
>>>>>>>
>>>>>>> Am 08.09.25 um 14:08 schrieb Harald Oehlmann:
>>>>>>>> Dear Tk team, dear Csaba,
>>>>>>>>
>>>>>>>> TIP 727
>>>>>>>> https://core.tcl-lang.org/tips/doc/trunk/tip/727.md
>>>>>>>> introduces the new widget "ttk::toggleswitch".
>>>>>>>> For me, this is a great improvement.
>>>>>>>> Csaba has developped this IMHO to a mature state.
>>>>>>>>
>>>>>>>> Now, Csaba continues with the next project from the conference, the "cargo" possibility, that each tk widget may have a variable store.
>>>>>>>>
>>>>>>>> Csaba, if you intend to call the vote of 727, I am ready to sponsor.
>>>>>>>> Unfortunately, I will be offline from next Saturday until 2025-10-07.
>>>>>>>>
>>>>>>>> Please ping me, if I can don anything this week.
>>>>>>>> I am on travel but still reachable.
>>>>>>>> I would love a 2nd tk Wizard opinion on the TIP and implementation like Mark, Brian, Francois or Kevin.
>>>>>>>>
>>>>>>>> Thanks for all the action, we all highly appreciate!
>>>>>>>>
>>>>>>>> Take care,
>>>>>>>> Harald
>>>>>>>>
>>>>> _______________________________________________
>>>>> Tcl-Core mailing list
>>>>> Tcl...@li...
>>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>>>
>>>> --
>>>> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Tcl-Core mailing list
>>>> Tcl...@li...
>>>> https://lists.sourceforge.net/lists/listinfo/tcl-core
>>
>> --
>> Csaba Nemethi  https://www.nemethi.de  mailto:csa...@t-...
>>

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