If they are really on/off yes/no options (eg "Show Detail") then I would
use a check box in the menu. If it is switching between two modes
("Simple", "Detailed") then I'd change the text of the option.

I think the use of regular menu items doesn't work in this situation.

As long as you only have a few options like these then menu items are
fine. What I find frustrating is if one needs to set a number of these
options at the same time. Placing them in a menu requires the user to
navigate to the options one by one as clicking on the menu option closes
the menu. For anything over 3 options I would place them in a settings
form and access this through a menu item which I would find far more
user friendly.

Ed!

The thing that drive me nuts are programs that have a button with
label like "italics".

Does this mean we are IN italics mode now, or does it mean click to GO
into italics mode.

I like a check mark that indicates the current boolean state.  It is
unambiguous.

In FontShower for Swing at http://mindprod.com/applet/fontshower.html
I used an italic button, that goes blue when you are in italic state.
This is not as clear, but it uses less space.  You also get visual
feedback in other ways about the button state.

For two different states e.g read/write, I use a pair of radio
buttons.   See http://mindprod.com/applet/fileio.html

Changing text on a single button would have the IN/GOTO ambiguity.  I
can't think of how to avoid it.  Perhaps it is tolerable on a program
people will use daily, but not on one that people will use just once.

The standard metaphor is to use check boxes in this case.

For grouped items of which only one can be checked, use radio buttons.

Changing text in general is not so good since you remember what menu
items do by position AND by value.
--
Claus Dragon <clauskick@mpsahotmail.com>
=(UDIC)=
d++ e++ T--
K1!2!3!456!7!S a27
"Coffee is a mocker. So, I am going to mock."

- Me, lately.