Hello out there,
currently Tk accepts only _gobal_ variables for widgets which set a
value. I always wondered why it doesn't also accept a fully namespaced
variable, too. Like so:
---
namespace eval ns {
variable someVar ""
} ttk::radiobutton .rad -text "Some text" -variable ::ns::someVar
---
If one demanded that always either a global or a _fully namespaced_
variable had to be supplied it would not cause any ambiguities even
when the above call would have been inside the namespace where the
variable 'someVar' already is defined.
Tcl 9 is the opportunity to introduce incompatibilities - although I
wonder if this even IS an incompatibility: In Tcl 8 a syntax like
-var ::ns::someVar
is not illegal: it just doesn't have any effect while in Tcl 9 it
would. But this is probably a question of language semantics which I
am not qualified to judge.
Comments welcome
Helmut

Helmut Giese <hgiese@ratiosoft.com> wrote:
> Hello out there,
> currently Tk accepts only _gobal_ variables for widgets which set a
> value. I always wondered why it doesn't also accept a fully namespaced
> variable, too.

Unless something has changed in 9, Tk has always accepted fully
qualified namespaced variables for Tk widget variables.

I.e.:

$ rlwrap wish
% namespace eval ns {
variable someVar ""
}
% puts $::ns::someVar

% ttk::radiobutton .r1 -text R1 -value R1 -variable ::ns::someVar
.r1
% ttk::radiobutton .r2 -text R2 -value R2 -variable ::ns::someVar
.r2
% pack .r1 .r2 -side top
% puts $::ns::someVar

% # clicks upon r1
% puts $::ns::someVar
R1
% # clicks upon r2
% puts $::ns::someVar
R2
%

The thing is, they do have to be 'fully qualified' (which is something
that is easy to forget).

> In Tcl 8 a syntax like
> -var ::ns::someVar
> is not illegal: it just doesn't have any effect

As I show above, it does. But, for a radio button, you do need to give
each widget a -value or the widget never sets anything into the
variable.

Am 05.11.2024 um 23:34 schrieb Rich:
> Helmut Giese <hgiese@ratiosoft.com> wrote:
>> Hello out there,
>> currently Tk accepts only _gobal_ variables for widgets which set a
>> value. I always wondered why it doesn't also accept a fully namespaced
>> variable, too.
>
> Unless something has changed in 9, Tk has always accepted fully
> qualified namespaced variables for Tk widget variables.
>
> I.e.:
>
> $ rlwrap wish
> % namespace eval ns {
> variable someVar ""
> }
> % puts $::ns::someVar
>
> % ttk::radiobutton .r1 -text R1 -value R1 -variable ::ns::someVar
> .r1
> % ttk::radiobutton .r2 -text R2 -value R2 -variable ::ns::someVar
> .r2
> % pack .r1 .r2 -side top
> % puts $::ns::someVar
>
> % # clicks upon r1
> % puts $::ns::someVar
> R1
> % # clicks upon r2
> % puts $::ns::someVar
> R2
> %
>
> The thing is, they do have to be 'fully qualified' (which is something
> that is easy to forget).
>
>> In Tcl 8 a syntax like
>> -var ::ns::someVar
>> is not illegal: it just doesn't have any effect
>
> As I show above, it does. But, for a radio button, you do need to give
> each widget a -value or the widget never sets anything into the
> variable.
>

I think, the idea by Helmut is a bit different.
The idea is, that the command does a lookup in the caller namespace and
resolves the namespace within this scope.

E.g. the request is to have the following "namespace which"
automatically included into the command:
namespace eval ns {
variable someVar ""
ttk::radiobutton .r1 -text R1 -value R1 -variable [namespace which
-variable someVar]
}

This is a sensible request.
Unfortunately, currently, it does not work like that.
Currently, it is possible to revert the order, of widget and varible
creation:

ttk::radiobutton .r1 -text R1 -value R1 -variable someVar]
variable someVar ""

Or it is even possible to use a non-existing variable.
For example, ttk::checkbutton is set to the alternate state, if the
variable does not exist.

Helmut, I can understand the request. It would be handy.
It specially gets handy for oo widgets.
Sorry, Helmut, without a big redesign, this would not work due to many
incompatibilites.
In the mean time, it is good practice to always use [namepscpace which
-variable someVar] in the function call.
If you like, you may do a function for your own, which does this (untested):

proc myradiobutton {path args} {
if {[dict exist $args -command]} {
dict set args -commmand [uplevel 1 [namepsace which -variable [dict
get $args -command]]]
}
tailcall ttk::radiobutton $path {*}$args
}

Thank you for all,
Harald

Hello,
many thanks to both of you for responding. I am sorry to not having
reacted sooner but I was pretty sick (thank you Covid :( ).
@Rich: Your demo was quite convincing. Still, I'm sure that whenever I
tried it in the past it always failed - too late to find out why and
not really important.
@ Harald: Too much honor - my question was what Rich assumed. To tell
the truth: It took me quite a while to even understand what you
assumed I had meant - I am much simpler minded :)
Have a nice weekend
Helmut

Am 16.11.2024 um 13:39 schrieb Helmut Giese:
> Hello,
> many thanks to both of you for responding. I am sorry to not having
> reacted sooner but I was pretty sick (thank you Covid :( ).
> @Rich: Your demo was quite convincing. Still, I'm sure that whenever I
> tried it in the past it always failed - too late to find out why and
> not really important.
> @ Harald: Too much honor - my question was what Rich assumed. To tell
> the truth: It took me quite a while to even understand what you
> assumed I had meant - I am much simpler minded :)
> Have a nice weekend
> Helmut

Good health to you !
What Rich proposes works.

Yes, no problem.
If you want it "simple", you may use the proposed way:

-variable [namespace which -variable someVar]

which cares to add the namespace resolution.

Take care,
Harald