This is a continuation of bug #138865 It would be desirable to change the default behavior of treelists based on: https://bugs.documentfoundation.org/show_bug.cgi?id=138865#c11 a) the auto-toggle on click should only kick in if there is only one checkbox in a row (which would solve this case regardless of any other potential changes) because how do we know which one should toggle. But not: „b) it seems more natural to me that the first click on an unselected row just selects it. Subsequent clicks on a selected row to change the toggle like it currently does seems fairly ok too.” I’d like to argue that the default behavior in Windows is “single click toggle” for one checkbox in a treelist. See for an example: https://youtu.be/5SK0P9PydG0?t=60 So most users are accustomed to that, not only in the AutoFilter dropdown but other simple config UI elements such as Options – Writer – Compatibility list ; Options – Writer – AutoCaption or Find and Replace -> Attributes button -> Attributes list. Steps to reproduce: 1. In Writer go to Tools – AutoCorrect – Autocorrect options 1.1. On the Options or Localized Options tab click some items in the list 2. In Writer go to Options – Writer – Compatibility 2.1. Click on the items of the list Actual results: 1: The first checkbox is turned off. This is the same behavior as bug #138865 just a different dialog. Expected: No checkbox is turned on/off by default, since there is more than one. 2: in the Compatibility dialog there is only one checkbox, which is toggled on/off by clicking its row. This is correct behavior, since there is only one checkbox. This is expected to be kept by default. Similar dialogs: Find and Replace -> Attributes ; AutoFilter dropdown; Options – Language Settings – Writing Aids. LibreOffice details: Version: 7.2.0.0.alpha0+ (x64) Build ID: e97a81e94511b52987a50b7bdb72c922899da588 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: CL Adding UX to help decide whether this is indeed desirable.
Some additional info: the widget is a GUI, which can either display as a tree or a table. The internal data format is always a table with multiple columns. If the GUI shows the table as a tree, you probably can assume that a checkbox / radiobox preceding some text is linked, so the text is actually the label. But you can't assume this for tables with multiple columns at all IMHO. So I'm still opposed to this behavior of changing the check- or radio-box as a general feature of the widget, if you select an entry / a row. Not even on a 2nd click. Maybe as a double click. I'm not even sure I would generalize the assumption, that 1. The widget is displayed as a tree 2. It has just two visible columns (internally there can be more invisible ones) 2. The first column contains a *box 3. The 2nd column has text, so entries have additional text next to the *box that the text is the label of the *box, so that behavior could change, but that at least seems acceptable. There are already too many examples (multiple *boxes, text row before the *box, etc.), where a more general approach would fail, as seen in bug#138865. If people think that the "row selection toggles *box" is a more common behavior, I would make it an opt-in feature of the widget, otherwise I would advice to implement it as the row selection handler, if possible. If we default to the select-toggle for some cases, there should be a way to disable it.
I dislike those auto-check-on-row-click activation in general since it covers the selection mechanism. Bug 116675 talks about the missing checkbox label connection for a UI with apparently no columns. My take: if the checkbox has a label clicking this should toggle the state, whether in a table/tree or not. If the table/tree has one or many checkboxes with a label relation at another column we do not auto-toggle the first (or any other) checkbox. One has to explicitly click the checkbox. Exception might be when the table must not be used for selection, but no actual situation pops up where this would apply now.
There is https://gerrit.libreoffice.org/c/core/+/108947 This reverts the default behavior to the previous state and adds an opt-in API used by the AutoFilter. It also has "toggle after select" implemented as a 3rd, yet unused option.
Attila Szűcs committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3d2a431da1126f4924f6cd7e5abac6488cd480e7 tdf#139115 vcl tree list: add new toggle behaviors It will be available in 7.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.
(In reply to Commit Notification from comment #4) > Attila Szűcs committed a patch related to this issue. Resolved fixed now?
(In reply to Heiko Tietze from comment #5) > (In reply to Commit Notification from comment #4) > > Attila Szűcs committed a patch related to this issue. > > Resolved fixed now? I think yes: - Autofilter has single click activation on filterable item labels too; similar to Excel - No item click (single nor double) toggle in other places like Tools - Autocorrect options - Options / Localised Options tabs; or Customize - Notebookbar (bug #139294); or Options - Fonts (bug #138865 - its workaround was also reverted in master)
Verified in: Version: 7.2.0.0.alpha0+ (x64) / LibreOffice Community Build ID: 72841008bf422dfd8553240b3a78f0474d03523c CPU threads: 4; OS: Windows 10.0 Build 17134; UI render: Skia/Raster; VCL: win Locale: hu-HU (hu_HU); UI: hu-HU Calc: threaded Jumbo