checkbuttons in tcl 8.4.12 and 8.5a4 with -offvalue == ""?
MartinLemburg@UGS
I just realized some differences between the checkbuttons visualisation
in tcl 8.4 and 8.5.
If the offvalue of a checkbutton is set to "" (empty string) and the
checkbutton is not "checked", than ...
- in tcl 8.4.12 the background is white
- in tcl 8.5a4 the background is grey and the "check" is still
visible
That's a bug, isn't it?
If the offvalue is " " (one blank), than every thing works.
Best regards,
Martin Lemburg
UGS - Transforming the Process of Innovation
Bryan Oakley
> Hello,
>
> I just realized some differences between the checkbuttons visualisation
> in tcl 8.4 and 8.5.
>
> If the offvalue of a checkbutton is set to "" (empty string) and the
> checkbutton is not "checked", than ...
> - in tcl 8.4.12 the background is white
> - in tcl 8.5a4 the background is grey and the "check" is still
> visible
>
> That's a bug, isn't it?
>
It's a much sought-after new feature. Checkbuttons in tk 8.5 have the
ability to have three states: on, off and "tristate".
The default value for the third state is the empty string. It's
documented in the 8.5 manual page; look for the -tristatevalue option:
MartinLemburg@UGS
tristate value usage was chosen!
If I have an offvalue "" and a tristatevalue "", than the tristate
appearance is prefered over the off appearance?
So I always have to set the tristatevalue to someting "impossible", if
the value of a checkbutton could be variable, even "", or if one of the
state values is ""?
Sounds for me a bit awkward!
Donal K. Fellows
> Hhm, ... ok I know now why, but I don't understand why this way of
> tristate value usage was chosen!
The default values of on-value and off-value are 1 and 0 respectively
(i.e. booleans) so what to use for something that is neither? The empty
string is as good as any (and better than most).
> If I have an offvalue "" and a tristatevalue "", than the tristate
> appearance is prefered over the off appearance?
Looks like pilot error to me. :-) Don't set two of the values to the
same thing, or you cease to be in the domain of behaviour that we specify.
> So I always have to set the tristatevalue to someting "impossible", if
> the value of a checkbutton could be variable, even "", or if one of the
> state values is ""?
>
> Sounds for me a bit awkward!
But it's a checkbutton! In all classical use its value will be
consistently one of two things, the on- or the off-value. What on earth
are you doing that is setting a checkbutton's variable to more than two
values without the third one being some kind of tristate value? How are
you coping with users clicking on buttons and forcing them away from
those magic values? Right now, you're encouraging me to just tell you
"tough luck". (Radiobuttons are something different here, even though
they are just about identical mechanically.)
Donal.
MartinLemburg@UGS
I just reviewed the visual_regexp application from Laurent Riesterer
and I tried to wrap into a starpack.
There I realized the first time, that checkbuttons have now three
states.
In visual_regexp there is the offvalue of some configurational
checkbuttons an empty string, to be used later on in the evaluated
regexp command.
I never touched the tristatevalue, but now I set the tristatevalue to
something else then "", something visual_regexp won't set into the
offvalue.
My thoughts are about the preference the third state takes over the off
state.
For backward compability it would have been nice, to have no need to
care for the tristate value, because if the offvalue and the
tristatevalue are equal, the offvalue appearance would have had the
preference.
So I have to change the behaviour or the configuration of the
checkbuttons unnecessarily. (IHMO)
Andreas Leitgeb
> For backward compability it would have been nice, to have no need to
> care for the tristate value, because if the offvalue and the
> tristatevalue are equal, the offvalue appearance would have had the
> preference.
Not only "nice" but even "necessary".
Good luck, tk is still in alpha, so changing
this should principially be possible.
Any application that used an offvalue "" before (which really
isn't all that exotic), would have to be changed (to add a
-tristatevalue "anything"), just to *not* change behaviour.
Of course the new option isn't accepted by older tcl/tk, so
one even needs a check on the tcl/tk version :-(((
If this isn't an "incompatible change", what is?
If on the other hand the tristatevalue was defined to
step behind the on- or off- values, then its ok,
because tristatevalue-nonaware scripts just happily
continue to work&look-right unchanged.
Btw., additionally, I wonder why the third state displays
as checked (though grayed) when indicatoron is true,
but more like unchecked (raised) when the indicatoron
is false.
I'd prefer a real third state, e.g. a flat relief, or
some semi-filled indicator (depending on -indicatoron).
No item should appear disabled when in fact it isn't!
Donald Arseneau
> MartinLemburg@UGS wrote:
> > If I have an offvalue "" and a tristatevalue "", than the tristate
> > appearance is prefered over the off appearance?
>
> Looks like pilot error to me. :-) Don't set two of the values to the
> same thing, or you cease to be in the domain of behaviour that we specify.
Looks like language designer error to me! Martin did NOT set two values
but inherited the default "" value for the sneaky new tristate option.
Unspecified domains are almost always a mistake of the language design.
It is probably time to define an order of preference in the case of
identical values, also defining the state implied by no match. I
suggest on,off,tristate,off as the order of preference.
> > So I always have to set the tristatevalue to someting "impossible", if
> > the value of a checkbutton could be variable, even "", or if one of the
> > state values is ""?
> > Sounds for me a bit awkward!
>
> But it's a checkbutton! In all classical use its value will be
> consistently one of two things, the on- or the off-value. What on earth
> are you doing that is setting a checkbutton's variable to more than two
> values without the third one being some kind of tristate value?
Why on earth was a third value added to the widget design? Why on earth
was that new feature allowed to interfere with normal on-or-off function?
--
Donald Arseneau as...@triumf.ca
Donald Arseneau
> I just realized some differences between the checkbuttons visualisation
> in tcl 8.4 and 8.5.
Hmmm... I don't get any clear picture from the TIP or the TclCore archive
what need this new -tristate feature is intended to fill. The TIP's
rationale is jargo-sales-speak:
In order to meet more demanding requirements of todays complex graphical
user interfaces...to be able to display a third state, i.e., both On and Off.
I don't understand how something is both On and Off, and the explanation
doesn't help me:
This indicates the situation where a property has a particular value
for some members of a selection set, but not others.
The greatest utility for a third state that I can identify is a visual
representation for the unknown state, when the value matches neither the
On nor Off values. Unfortunately, the new -tristate does not satisfy
that need, because it uses a particular value.
A third, specific, state for the checkbutton could still be useful for
some things. However, I see no utility for a tri-state radiobutton.
--
Donald Arseneau as...@triumf.ca
Roy Terry
news:yfioe0o...@triumf.ca...
> "MartinLemburg@UGS" <martin.le...@gmx.net> writes:
>
> > I just realized some differences between the checkbuttons visualisation
> > in tcl 8.4 and 8.5.
>
> Hmmm... I don't get any clear picture from the TIP or the TclCore archive
> what need this new -tristate feature is intended to fill. The TIP's
> rationale is jargo-sales-speak:
>
> In order to meet more demanding requirements of todays complex graphical
> user interfaces...to be able to display a third state, i.e., both On and
Off.
>
> I don't understand how something is both On and Off, and the explanation
> doesn't help me:
>
> This indicates the situation where a property has a particular value
> for some members of a selection set, but not others.
>
>
> The greatest utility for a third state that I can identify is a visual
> representation for the unknown state, when the value matches neither the
> On nor Off values. Unfortunately, the new -tristate does not satisfy
> that need, because it uses a particular value.
not with an unknown value.
>
> A third, specific, state for the checkbutton could still be useful for
> some things. However, I see no utility for a tri-state radiobutton.
I believe the third state is intended to fill needs such as during
an install component selection process such as.
1) The check represents a bunch of lower level "leaf" options
some of which are on and some off
2) Check is on but not changeable due to higher level
choices when force it to be checked.
These are somewhat guesses just based on examples of
typical features I've noticed on Windows GUIs.
I expect you will not find them valid and that's OK with
me. But I do believe the TIP implementors had a valid and
positive reasons for the change perhaps not well captured
in the TIP. I expect to eventually make use of the feature.
>
> --
> Donald Arseneau as...@triumf.ca
Bryan Oakley
>
> Why on earth was a third value added to the widget design? Why on earth
> was that new feature allowed to interfere with normal on-or-off function?
>
>
The second part of the question is easy to answer: it's alpha software.
That means the code isn't feature complete or fully debugged.
Fortunately, these sorts of reports are exactly why alphas are released
-- to see what sort of problems crop up that weren't envisioned by the
author.
In this instance, the case where the user sets the -on or -off value to
the same as the default for the -tristate option wasn't properly
accounted for.
Now, for the first part of the question...
The third value is necessary for a particular set of problems. For
example, imagine a checklist that lets you turn the display of layers on
a canvas on and off. For example, it may start out in this state where
nothing is selected:
[ ] Cars
[ ] Convertibles
[ ] Sedans
[ ] Coupes
[ ] Trucks
...
If you check the "Cars" box it automatically selects convertibles,
sedans and coupes.
[x] Cars
[x] Convertibles
[x] Sedans
[x] Coupes
[ ] Trucks
...
Now, uncheck Sedans. What is the state of "Cars"?
[?] Cars
[x] Convertibles
[ ] Sedans
[x] Coupes
[ ] Trucks
...
It can't be checked since checked implies everything below is checked.
It can't be unchecked since that implies everything below is unchecked.
Hence, the need for a third state.
This sort of thing is somewhat common in installers, for example, where
you can quickly select a whole package (eg: tcllib) or a subset (eg:
just SNIT).
MartinLemburg@UGS
should I file a bug on sourceforge?
Or does this discussion is enough to start an action or to think over
this thing?
Thanks and a happy weekend!
Martin Lemburg
UGS - Transforming the Process of Innvoation
Donald Arseneau
> Now, uncheck Sedans. What is the state of "Cars"?
>
> [?] Cars
> [x] Convertibles
> [ ] Sedans
> [x] Coupes
> [ ] Trucks
> This sort of thing is somewhat common in installers, for example, where you
> can quickly select a whole package (eg: tcllib) or a subset (eg: just SNIT).
Thanks. I think the cygwin package selection looked like that, but I don't
remember if they had special icons for intermediate/tristate/... selections.
I think there are several possible variations on "neither here nor there"
and it would indeed be useful to have a representation when one crops up.
--
Donald Arseneau as...@triumf.ca
Donald Arseneau
> "Donald Arseneau" <as...@triumf.ca> wrote in message
> > The greatest utility for a third state that I can identify is a visual
> > representation for the unknown state, when the value matches neither the
> > On nor Off values. Unfortunately, the new -tristate does not satisfy
> > that need, because it uses a particular value.
> How would you request displaying the "unknown state"? Certainly
> not with an unknown value.
Certainly yes! Until now, the checkbutton is displayed with its "off"
appearance for any value except the onvalue. This is documented:
"automatically selects and deselects itself when the
variables value changes to and from the button's
``on'' value."
As such, the offvalue has no relevance for the visual display.
But it would often be useful to distinguish between the selected
offvalue and all other bogus values.
> > A third, specific, state for the checkbutton could still be useful for
> > some things. However, I see no utility for a tri-state radiobutton.
>
> I believe the third state is intended to fill needs such as during
> an install component selection process such as.[...]
>
> I expect you will not find them valid and that's OK with me.
It sounds good to me too, although I am still at a loss for
a radiobutton application.
--
Donald Arseneau as...@triumf.ca
bria...@easystreet.com
If I didn't know better, I would swear that you've never used a
computer before!
I'll give you an example of tri-state check button outside of Tk. You
can do this regardless of which OS you're using; it's valid on Mac OS
X, KDE, and XP:
Open a file explorer
(XP: explorer, OS X: finder, KDE: konqueror).
Select a single file and using the RMB popup menu,
select "Properties".
(OS X, it's "Get Info" from the File pulldown if you
don't have a 3-button mouse)
Somewhere in the properties dialog box you'll find check
button(s) that represent some permission state of the
file (read-only, execute, etc.).
Now, select a different file and repeat. Same thing.
Now make a change so that you have two files with different,
say, read-only settings: one is read-only, and the other is not.
Next, select both files (Yes, multiple selection).
Open the properties dialog.
The dialog box on a multiple selection will display the property state
of all the selected items with a single checkbutton. If they are all
checked, it shows checked. If they are all unchecked, it shows
unchecked. If, however, some are checked and some aren't, the button
shows Tri-State. But here's the most important part: clicking on the
checkbutton will change the state of ALL items. This is a feature!
The general idea is that the checkbutton represents the state of an
object. The object comes from a set of objects. For convenience and
power, multiple selection is also represent with the single button.
The "power" part comes from the ability to act on the multiple
selection using the single button.
This is why the checkbutton was changed. It's not difficult to see how
the radiobutton can apply to multiple selection as well.
I will concede that the choice of "" as the default tristate value is
probably not ideal and it's not too late to change this. You can also
easily work around this with:
option add *Checkbutton.tristateValue "NONE"
So you don't have to edit each instance of the checkbutton.