ttk::combobox / why combined option -state?

Why do some ttk widgets, e.g. combobox, have a combined option "-state normal | readonly | disabled"?
I think it should be more like this: "-state enabled | disabled -readonly true | false".

Torsten

On Friday, August 3, 2012 3:20:37 PM UTC-7, Torsten wrote:
> Why do some ttk widgets, e.g. combobox, have a combined option "-state normal | readonly | disabled"?
>
> I think it should be more like this: "-state enabled | disabled -readonlytrue | false".
>
>
>
> Torsten

First of all, many Tk widgets have a -state with value normal | disabled. Ttk simply generalizes this; and further, Ttk widget appearance and configuration is scripted (take a look at the style engine some time, and the Tcl code that forms part of the Ttk library), and the -state option is key in this process. You can actually define arbitrarily many states for a particular widget instance, and have it change its appearance (i.e., the bitmap displayed by a ttk::label) depending on the -state. In short, it's a generalpurpose mechanism.

When I change the status from "readonly" to "disabled" I have to remember the previous state
somewhere else. I can not simply use "enabled", the natural "partner" of "disabled".
The point is, that different states are not independent of each other although they affect different
and independent aspects. Toggling between enabled/disabled should not affect the readonly status.
Allowing arbitrarily many states makes it even worth.

Torsten

Hi Torsten,

Am 04.08.12 09:15, schrieb Torsten:
> When I change the status from "readonly" to "disabled" I have to
> remember the previous state somewhere else. I can not simply use
> "enabled", the natural "partner" of "disabled".

But you can use "!disabled", see below

> The point is, that different states are not independent of each other
> although they affect different and independent aspects. Toggling between
> enabled/disabled should not affect the readonly status. Allowing
> arbitrarily many states makes it even worth.

I think, you misunderstood, how the states work. In fact, readonly and
disabled are distinct flags, that can be set independently. The state is
actually a list.

Try this:

Sources) 64 % ttk::combobox .c
..c
(Sources) 65 % .c state
(Sources) 66 % .c state readonly
!readonly
(Sources) 67 % .c state
readonly
(Sources) 68 % .c state disabled
!disabled
(Sources) 69 % .c state
disabled readonly
(Sources) 70 % .c state !disabled
disabled
(Sources) 71 % .c state
readonly
(Sources) 72 %

Christian

Torsten asked:
>
> Why do some ttk widgets, e.g. combobox, have a combined option
> "-state normal | readonly | disabled"?

The only reason any ttk::* widgets have a -state option at all
is for compatibility with the corresponding core widget.
It is considered deprecated in favor of the 'state' widget method
(see <URL: http://tmml.sourceforge.net/doc/tk/ttk_widget.html >,
section "WIDGET STATES").


> I think it should be more like this: "-state enabled | disabled
> -readonly true | false".

That's essentially how ttk::* widget states work. Instead of
an enumerated -state value {normal|disabled|readonly|active|...}
as found in various core widgets, there are a half-dozen or
so independent state flags.


--Joe English

Torsten wrote:
>
> When I change the status from "readonly" to "disabled" I have to
> remember the previous state somewhere else.

That's precisely why ttk::*'s state mechanism was introduced.

> I can not simply use
> "enabled", the natural "partner" of "disabled".

Use [$w state disabled] to disable, [$w state !disabled] to enable.
This will only affect the disabled/enabled state flag, leaving
all others unchanged.

See <URL: http://tmml.sourceforge.net/doc/tk/ttk_widget.html >,
section "WIDGET STATES".


--Joe English