Bug 161972 - Inserting new comment in Calc disables the "show all comments" setting
Summary: Inserting new comment in Calc disables the "show all comments" setting
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
5.4.0.3 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsUXEval
Depends on:
Blocks: Calc-Comments
  Show dependency treegraph
 
Reported: 2024-07-09 15:01 UTC by Gabor Kelemen (allotropia)
Modified: 2024-09-23 17:10 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Simple example file from Calc (8.11 KB, application/vnd.oasis.opendocument.spreadsheet)
2024-07-09 15:01 UTC, Gabor Kelemen (allotropia)
Details
View - Comments is enabled before inserting a new one (64.52 KB, image/png)
2024-07-09 15:02 UTC, Gabor Kelemen (allotropia)
Details
View - Comments is disabled after inserting a new comment which is also hidden (58.22 KB, image/png)
2024-07-09 15:03 UTC, Gabor Kelemen (allotropia)
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Gabor Kelemen (allotropia) 2024-07-09 15:01:48 UTC
Created attachment 195188 [details]
Simple example file from Calc

If the View - Comments setting is enabled and all comments are shown, inserting a new comment disables this setting and is hidden, while the other comments are still visible.

1. Open attached file
2. Enable View - Comments. 2 comments become visible and this menu item is seen toggled in the View menu
3. Insert a new comment 
-> this one becomes hidden and the View - Comments item becomes default state.

It would be more consistent to change the behavior so that new comments are visible just like old ones when the View - Comments is enabled and inserting a comment does not disable it.

Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 2afdc61dd3138b383fb73dae2242ba1a9c8de901
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: hu-HU (hu_HU.UTF-8); UI: en-US
Calc: threaded

Behavior is like this since 5.4 when View - Comments was added.
Comment 1 Gabor Kelemen (allotropia) 2024-07-09 15:02:50 UTC
Created attachment 195189 [details]
View - Comments is enabled before inserting a new one
Comment 2 Gabor Kelemen (allotropia) 2024-07-09 15:03:39 UTC
Created attachment 195190 [details]
View - Comments is disabled after inserting a new comment which is also hidden
Comment 3 ady 2024-07-09 15:42:30 UTC
(In reply to Gabor Kelemen (allotropia) from comment #0)

> It would be more consistent to change the behavior so that new comments are
> visible just like old ones when the View - Comments is enabled and inserting
> a comment does not disable it.

The View > Comments menu entry is working as an applied action, not so much as a toggle status for every comment, (and I'm fine with it).

Only when all the comments are unhidden, the menu entry is shown as ON, but that "status" can also be achieved by selecting the range of cells with comments and choosing to show comments by means of the cell's context menu.

IIUC, the property to show/hide a comment is saved on each comment/cell, not as a whole on the document – I could be wrong.

For instance, you can have many comments set to Show already, and you might want to add several new comments but you want them to remain hidden. Unhiding all the new comments is easy with the current workflow, but having to hide each new comment is an extra unneeded work, even when selecting multiple cells.

For each case, there are pros and cons.

FWIW, I am not convinced that changing the current behavior is for the better.
Comment 4 Heiko Tietze 2024-08-26 13:37:58 UTC
The command is disabled while editing a comment. Meaning it becomes available once you finished to add a new comment.

What remains is the fact that View > Comments is not a toggle. I can follow Ady's comment 3 in this regard. You too, Gabor?
Comment 5 Heiko Tietze 2024-09-06 07:55:10 UTC
The topic was on the agenda of the design meeting but received no further comments. Resolving NAB following comment 3.
Comment 6 Gabor Kelemen (allotropia) 2024-09-22 19:11:23 UTC
Let me reopen this. The customer request is kinda straightforward, the current process is confusing. Making it simpler is desired.

(In reply to Heiko Tietze from comment #4)
> The command is disabled while editing a comment. Meaning it becomes
> available once you finished to add a new comment.

Being disabled while editing a new comment is not a problem, but after editing it changes status if it was "Enabled" (but not if it was disabled). 
Further, editing an existing comment does not turn it off - which makes sense in itself, but inconsistent with editing a new comment.
This is not good.

> 
> What remains is the fact that View > Comments is not a toggle. I can follow
> Ady's comment 3 in this regard. You too, Gabor?

That is exactly the problem. This current behavior (it's BOTH a status indicator AND an action button) makes less sense than making it a toggle.

In Calc, new comments are hidden after creation and initial editing by default.

This contrasts the behavior of Excel: there the new comments are hidden or shown depending on the status of the Show All Comments button, which also changes the status of existing comments. Our customer was inspired by that.

Other use cases, such as the one mentioned by ady, are worth investigating in detail:

> For instance, you can have many comments set to Show already, and you might want to 
> add several new comments but you want them to remain hidden. Unhiding all the new 
> comments is easy with the current workflow, but having to hide each new comment is 
> an extra unneeded work, even when selecting multiple cells.

- Having a file with all existing comments hidden.
Currently: New comments are added as hidden. Unhiding the new ones is a per-comment click, but hidden ones are kept hidden.
After: (a) If View - Comments becomes a toggle which is turned off by default, the behavior is the SAME.
(b) If it is turned on by default, new comments are added as visible and hidden ones are kept hidden. This would match Excel behavior. This is LESS clicks than before.
(c) If the status is changed, all comments become visible / hidden. This is the SAME as before, plus new comments are created according to the new visible / hidden state.

- Having a file with all existing comments visible. Let's say we want to add some hidden ones.
Currently: New comments are added as hidden. No clicks needed.
After: (a) If View - Comments becomes a toggle which is turned off by default, new comments are created as hidden. This is the SAME as before.
(b) If it is turned on by default, new comments are added as visible. Hiding them is a per-comment click.
(c) If the status is changed  all comments become visible / hidden. This is the SAME as before, plus new comments are created according to the new visible / hidden state.

Overall, it does not seem like there would be a huge downside. I think it would be more consistent and less confusing on the "is this a status indicator or a toggle command? -> Both" front.
Comment 7 ady 2024-09-23 02:14:12 UTC
(In reply to Gabor Kelemen (allotropia) from comment #6)

> That is exactly the problem. This current behavior (it's BOTH a status
> indicator AND an action button) makes less sense than making it a toggle.

The meaning of this "status", when ON, is: "all your current comments are currently displayed; there is no hidden comments at this moment".

The meaning of this "status", when OFF, is: "(beware) there might be hidden comments".

The ON status of this menu entry is not meant as "every new comment should be automatically displayed, not hidden". It is not a "setting", but an "action".
Comment 8 Heiko Tietze 2024-09-23 07:43:16 UTC
How about a tri-state toggle, and better naming of the command (bug 140615)?

View > [x] All Comments
* all shown, create visible
View > [ ] All Comments
* all hidden, create hidden
View > [/] All Comments
* some hidden, create visible

Click on [/] All Comments could either uncheck the option or check, I see no preference for one.

We should consider the two commands uno:ShowAnnotations (used in the main menu) and uno:ShowAllNotes/uno:HideAllNodes (introduced with bug 84837). Single comments can be changed with uno:NoteVisible or uno:ShowNote/uno:HideNote, making the maintenance and customization difficult.

I would reduce it to two commands: uno:ShowAnnotations (with the modifications as discussed) and uno:ShowNote (to keep the label similar) that would also toggle the visibility on/off.
Comment 9 ady 2024-09-23 17:10:04 UTC
(In reply to Heiko Tietze from comment #8)
> How about a tri-state toggle, and better naming of the command (bug 140615)?
> 
> View > [x] All Comments
> * all shown, create visible
> View > [ ] All Comments
> * all hidden, create hidden
> View > [/] All Comments
> * some hidden, create visible

Let's recap. The current menu entry is working correctly; there is no bug there. The problem is that a user might not understand the effects of the shown toggle ON/OFF.

The proposed tri-state toggle in comment 8 doesn't solve the potential slight temporal misunderstanding of the current behavior of the toggle status, and worse, it blocks (i.e. does not allow) the current status behavior, which is:

 [x] Whichever the prior status (shown/hidden) of any comment in the currently-shown worksheet, now show (un-hide) all the _current_ comments in it;

 [ ] Some comments might be hidden;

... and with both statuses, newly created comments are initially hidden (with its reasoning as explained in comment 3).


In case someone is not seeing the detail, the proposed tri-state does not allow the current behavior.

Instead of changing the meaning and effects of the menu entry, and even blocking the current behavior, the solution is to improve the documentation (Help Content) with one paragraph, explaining the meaning of the toggle (ON/OFF) with better wording. If a user wants every single (new) comment to be shown, then that user can create (i.e. insert) them and then act on the current menu entry, once.

I still see no good reason to change the current behavior, and even worse, blocking it. If the source of this "problem" is lack of intuitive meaning/effects of the menu entry, the proposed tri-state does not improve its (intuitive) understanding at all, and better documentation would be needed anyway. Instead, just improve the documentation of the current behavior, without the need to over-complicated menu entries (which – worth saying it again –  blocks the current behavior instead of only adding possibilities to the current one).