Description: The language checkbox doesn't act like a checkbox... Steps to Reproduce: 1. go Tools / Language / For selection 2. check a language 3. go Tools / Language / For selection 4. try to uncheck that language Actual Results: You can't You have to click another language or "none" in order to uncheck it... Expected Results: Checkbox behavior (clicking on it toggles its state, now it's checked, now it's unckecked) Reproducible: Always User Profile Reset: No Additional Info: [Information automatically included from LibreOffice] Locale: en-US Module: TextDocument [Information guessed from browser] OS: Linux (All) OS is 64bit: yes
What is the goal of being able to uncheck that? Just for some "purity" concept? The checkmark is an clear metaphor; and at the same time, there is no "unset language" state for any text. It may be "none" special language, or any other of thousands of valid languages (even those not present in the "quick" list; even those that LibreOffice doesn't know). But no "unset language" (see bug 160248). So - this expectation aims to what specific result?
@Mike: I suppose the reporter means it rather should be a radio button instead of a checkbox. A bit like in a form: - if we got radio buttons, 1 of them (not less, not more) must be selected and you can "unselect" one, you must select another one. - if we got checkboxes, we can have 0, 1 or several checked and they can be unchecked if needed. BTW, "Tools/Language/For Selection" works but "Tools/Language/For Paragraph" and "Tools/Language/For All Text" don't work, checkboxes stay unchecked whereas I checked one of them. Either I missed something or I should submit a bugtracker.
(In reply to Julien Nabet from comment #2) I kind of figured that. However, the *checkbox* is a better metaphor; it has some generic meaning, not limited to UI, and so is very suitable for some *loose* "this is chosen" concept, while a radio button is very specific to UI (and is bound to "**complete** set of mutually exclusive options"). So I still disagree with radio button being a better choice here, where the set is not complete, and the checkmark is mostly informative.
(In reply to Mike Kaganski from comment #3) > (In reply to Julien Nabet from comment #2) > > I kind of figured that. However, the *checkbox* is a better metaphor; it has > some generic meaning, not limited to UI, and so is very suitable for some > *loose* "this is chosen" concept, while a radio button is very specific to > UI (and is bound to "**complete** set of mutually exclusive options"). So I > still disagree with radio button being a better choice here, where the set > is not complete, and the checkmark is mostly informative. I understand. Perhaps the "checked checkbox" should be grayed to show explicitely we can't uncheck it?
(In reply to Julien Nabet from comment #4) > (In reply to Mike Kaganski from comment #3) > > (In reply to Julien Nabet from comment #2) > > > > I kind of figured that. However, the *checkbox* is a better metaphor; it has > > some generic meaning, not limited to UI, and so is very suitable for some > > *loose* "this is chosen" concept, while a radio button is very specific to > > UI (and is bound to "**complete** set of mutually exclusive options"). So I > > still disagree with radio button being a better choice here, where the set > > is not complete, and the checkmark is mostly informative. > > I understand. Perhaps the "checked checkbox" should be grayed to show > explicitely we can't uncheck it? If it would be gray, the user might think they can't check any box in that submenu.
Mutual exclusive items require radio buttons. Not being able to uncheck a checkbox makes the function feel broken. Since one of the radio buttons need to be active we should add None to the selection.