Schnexel (May 5 2009) Is it possible to have Tk8.5 radio/checkbuttons in menus that are recognizable as such even if not checked? (And without much change to old 8.4 code)
Unlike with Tk8.4 I can no longer discern a menu checkbox if unchecked, because the box is missing. That lost box is lost information.
(I know the new design is regarded standard "good" GUI practice, but... For me it is yet another classic IT ridiculousity (like not having a NULL value for boolean data in that infamous SQL thing, or, like placing a wheel on an important mouse button, etc.).)
I know from experience the problem/complaint is a bit too subtle to readily comprehend. Or, the ridiculousity of said innovation is too hard to accept. Still, let me try to explain:
A GUI should be as self-explanatory as possible. I assume intelligent and courageous users who don't want to waste their time with wondering "what is this" or with wading thru stupid helpfiles, reading 90% irrelevant stuff. My users instead just try the damn thing out.
Often a little (even if perhaps redundant) hint can help see at first glance what a menu is about, e.g. by subconsciously reasoning: "Ah, this menu entry is not a command but a switch (so it won't hurt if I klick it)." or, "Ah, here's a list of values, and the empty value is checked."
Dear GUI graphics designers: You don't help the user with hiding information just because it might look inelegant or scary (like that wrinkly empty checkbox frame, which could remind the user there's something to check). Note to the marketeers: At the end, a gadget is to be used, not just marveld at for it's elegant looks.
So, please give me back the empty checkbox visual...
ZB ...but if so, perhaps make it optional, please. In my opinion a difference "option <-> command" should be easily recognizable just from the context (from menu point description). That newer look is quite pleasant to me.
MG What OS are you running on? On my Windows system (which uses the same native menu code between 8.4/8.5), checkbutton menu entries have never shown a box, there's just a tick when it's selected/on and nothing when it's off.
ZB If you mean me: I'm running Linux, and the behaviour is exactly the same - and I would to keep it work this way.
Schnexel ZB, shure, optimally optional. But I'm sorry methinks you offer just an excuse, and excuses tend to make bad constructs worse. In this case, it's the superfluous need to add superfluous context, which is a waste of time and patience on the programmer's as well as the user's side. Not that I didn't expect to get excuses here :-)
MG, I don't even have Windows. (I use a system where the plural in windows is apt: Fvwm-Linux.) Why am I not surprised that the non-box iconology is a windoze invention? Counterproductive oversimplification is a Windows classic (don't scare first users, look trumps functionality). And the poor Linuxers seem to think they need to follow this gaga. But I stopped wondering when they started happily ritscheratsching the microsofty mousebuttonwheel.
ZB No, it wasn't any excuse; in my opinion, it really looks better. Personally I had no problem with "boxless" option menu entries - but I'm not opposed to introducing variant "with boxes", only wanting to make it optional, in case it will really get introduced. Personally I prefer current solution; box in menu entry looks like a hole, or kind of perforation... present "look & feel" is better to me - but I'm aware, it's a matter of taste.
Schnexel I can actually understand that for many tastes (perhaps even mine) the boxless variant has better "look & feel". However, methinks to hide information for the sake of look & feel is very bad (yet classic Homo "Sapiens") engineering. (A paradigmatic example is the Windows file browser hiding file extensions, which opened an easy door for virus.)
So, is there actually really no simple way to get back the boxed look?