Description: UI: The No List button constantly highlighted when no some text isn't a list Steps to Reproduce: 1. Open Writer 2. Look in the toolbar.. the no list button is highlighted Actual Results: The list button shows being 'activated' Expected Results: Well in the regular toolbar everything is 'normally' turned off, except for alignment.. A document has no lists, except if you turn then on, so obvious something not a list. The list button will highlight if something being a list, no need having no list also being stated out And well I expect "No list' a button to remove a List, not a 'state' which can be turned on/off Reproducible: Always User Profile Reset: No Additional Info: Version: 7.4.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 4659fc2f0a7223a89446edff0b77e58758b5edf5 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: en-US (nl_NL); UI: en-US Calc: CL
(In reply to Telesto from comment #0) > Well in the regular toolbar everything is 'normally' turned off... There are some "exceptions" actually all mutually exclusive options. And whether the paragraph has assigned a list or not is such a property. Having it as a one-shot function to "clear list attributes" makes the function a bit unaligned with the two list types we offer next to it. => NAB
(In reply to Heiko Tietze from comment #1) > (In reply to Telesto from comment #0) > > Well in the regular toolbar everything is 'normally' turned off... > > There are some "exceptions" actually all mutually exclusive options. And > whether the paragraph has assigned a list or not is such a property. Having > it as a one-shot function to "clear list attributes" makes the function a > bit unaligned with the two list types we offer next to it. => NAB That's part of the problem. No List is actually being intended as Clear list :-) (how I perceive it). It caries the wrong label (no clue why No List got picked...) By calling the button 'No list' you are - verbally - creating a mutually exclusive option.. Which in practically isn't there. It isn't even an toggle. A toggle button - No list - suggest you you can it turn it off (activating a list), but this isn't possible. Next is simply counter intuitive.. Mostly you toggle stuff on to divert from the default. Here the default is 'no List' and you have button, toggled on to disable the list (hard to wrap you head around). The current implementation kind of suggest the whole document being a list, except if 'No list is activated' And empty document has 'no list' (except of some unusual default style). Also "No list' toggled 'ON' does actually isn't doing anything to the document. It isn't adding some 'DF attribute'. The unalignedness not really problem, IMHO..
I believe OP is asking for a change in UI design rather than reporting a bug. As Heiko points out, there are some mutually-exclusive options in which one is always selected. But - let's look at what those are: Direction: RTL, LTR. Alignment: Left, Right, Center, Justified. (that's what I have right now on my Formatting bar) and then we have: Bulleted List, Numbered List, No List Do you see the difference? The other mutually-exclusive state all have positively-defined values, with a meaning in themselves. "Nothing" is not one of the options. It _is_ a bit strange and unexpected to have a "nothing" option in a pressed/selected state. I would actually prefer to see only _two_ buttons: Bulleted List and Numbered List (and perhaps also category indicator list, see my bug #148479), where by default none of them is pressed; and pressing one depresses the authors. I don't have a very strong opinion about this, but it's definitely not NOTABUG.
The topic was on the agenda of the design meeting. The No List function was added with https://gerrit.libreoffice.org/c/core/+/108841 for bug 92622 and bug 115965. Some good arguments in these tickets. We could remove it from the toolbar sw/uiconfig/swriter/toolbar/textobjectbar.xml, or just hide it.
(In reply to Heiko Tietze from comment #4) > The topic was on the agenda of the design meeting. > > The No List function was added with > https://gerrit.libreoffice.org/c/core/+/108841 for bug 92622 and bug 115965. The first one is about the context menu, which is a different kettle of fish and not up for removal. > Some good arguments in these tickets. Couldn't find such good arguments in bug 115965.
(In reply to Heiko Tietze from comment #4) > The topic was on the agenda of the design meeting. > > The No List function was added with > https://gerrit.libreoffice.org/c/core/+/108841 for bug 92622 and bug 115965. > Some good arguments in these tickets. > > We could remove it from the toolbar > sw/uiconfig/swriter/toolbar/textobjectbar.xml, or just hide it. A) Removing No List from the toolbar would remove my 'sting' B) In principle the 'No list' is wrong. There is no Disable No-List feature. the no List being 'enabled' by default (but does nothing). And the possibility to disable a list, by clicking the button again (no list has no value). However I do get the issue at bug 115965. Unordered list/Unordered list are mutual exclusive. Radio button focus on the mutual exclusiveness. Checkbox focuses on the on/off aspect (toggle ordered list on, click again to disable) From the logic checkbox system makes more sense compared to radio buttons. By clicking 'ordered list' a second time you do know you're disabling an ordered list (and not an unordered list). Which seems relevant to visual impaired too, but what do I know... But well I do grasp the surprise, if you hear checkbox the first time :-), with unordered/and ordered list being mutual exclusive Dependent checkbox are pretty common. See Format -> Paragraph -> Text Flow. 'Do Not split Paragraph' enables if you disable Orphan and Window Control With Page Style enables if 'Insert (breaks) being checked. Note: when I say I'm in principle against, doesn't mean there can be exceptions.. I'm undecided if this is such a case.. I do struggle.. I'm already happy with removal from toolbar. However this does hit the fundamental question how much of the UI (and logic) must be bend. And where the need for an dedicated UI begins. -- Adding CC to Mike for his opinion..
I do not have a strong opinion, but IMO this is an unneeded button.
(In reply to Telesto from comment #6) > Note: when I say I'm in principle against, doesn't mean there can be > exceptions.. I'm undecided if this is such a case.. I do struggle.. I'm > already happy with removal from toolbar. I was thinking that removal from the toolbar is the right way to go since it's the path of least resistance - anyone who wants the "No List" button can still get it back. But... are there such people? That is, do the people who pushed forward 115965 care in particular about "No List", or are two dependent checkboxes ok with them? I pinged on that bug. If nobody actively wants to keep the No List button, perhaps it's better to remove it altogether, and not just from the toolbar. > However this does hit the fundamental question how much of the UI (and > logic) must be bend. And where the need for an dedicated UI begins. You mean, whether dependent checkboxes are appropriate at all? Otherwise I don't quite follow.
(In reply to Eyal Rozenberg from comment #8) > > However this does hit the fundamental question how much of the UI (and > > logic) must be bend. And where the need for an dedicated UI begins. > > You mean, whether dependent checkboxes are appropriate at all? Otherwise I > don't quite follow. Sorry, I'm talk gibberish once in a while.. The no list feature got introduced because of screenreaders: NVDA & Orca Screen readers are used for individuals who are blind or visually impaired. The complaint for bug 115965 was: Screen readers read Number List and Bullet list as check items. They should be read as radio items because only one can be selected at a time. So the introduction of 'No list' is triggered 'special group' of stakeholders with specific needs. The ordered lists/unordered list are mutual exclusive, but can also be turned on/off. The screenreading detecting the (un)ordered list checkbox being 'proper' from the on/off perspective. But makes les sense from the 'mutual exclusive' perspective. Except if in that case the 'on/off' switch is missing.. which causes the introduction of No-List Which is introduction a button 'exclusively' needed for people with screen readers. There likely more area's where impaired people prefer a different UI design (at least I assume so, I actually don't know). It's bit of slippery slope if we are start modifying the UI, and start adding buttons like 'no list' without value for non-impaired and even breaking UI logic (and causing 'issues, like the 'bug' here) Different targets groups have different requirements. A dedicated UI targeting the visual impaired is likely always 'better' compared to long list of compromises.. with lose-lose, win-lose situations. So an UI template (in form of say an extension) might be better in the long run. However this is depending on 'needs and desires' of impaired people. I'm unable to make realistic assessment here. I have tendency to blow things out of proportion
I'm glad to see this issue exists. I am strongly in favour of removing it - especially since it seems like it was added as an after-thought. (Added in LO 7.2 https://gerrit.libreoffice.org/c/core/+/108841) It is basically a duplicate function. The existing bullet, numbering buttons are already toggles. I'm happy to see that no one specifically asked for this to exist, and basically everyone thinks it should go away. So lets make it so. (I'm planning to replace it with the SetOutline button.)
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c0eb37dfd00311518926bd602ccc8776f89b397c tdf#115965 tdf#148790 sw toolbar: no need for RemoveBullet It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/2bb923d236cbd53ea2b10634537cb23fa545b0a2 tdf#115965 tdf#148790 sw sidebar: no need for RemoveBullet It will be available in 24.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.