1. Forum
  2. Newsgroups
  3. comp.lang.tcl

  • private option for widgets

    From Manfred Stelzhammer@manfred@antispam.at to comp.lang.tcl on Wed Oct 8 20:27:37 2025
    From Newsgroup: comp.lang.tcl

    Hi

    What you think about one (or more) private options for a widget to store information on a widget.

    Maybe to store the object which created the widget.
    This private option should not influence the widget.
    It's only like a variable.

    The name could be "private" or "store" or "myoption" or something else.

    ttk::button .bu -text nix -private "object0815"

    And with ".bu cget -private" I get the information.

    Could this be usefull?

    regards

    Manfred






    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Emiliano@emiliano@example.invalid to comp.lang.tcl on Wed Oct 8 17:22:54 2025
    From Newsgroup: comp.lang.tcl

    On Wed, 8 Oct 2025 20:27:37 +0200
    Manfred Stelzhammer <manfred@antispam.at> wrote:

    Hi

    What you think about one (or more) private options for a widget to store information on a widget.

    Maybe to store the object which created the widget.
    This private option should not influence the widget.
    It's only like a variable.

    The name could be "private" or "store" or "myoption" or something else.

    ttk::button .bu -text nix -private "object0815"

    And with ".bu cget -private" I get the information.

    Could this be usefull?

    This issue is addressed in TIP 729

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

    This TIP is currently being voted and, should it be accepted, it will
    be in Tk 9.1 (next release).

    There are two older TIP which tries to address the same subject:
    369 and 349

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

    These proposals have the same drawback: all widgets, both core and
    third-party, must be modified to support this option or subcommand.

    The advantage of the TIP 729 proposal is twofold: it can be applied to
    any widget without modification, and different packages can have their
    own private attribute tables with whatever data they define without
    any name clashes. When the widget is destroyed, all related data is
    cleaned up from all attribute tables.

    Regards
    --
    Emiliano <emiliano@example.invalid>
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From meshparts@alexandru.dadalau@meshparts.de to comp.lang.tcl on Thu Oct 9 09:24:28 2025
    From Newsgroup: comp.lang.tcl

    Am 08.10.2025 um 20:27 schrieb Manfred Stelzhammer:
    Hi

    What you think about one (or more) private options for a widget to store information on a widget.

    Maybe to store the object which created the widget.
    This private option should not influence the widget.
    It's only like a variable.

    The name could be "private" or "store" or "myoption" or something else.

    ttk::button .bu -text nix -private "object0815"

    And with ".bu cget -private" I get the information.

    Could this be usefull?

    regards

    Manfred






    Good idea!
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Christian Gollwitzer@auriocus@gmx.de to comp.lang.tcl on Thu Oct 9 09:36:47 2025
    From Newsgroup: comp.lang.tcl

    Am 08.10.25 um 20:27 schrieb Manfred Stelzhammer:
    Hi

    What you think about one (or more) private options for a widget to store information on a widget.

    Maybe to store the object which created the widget.
    This private option should not influence the widget.
    It's only like a variable.

    The name could be "private" or "store" or "myoption" or something else.

    ttk::button .bu -text nix -private "object0815"

    And with ".bu cget -private" I get the information.

    That would be a fairly trivial snit::widgetadaptor which you can apply
    to any widget.

    package require Tk
    package require snit

    ::snit::widgetadaptor datastore {

    constructor {args} {
    installhull $win
    $self configurelist $args
    }

    option -datastore {}

    delegate method * to hull
    delegate option * to hull
    }

    ttk::button .bu -text nix
    datastore .bu
    .bu configure -datastore "Whatever"
    puts [.bu cget -datastore]

    Christian
    --- Synchronet 3.21a-Linux NewsLink 1.2
  • From Manfred Stelzhammer@manfred@antispam.at to comp.lang.tcl on Thu Oct 9 18:18:30 2025
    From Newsgroup: comp.lang.tcl

    Ok

    I see, the idea isn't new.


    regards

    Manfred



    Am 08.10.25 um 22:22 schrieb Emiliano:
    On Wed, 8 Oct 2025 20:27:37 +0200
    Manfred Stelzhammer <manfred@antispam.at> wrote:

    Hi

    What you think about one (or more) private options for a widget to store
    information on a widget.

    Maybe to store the object which created the widget.
    This private option should not influence the widget.
    It's only like a variable.

    The name could be "private" or "store" or "myoption" or something else.

    ttk::button .bu -text nix -private "object0815"

    And with ".bu cget -private" I get the information.

    Could this be usefull?

    This issue is addressed in TIP 729

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

    This TIP is currently being voted and, should it be accepted, it will
    be in Tk 9.1 (next release).

    There are two older TIP which tries to address the same subject:
    369 and 349

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

    These proposals have the same drawback: all widgets, both core and third-party, must be modified to support this option or subcommand.

    The advantage of the TIP 729 proposal is twofold: it can be applied to
    any widget without modification, and different packages can have their
    own private attribute tables with whatever data they define without
    any name clashes. When the widget is destroyed, all related data is
    cleaned up from all attribute tables.

    Regards


    --- Synchronet 3.21a-Linux NewsLink 1.2