Created attachment 191427 [details] Clicking on one comment selects the cell, allowing overwrite This is a followup to bug 158514 When you double click on a comment in the Navigator, the selection goes to the cell with the comment. This allows a quick overwrite of the cell contents, but it would make more sense to open the cell for editing. 1. Open attachment 191224 [details] 2. In the Navigator double click on either comment 3. Start typing some characters -> these are entered in the cell 4. Double click again on the same comment 5. Start typing some characters -> these are entered in the cell, overwriting the ones entered in step 3. It would be better in cases of collaborative editing to open the cell for editing, so that existing content is not overwritten. Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 0ddd9f7e055a0c1ecb120de3e40c3fdb8373e9dc CPU threads: 15; OS: Windows 10.0 Build 19045; UI render: default; VCL: win Locale: hu-HU (hu_HU); UI: en-US Calc: threaded
Created attachment 191428 [details] After double clicking the same comment, typing destroys the previously entered text
(In reply to Gabor Kelemen (allotropia) from comment #0) > 1. Open attachment 191224 [details] > 2. In the Navigator double click on either comment > 3. Start typing some characters > -> these are entered in the cell In my case, the cursor is inside the comment and typing adds to the comment (at the beginning). Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 40617d867346956588ac023511f31210107217f4 CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: threaded (same with gen VCL plugin) In any case, let's check with UX/Design team what should be preferred when double-clicking in Navigator: A) edit comment, cursor at the end? B) edit cell, cursor at the end?
(In reply to Heiko Tietze from bug 158514 comment 4) > Bug 64701 asks for "Show Comments Should Select Comment for Editing" and I > wonder if double clicking the Navigator should not only select the cell but > also enter the edit mode directly. > > Otherwise, the proposed Edit function should not change the content within > the Navigator (like F2 to rename a file name) but activate the item itself. I'm not sure anymore if Edit is always wanted. Single click should not go to the cell since users may want to interact with the item in the Navigator, eg. delete the comment directly. So double-click is the go-to action - and as Stephane points out always followed by showing the comment and going into the edit mode. My take: just show the comment, iow don't do what is requested and implemented.
Double-checked with Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b72aa31d7db38c81f757206e4e51844b839797ea CPU threads: 16; OS: Windows 10.0 Build 22000; UI render: Skia/Raster; VCL: win Locale: de-DE (en_DE); UI: en-US Calc: threaded (If one uses the newly introduced Edit command from the context menu we should keep the current behavior, of course, and do go-to + show + edit)
(In reply to Gabor Kelemen (allotropia) from comment #0) > It would be better in cases of collaborative editing to open the cell for > editing, so that existing content is not overwritten. What about named ranges? And drawing objects? Are you suggesting this behavior for them as well, or just for comments? Anyway, personally, tend to agree with Heiko in comment #3, but I don't have a strong opinion on this.
We discussed the topic in the design meeting. We currently execute goto + show comment + edit comment on double-click. It should definitely not be edit the cell content, and editing the comment feels also weird and feels dangerous. So the proposal is to goto + toggle show/hide + select the frame (in order to edit per F2). Currently we show the comment but do not (reliably) hide it when another, potentially close comment is shown. It would be nice if a single click wont change the view port but shows the comment temporarily (until clicking somewhere else); double-click navigates to the cell, makes the comment permanently visible (or hidden, if shown), and selects the comment for easy editing access to edit. Now I wonder if we should resolve ticket as WF according the original summary or change it (eg. "Double-click should not go into the edit mode but select the comment"). Up to Gabor to decide.