Menu
▾
▴
tcl-core
|
From: Csaba N. <csa...@t-...> - 2025-09-13 12:38:30
|
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-...
|
|
From: Csaba N. <csa...@t-...> - 2025-09-18 19:24:28
|
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-...
|
|
From: Emiliano G <emi...@gm...> - 2025-09-22 15:53:11
|
El jue, 18 sept 2025 a las 16:24, Csaba Nemethi (<csa...@t-...>) escribió: > > 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. Some comments about tip 729, most of which are personal preferences: * tk attribtable tableName My preference for the tableName command to be created in the current namespace if not fully qualified. This will ease the handling of attribute tables when implemented as TclOO objects. If tableName already exists, it is overwritten. Also, in all the tableName instance subcommands, if pathName doesn't exist my preference is to raise an error, except in [tableName exists]. * tableName set Preference to return the full key-value pair for pathName in tableName, just as [dict set] does. * tableName get Preferred API ** tableName get pathName ?key? ?defaultvalue? If there's no such "key" entry, "defaultvalue" is returned if specified, or an empty string otherwise, just as [ttk::style lookup] does. * tableName names Preferred API ** tableName names ?pathName? returning the list of path names in tableName if pathName is not specified. Otherwise, it returns the list of keys already set for pathName in tableName. * tableName clear I prefer the description "Unsets all attributes *and removes pathName* from tableName. Returns an empty string." About the implementation: is there any technical advantage to do this in Tcl and not C? Regards Emiliano |
|
From: Csaba N. <csa...@t-...> - 2025-09-22 20:18:27
|
Hi Emiliano,
Many thanks for your comments! See my answer embedded into your text.
Am 22.09.25 um 17:48 schrieb Emiliano G:
> El jue, 18 sept 2025 a las 16:24, Csaba Nemethi
> (<csa...@t-...>) escribió:
>>
>> 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.
>
> Some comments about tip 729, most of which are personal preferences:
>
> * tk attribtable tableName
>
> My preference for the tableName command to be created in the current
> namespace if not fully qualified. This will ease the handling of
> attribute tables when implemented as TclOO objects. If tableName
> already exists, it is overwritten. Also, in all the tableName instance
> subcommands, if pathName doesn't exist my preference is to raise an
> error, except in [tableName exists].
>
It is common practice in Tk that commands by name are created in the
global namespace. Example: image create <type> <name> ... Here the
<name> command is always created in the global namespace. Why should we
break this rule?
The implementation already makes sure that an already existing tableName
command will be overwritten. This is explicitly mentioned in the manual:
"If an attribute table of the given name already exists then it is
replaced with the new one and all the attributes of all widgets set
using the old table instance will be unset."
Also, in all the tableName instance subcommands, if pathName doesn't
exist then the implementation already raises an error. This is valid
for all op names (set|get|names|unset|clear|exists). Why should the
"exists" case be handled differently?
> * tableName set
>
> Preference to return the full key-value pair for pathName in
> tableName, just as [dict set] does.
>
What would this be good for? Do you have a convincing use case? Would
it have any benefit over retrieving this information via "tableName get" ?
> * tableName get
>
> Preferred API
>
> ** tableName get pathName ?key? ?defaultvalue?
>
> If there's no such "key" entry, "defaultvalue" is returned if
> specified, or an empty string otherwise, just as [ttk::style lookup]
> does.
>
OK, this is a decent proposal, I will implement it.
> * tableName names
>
> Preferred API
>
> ** tableName names ?pathName?
>
> returning the list of path names in tableName if pathName is not
> specified. Otherwise, it returns the list of keys already set for
> pathName in tableName.
>
Here, the word "names" always refers to attribute names, aka keys. Your
proposal would add a second meaning to it. What about a new subcommand
"tableName pathnames" instead?
> * tableName clear
>
> I prefer the description "Unsets all attributes *and removes pathName*
> from tableName. Returns an empty string."
>
OK, I will add this to the man page.
> About the implementation: is there any technical advantage to do this
> in Tcl and not C?
>
The implementation in Tcl is much simpler and easier to maintain.
Currently it has no more than 228 LOC, of which 81 are comments or empty
lines.
> Regards
> Emiliano
>
Best regards,
Csaba
>
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
--
Csaba Nemethi https://www.nemethi.de mailto:csa...@t-...
|
|
From: Emiliano <emi...@gm...> - 2025-09-23 01:06:16
|
On Mon, 22 Sep 2025 22:18:13 +0200 Csaba Nemethi <csa...@t-...> wrote: > Hi Emiliano, > > Many thanks for your comments! See my answer embedded into your text. Many thanks for taking the time to read them, and for moving this forward! See inline comments ... > > It is common practice in Tk that commands by name are created in the > global namespace. Example: image create <type> <name> ... Here the > <name> command is always created in the global namespace. Why should we > break this rule? Tk predates namespaces, so compatibility plays an important role here. But this is not the case with this functionality, which is meant to be used primarily by package developers, so they are expected to put all their data inside a namespace. That said, even the current docs recommends, in case of images, to use namespaces. image(n) reads "It is important to note that the image command will silently overwrite any procedure that may currently be defined by the given name, so choose the name wisely. It is recommended to use a separate namespace for image names (e.g., ::img::logo, ::img::large)." I'll argue that, while *named* images should be created from the global scope (so they are easier to find), non-named images, as created by [image create $type -opt ...] should be created in the current namespace as the returned name will be assigned to a variable anyway. Just as [oo::object new] does. > The implementation already makes sure that an already existing tableName > command will be overwritten. This is explicitly mentioned in the manual: > > "If an attribute table of the given name already exists then it is > replaced with the new one and all the attributes of all widgets set > using the old table instance will be unset." Sorry, didn't read the docs, just the tip. My bad! > Also, in all the tableName instance subcommands, if pathName doesn't > exist then the implementation already raises an error. This is valid > for all op names (set|get|names|unset|clear|exists). Why should the > "exists" case be handled differently? For the same reason [winfo] returns an error when asked for info about a non-existing widget but doesn't when asked about whether it [winfo exists]. It should return just true or false. > > * tableName set > > > > Preference to return the full key-value pair for pathName in > > tableName, just as [dict set] does. > > > > What would this be good for? Do you have a convincing use case? Would > it have any benefit over retrieving this information via "tableName get" ? No. As said, just consistency with [dict set]. While I like consistency, this can be left out. Fine with me. > > * tableName names > > > > Preferred API > > > > ** tableName names ?pathName? > > > > returning the list of path names in tableName if pathName is not > > specified. Otherwise, it returns the list of keys already set for > > pathName in tableName. > > > > Here, the word "names" always refers to attribute names, aka keys. Your > proposal would add a second meaning to it. What about a new subcommand > "tableName pathnames" instead? Also fine with me. This is also for the sake of consistency. When some functionality in Tcl or Tk uses a handle or any kind of mapping, the "names" subcommand (array names, image names ...) usually is a list of keys. In this case, we have two cascade mappings in play: window -> attributes dictionary and attribute (or key, or name ... ) -> value. I simply thought in collapsing both in a single command. > > About the implementation: is there any technical advantage to do this > > in Tcl and not C? > > > > The implementation in Tcl is much simpler and easier to maintain. > Currently it has no more than 228 LOC, of which 81 are comments or empty > lines. Sorry, but I beg to differ on this point. A C implementation is not much longer. tkcargo is 466 lines of C code and it actually have more functionality than the one proposed here, using standard Tcl and Tk C API. It is also way faster, mainly when the number of widgets and the number of tables become quite large [1]. I've attached four files, three measuring test scripts and a result csv file. The three test scripts are almost the same, one running with plain Tk (not tables) to be the reference value, one with [tk attribtable] and one with tkcargo. They are different as I just want to be sure I was testing the right thing and be sure I didn't srew up things. While the results seem somewhat noisy, the tendency is clear. Also, I'm not comfortable with the modification of Tk_DestroyWindow to support this use case, based on two points. First, the cleanup script will be forced to run even for widgets that are not in any table, a source of slowdown. And the other is a matter of style: when introducing any other functionality which needs to perform some cleanup when a widget is destroyed, will we keep adding scripts to run? Regards Emiliano [1] Result also show something that looks like O(n^2) when detroying large number of widgets, for example a frame with several thousand children. But this has to be investigated independently of the ongoing discussion. |
|
From: Donal F. <don...@ma...> - 2025-09-23 16:01:30
|
Emiliano wrote: That said, even the current docs recommends, in case of images, to use namespaces. image(n) reads "It is important to note that the image command will silently overwrite any procedure that may currently be defined by the given name, so choose the name wisely. It is recommended to use a separate namespace for image names (e.g., ::img::logo, ::img::large)." I remember writing that. It was based on the experience of doing [image create photo open ...] to make the icon for a button used to open files, and then wondering why my program broke! The important thing is avoiding overwriting existing commands. The actual workaround I originally used (in Tk 4.0, so a good while ago) was using default-named images and storing their handles in an array indexed by the names I really wanted. Donal. |
|
From: bch <bra...@gm...> - 2025-09-23 18:46:08
|
> On Sep 23, 2025, at 09:01, Donal Fellows <don...@ma...> wrote:
>
>
> Emiliano wrote:
> That said, even the current docs recommends, in case of images, to use namespaces. image(n) reads "It is important to note that the image command will silently overwrite any procedure that may currently be defined by the given name, so choose the name wisely. It is recommended to use a separate namespace for image names (e.g., ::img::logo, ::img::large)."
>
> I remember writing that. It was based on the experience of doing [image create photo open ...] to make the icon for a button used to open files, and then wondering why my program broke! The important thing is avoiding overwriting existing commands.
>
> The actual workaround I originally used (in Tk 4.0, so a good while ago) was using default-named images and storing their handles in an array indexed by the names I really wanted.
What I do in my command-generating-code is test ( if(NULL!=Tcl_GetCommandFromObj(interp, objv[objc-1]){…; return TCL_ERROR}) - if overwriting is warranted, a “-force bool” switch can be used, but otherwise, it seems dangerous/disrespectful to blindly nuke another command. Or test the objProc and only nuke the packages own types…
% bch_pkg mk -foo 8 -bar mars puts ;# “puts” == name to be generated
Is a typical test in my development that has better fail.
-bch
>
> Donal.
> _______________________________________________
> Tcl-Core mailing list
> Tcl...@li...
> https://lists.sourceforge.net/lists/listinfo/tcl-core
|
|
From: Emiliano <emi...@gm...> - 2025-09-23 01:07:49
|
On Mon, 22 Sep 2025 22:18:13 +0200 Csaba Nemethi <csa...@t-...> wrote: And, as usual, forgot to attach the files!! Sorry. Regards Emiliano |
|
From: nicolas b. <sl1...@gm...> - 2025-09-23 07:34:07
|
Hi Csaba, about TIP 727 (ttk::toggleswitch), I've tried your code with my app on both macOS and Windows. I had to remove package require tsw and replace tsw::toggleswitch with ttk::toggleswitch in my code. it works very fine on both platforms (on Windows I do use the awdark theme) best regards, Nicolas Le mar. 23 sept. 2025 à 03:08, Emiliano <emi...@gm...> a écrit : > On Mon, 22 Sep 2025 22:18:13 +0200 > Csaba Nemethi <csa...@t-...> wrote: > > And, as usual, forgot to attach the files!! Sorry. > > Regards > > Emiliano > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Csaba N. <csa...@t-...> - 2025-09-24 07:53:17
|
Hi Emiliano, See my embedded comments below. Am 23.09.25 um 03:06 schrieb Emiliano: > On Mon, 22 Sep 2025 22:18:13 +0200 > Csaba Nemethi <csa...@t-...> wrote: > >> Hi Emiliano, >> >> Many thanks for your comments! See my answer embedded into your text. > > Many thanks for taking the time to read them, and for moving this forward! > See inline comments ... > >> >> It is common practice in Tk that commands by name are created in the >> global namespace. Example: image create <type> <name> ... Here the >> <name> command is always created in the global namespace. Why should we >> break this rule? > > Tk predates namespaces, so compatibility plays an important role here. > But this is not the case with this functionality, which is meant to be used > primarily by package developers, so they are expected to put all their data > inside a namespace. > > That said, even the current docs recommends, in case of images, to use > namespaces. image(n) reads "It is important to note that the image command > will silently overwrite any procedure that may currently be defined by the > given name, so choose the name wisely. It is recommended to use a separate > namespace for image names (e.g., ::img::logo, ::img::large)." > > I'll argue that, while *named* images should be created from the global > scope (so they are easier to find), non-named images, as created by > [image create $type -opt ...] should be created in the current namespace > as the returned name will be assigned to a variable anyway. Just as > [oo::object new] does. > The new version creates the attribute table of a given name as a procedure in the namespace of the calling context if not fully qualified. >> The implementation already makes sure that an already existing tableName >> command will be overwritten. This is explicitly mentioned in the manual: >> >> "If an attribute table of the given name already exists then it is >> replaced with the new one and all the attributes of all widgets set >> using the old table instance will be unset." > > Sorry, didn't read the docs, just the tip. My bad! > >> Also, in all the tableName instance subcommands, if pathName doesn't >> exist then the implementation already raises an error. This is valid >> for all op names (set|get|names|unset|clear|exists). Why should the >> "exists" case be handled differently? > > For the same reason [winfo] returns an error when asked for info about a > non-existing widget but doesn't when asked about whether it [winfo exists]. > It should return just true or false. > The exists subcommand no longer checks whether the path name specifies an existing widget. >>> * tableName set >>> >>> Preference to return the full key-value pair for pathName in >>> tableName, just as [dict set] does. >>> >> >> What would this be good for? Do you have a convincing use case? Would >> it have any benefit over retrieving this information via "tableName get" ? > > No. As said, just consistency with [dict set]. While I like consistency, this > can be left out. Fine with me. > No action here. >>> * tableName names >>> >>> Preferred API >>> >>> ** tableName names ?pathName? >>> >>> returning the list of path names in tableName if pathName is not >>> specified. Otherwise, it returns the list of keys already set for >>> pathName in tableName. >>> >> >> Here, the word "names" always refers to attribute names, aka keys. Your >> proposal would add a second meaning to it. What about a new subcommand >> "tableName pathnames" instead? > > Also fine with me. This is also for the sake of consistency. When some > functionality in Tcl or Tk uses a handle or any kind of mapping, the "names" > subcommand (array names, image names ...) usually is a list of keys. > In this case, we have two cascade mappings in play: window -> attributes > dictionary and attribute (or key, or name ... ) -> value. I simply thought > in collapsing both in a single command. > Now I have added a pathnames subcommand. >>> About the implementation: is there any technical advantage to do this >>> in Tcl and not C? >>> >> >> The implementation in Tcl is much simpler and easier to maintain. >> Currently it has no more than 228 LOC, of which 81 are comments or empty >> lines. > > Sorry, but I beg to differ on this point. A C implementation is not much > longer. tkcargo is 466 lines of C code and it actually have more functionality > than the one proposed here, using standard Tcl and Tk C API. It is also way > faster, mainly when the number of widgets and the number of tables become > quite large [1]. I've attached four files, three measuring test scripts and > a result csv file. The three test scripts are almost the same, one running > with plain Tk (not tables) to be the reference value, one with [tk attribtable] > and one with tkcargo. They are different as I just want to be sure I was > testing the right thing and be sure I didn't srew up things. While the results > seem somewhat noisy, the tendency is clear. > > Also, I'm not comfortable with the modification of Tk_DestroyWindow to > support this use case, based on two points. First, the cleanup script > will be forced to run even for widgets that are not in any table, a source > of slowdown. And the other is a matter of style: when introducing any other > functionality which needs to perform some cleanup when a widget is > destroyed, will we keep adding scripts to run? > This is still open, maybe we should see the opinion of further Community members. The current implementation is straightforward and works as expected, but I can understand that you would prefer one in C only. > Regards > > Emiliano > Thanks again for your feedback! Best regards, Csaba > [1] Result also show something that looks like O(n^2) when detroying large > number of widgets, for example a frame with several thousand children. But > this has to be investigated independently of the ongoing discussion. > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core -- Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... |
|
From: Eric B. <eri...@gm...> - 2025-09-24 08:10:41
|
Le mer. 24 sept. 2025 à 09:53, Csaba Nemethi <csa...@t-...> a écrit : > Hi Emiliano, > > See my embedded comments below. > ... > > >>> About the implementation: is there any technical advantage to do this > >>> in Tcl and not C? > >>> > >> > >> The implementation in Tcl is much simpler and easier to maintain. > >> Currently it has no more than 228 LOC, of which 81 are comments or empty > >> lines. > > > > Sorry, but I beg to differ on this point. A C implementation is not much > > longer. tkcargo is 466 lines of C code and it actually have more > functionality > > than the one proposed here, using standard Tcl and Tk C API. It is also > way > > faster, mainly when the number of widgets and the number of tables become > > quite large [1]. I've attached four files, three measuring test scripts > and > > a result csv file. The three test scripts are almost the same, one > running > > with plain Tk (not tables) to be the reference value, one with [tk > attribtable] > > and one with tkcargo. They are different as I just want to be sure I was > > testing the right thing and be sure I didn't srew up things. While the > results > > seem somewhat noisy, the tendency is clear. > > > > Also, I'm not comfortable with the modification of Tk_DestroyWindow to > > support this use case, based on two points. First, the cleanup script > > will be forced to run even for widgets that are not in any table, a > source > > of slowdown. And the other is a matter of style: when introducing any > other > > functionality which needs to perform some cleanup when a widget is > > destroyed, will we keep adding scripts to run? > > > > This is still open, maybe we should see the opinion of further Community > members. The current implementation is straightforward and works as > expected, but I can understand that you would prefer one in C only. > > Since you ask... I agree with Emiliano on these two points. This kind of code must be entirely written in C. Invoking a specific script in Tk_DestroyWindow is not the way to go. Also please use spaces in C code instead of tabs for indentation. Regards, Eric |
|
From: Emiliano <emi...@gm...> - 2025-09-24 19:29:46
|
On Wed, 24 Sep 2025 09:52:59 +0200 Csaba Nemethi <csa...@t-...> wrote: > This is still open, maybe we should see the opinion of further Community > members. The current implementation is straightforward and works as > expected, but I can understand that you would prefer one in C only. Fully agree. Thanks for your time and patience! Regards -- Emiliano <emi...@gm...> |
|
From: Csaba N. <csa...@t-...> - 2025-09-25 16:27:39
|
Hi Emiliano, hi Eric, I just want to let you know that I have started to replace the implementation of the "tk attribtable" command using Tcl scripts with one written entirely in C. Thanks to Emiliano's tkcargo package, from which I can reuse several ideas and code fragments, I am making good progress (the set, get, names, and pathnames subcommands already work as expected), but it will take a few more days to get everything ready. Many thanks again for your feedback! Best regards, Csaba Am 24.09.25 um 21:29 schrieb Emiliano: > On Wed, 24 Sep 2025 09:52:59 +0200 > Csaba Nemethi <csa...@t-...> wrote: > >> This is still open, maybe we should see the opinion of further Community >> members. The current implementation is straightforward and works as >> expected, but I can understand that you would prefer one in C only. > > Fully agree. Thanks for your time and patience! > > Regards -- Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... |
|
From: Eric B. <eri...@gm...> - 2025-09-25 16:36:10
|
Hi Csaba, Great ! Many thanks to you for your effort and your acceptance to do it. Eric Le jeu. 25 sept. 2025 à 18:27, Csaba Nemethi <csa...@t-...> a écrit : > Hi Emiliano, hi Eric, > > I just want to let you know that I have started to replace the > implementation of the "tk attribtable" command using Tcl scripts with > one written entirely in C. Thanks to Emiliano's tkcargo package, from > which I can reuse several ideas and code fragments, I am making good > progress (the set, get, names, and pathnames subcommands already work as > expected), but it will take a few more days to get everything ready. > > Many thanks again for your feedback! > > Best regards, > > Csaba > > > Am 24.09.25 um 21:29 schrieb Emiliano: > > On Wed, 24 Sep 2025 09:52:59 +0200 > > Csaba Nemethi <csa...@t-...> wrote: > > > >> This is still open, maybe we should see the opinion of further Community > >> members. The current implementation is straightforward and works as > >> expected, but I can understand that you would prefer one in C only. > > > > Fully agree. Thanks for your time and patience! > > > > Regards > > -- > Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... > > > > _______________________________________________ > Tcl-Core mailing list > Tcl...@li... > https://lists.sourceforge.net/lists/listinfo/tcl-core > |
|
From: Emiliano <emi...@gm...> - 2025-09-26 00:48:34
|
On Thu, 25 Sep 2025 18:27:21 +0200 Csaba Nemethi <csa...@t-...> wrote: > Hi Emiliano, hi Eric, > > I just want to let you know that I have started to replace the > implementation of the "tk attribtable" command using Tcl scripts with > one written entirely in C. Thanks to Emiliano's tkcargo package, from > which I can reuse several ideas and code fragments, I am making good > progress (the set, get, names, and pathnames subcommands already work as > expected), but it will take a few more days to get everything ready. Great. Thanks !! If you need any help, please feel free to contact me. And, if you find any way to make things faster[1], please do. Thanks again for your time and patience!! Regards -- Emiliano <emi...@gm...> [1] Last year, fvogel and I worked on two nasty, unrelated bugs that slow image insertion/deletion times down, resulting in unresponsible GUIs. This kind of slowdowns make Tk look really bad, and anything we can do to fix them are welcome. https://core.tcl-lang.org/tk/tktview/56970b5e7cc993e6dc6d https://core.tcl-lang.org/tk/tktview/b7abf0d8179a7f1fdad9 |
|
From: Csaba N. <csa...@t-...> - 2025-09-26 17:53:41
|
Work completed. Thanks to Emiliano for his high-quality tkcargo implementation, which the tk attribtable code is based on! Best regards, Csaba Am 26.09.25 um 02:48 schrieb Emiliano: > On Thu, 25 Sep 2025 18:27:21 +0200 > Csaba Nemethi <csa...@t-...> wrote: > >> Hi Emiliano, hi Eric, >> >> I just want to let you know that I have started to replace the >> implementation of the "tk attribtable" command using Tcl scripts with >> one written entirely in C. Thanks to Emiliano's tkcargo package, from >> which I can reuse several ideas and code fragments, I am making good >> progress (the set, get, names, and pathnames subcommands already work as >> expected), but it will take a few more days to get everything ready. > > Great. Thanks !! If you need any help, please feel free to contact me. > And, if you find any way to make things faster[1], please do. > > Thanks again for your time and patience!! > > Regards > -- Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... |
|
From: Emiliano <emi...@gm...> - 2025-09-27 00:07:34
|
On Fri, 26 Sep 2025 19:53:23 +0200 Csaba Nemethi <csa...@t-...> wrote: > Work completed. Thanks to Emiliano for his high-quality tkcargo > implementation, which the tk attribtable code is based on! > > Best regards, > > Csaba Great work! Thanks! I have a few remarks, none of them critical. In the attribtable man page, I think the final remark about the entries in the tables being cleared when the widget is destroyed should be before the subcommands description. After all, this is the main selling point of the functionality, IMO. The error result raised by Tcl_WrongNumArgs here https://core.tcl-lang.org/tk/file?ci=6a9c2f6168e06a30&name=generic%2FtkCmds.c&ln=802 is not the same as other tk commands, like the widget themselves. While I have no strong preference, I apply the "when in Rome, do as the romans do" principle. Example using entry: % entry .e .e % .e wrong # args: should be ".e option ?arg ...?" % .e asd bad option "asd": must be bbox, cget, configure, delete, get, icursor, index, insert, scan, selection, validate, or xview In the call to Tk_NameToWindow here https://core.tcl-lang.org/tk/file?ci=6a9c2f6168e06a30&name=generic%2FtkCmds.c&ln=813 the interp argument can be NULL, making the following call to Tcl_ResetResult unnecessary. This is not clear in the docs, and I think it should be fixed there, making it explicit. Finally, there is an interaction between "unset" and "pathnames". When all the names are "unset" and the attributes dictionary becomes empty, the widget is not shown in "pathnames", as if "clear" was called on it. This has the advantage that further "set" calls are faster, and the disadvantage that AttribTableDestroyHandler keep being called for other events that match StructureNotifyMask, so it's a tradeoff decision to remove the entry or not. My (mild) preference would be to remove it, but it's fine as it is. Again, thanks for your time and patience! Regards -- Emiliano <emi...@gm...> |
|
From: Stuart C. <exo...@ya...> - 2025-09-27 09:17:40
|
I think "tkcargo" is fine for a name, and wouldn't be concerned about Rust. It (cargo) is a term/name that's been used for that sort of thing for a long time, in many places. We should feel free to name things as we want and not feel constrained by others. My CDN $0.02. Stu ps. For further bikeshedding, "proptable", "props", and "properties" are shorter. On Friday, September 26, 2025 at 01:53:44 p.m. EDT, Csaba Nemethi <csa...@t-...> wrote: Work completed. Thanks to Emiliano for his high-quality tkcargo implementation, which the tk attribtable code is based on! Best regards, Csaba Am 26.09.25 um 02:48 schrieb Emiliano: > On Thu, 25 Sep 2025 18:27:21 +0200 > Csaba Nemethi <csa...@t-...> wrote: > >> Hi Emiliano, hi Eric, >> >> I just want to let you know that I have started to replace the >> implementation of the "tk attribtable" command using Tcl scripts with >> one written entirely in C. Thanks to Emiliano's tkcargo package, from >> which I can reuse several ideas and code fragments, I am making good >> progress (the set, get, names, and pathnames subcommands already work as >> expected), but it will take a few more days to get everything ready. > > Great. Thanks !! If you need any help, please feel free to contact me. > And, if you find any way to make things faster[1], please do. > > Thanks again for your time and patience!! > > Regards > -- Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... _______________________________________________ Tcl-Core mailing list Tcl...@li... https://lists.sourceforge.net/lists/listinfo/tcl-core |
|
From: Csaba N. <csa...@t-...> - 2025-09-27 11:37:14
|
Hi Stu, Thanks for your feedback! There have been negative comments about using the word "cargo" from Marc, Steve, Emiliano, and (indirectly) Ashok. I have been using the term "attribute" in all my mega-widgets for decades now, and I personally like it more than the word "cargo". Now there seems to be a decision in favor of "attribute" and "tk attribtable", sorry! Best regards, Csaba Am 27.09.25 um 10:57 schrieb Stuart Cassoff via Tcl-Core: > I think "tkcargo" is fine for a name, and wouldn't be concerned about Rust. > It (cargo) is a term/name that's been used for that sort of thing for a long time, in many places. > We should feel free to name things as we want and not feel constrained by others. > > My CDN $0.02. > > > Stu > > ps. For further bikeshedding, "proptable", "props", and "properties" are shorter. > > > On Friday, September 26, 2025 at 01:53:44 p.m. EDT, Csaba Nemethi <csa...@t-...> wrote: > > > > > > Work completed. Thanks to Emiliano for his high-quality tkcargo > implementation, which the tk attribtable code is based on! > > Best regards, > > Csaba > > > Am 26.09.25 um 02:48 schrieb Emiliano: >> On Thu, 25 Sep 2025 18:27:21 +0200 >> Csaba Nemethi <csa...@t-...> wrote: >> >>> Hi Emiliano, hi Eric, >>> >>> I just want to let you know that I have started to replace the >>> implementation of the "tk attribtable" command using Tcl scripts with >>> one written entirely in C. Thanks to Emiliano's tkcargo package, from >>> which I can reuse several ideas and code fragments, I am making good >>> progress (the set, get, names, and pathnames subcommands already work as >>> expected), but it will take a few more days to get everything ready. >> >> Great. Thanks !! If you need any help, please feel free to contact me. >> And, if you find any way to make things faster[1], please do. >> >> Thanks again for your time and patience!! >> >> Regards >> > -- Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... |
|
From: Csaba N. <csa...@t-...> - 2025-09-27 13:13:05
|
Hi Emiliano, Many thanks for your quick feedback! See my embedded comments below. Am 27.09.25 um 02:07 schrieb Emiliano: > On Fri, 26 Sep 2025 19:53:23 +0200 > Csaba Nemethi <csa...@t-...> wrote: > >> Work completed. Thanks to Emiliano for his high-quality tkcargo >> implementation, which the tk attribtable code is based on! >> >> Best regards, >> >> Csaba > > Great work! Thanks! > > I have a few remarks, none of them critical. > > In the attribtable man page, I think the final remark about the entries > in the tables being cleared when the widget is destroyed should be before > the subcommands description. After all, this is the main selling point of > the functionality, IMO. > Good suggestion! Done. > The error result raised by Tcl_WrongNumArgs here > https://core.tcl-lang.org/tk/file?ci=6a9c2f6168e06a30&name=generic%2FtkCmds.c&ln=802 > is not the same as other tk commands, like the widget themselves. While I have > no strong preference, I apply the "when in Rome, do as the romans do" > principle. Example using entry: > % entry .e > .e > % .e > wrong # args: should be ".e option ?arg ...?" > % .e asd > bad option "asd": must be bbox, cget, configure, delete, get, icursor, index, insert, scan, selection, validate, or xview > Instead of the generic word "subcommand" I have written "set|get|unset|clear|exists|names|pathnames" because this in addition enumerates the supported subcommands. Compare this to the following examples: % place wrong # args: should be "place option|pathName args" % canvas .c; .c yview scroll wrong # args: should be ".c yview moveto|scroll args" The "..." in the error message stands for "zero or more additional arguments". An alternative form would be "?arg ...?" (like in the tkcargo code), but this would read: The subcommand can *optionally* be followed by at least one argument. However, this is not quite accurate, because the "pathnames" subcommand mustn't be followed by anything, while all the others expect at least one argument. Now I have replaced the "..." with "args", which suits both cases and is more familiar to the users, since in Tcl it means "zero or more arguments". > In the call to Tk_NameToWindow here > https://core.tcl-lang.org/tk/file?ci=6a9c2f6168e06a30&name=generic%2FtkCmds.c&ln=813 > the interp argument can be NULL, making the following call to > Tcl_ResetResult unnecessary. This is not clear in the docs, and I think it > should be fixed there, making it explicit. > While this is correct, for all but two of the supported subcommands it is important to have the error message in interp, because of the "return TCL_ERROR". > Finally, there is an interaction between "unset" and "pathnames". When all > the names are "unset" and the attributes dictionary becomes empty, the > widget is not shown in "pathnames", as if "clear" was called on it. This was a deliberate decision from me, also because of the manual. It is just an *internal* design decision that the attributes are kept in dictionaries. From the user's point of view it should make no difference whether for a given widget the table contains no dictionary or an empty one instead. With my version the documentation is fully in sync with the code. BTW: We have the same interaction between "unset" and "exists" without the optional "name" argument. > This has the advantage that further "set" calls are faster, and the > disadvantage that AttribTableDestroyHandler keep being called for other > events that match StructureNotifyMask, so it's a tradeoff decision to remove > the entry or not. My (mild) preference would be to remove it, but it's > fine as it is. Your tkcargo implementation doesn't remove the entry either when the dictionary gets empty due to "unset" invocations with at least one name argument. (Instead of tkcargo's "unset" subcommand we now have an "unset" and a "clear", as suggested by Ashok.) > > Again, thanks for your time and patience! > > Regards Best regards, Csaba -- Csaba Nemethi https://www.nemethi.de mailto:csa...@t-... |
|
From: Emiliano <emi...@gm...> - 2025-09-27 16:29:28
|
On Sat, 27 Sep 2025 15:11:04 +0200 Csaba Nemethi <csa...@t-...> wrote: [...] > While this is correct, for all but two of the supported subcommands it > is important to have the error message in interp, because of the "return > TCL_ERROR". You are right! I had a brain fart, sorry. As for the other comments, thanks for taking the time to explain them. I'm completely fine with the current implementation. I have just one pet project that uses tkcargo but now I can use the core implementation. Thanks again for your work !! Regards -- Emiliano <emi...@gm...> |
Thanks for helping keep SourceForge clean.
X