Bug 155442

Summary:	Accelerator to delete row(s) conflicts with the one for adding row(s)
Product:	LibreOffice	Reporter:	matthess
Component:	Calc	Assignee:	Julien Nabet <serval2412>
Status:	RESOLVED FIXED
Severity:	minor	CC:	heiko.tietze, serval2412, stephane.guillou, xiscofauli
Priority:	low	Keywords:	bibisected, bisected, regression
Version:	7.4.0.0 alpha0+
Hardware:	All
OS:	Windows (All)
Whiteboard:	target:7.6.0 target:7.5.5
Crash report or crash signature:		Regression By:
Bug Depends on:
Bug Blocks:	98259
Attachments:	screenshot of version 7.3 versus version 7.5

Description matthess 2023-05-23 03:46:59 UTC

Description:
Alt+S+W doesn't delete rows anymore as the shortcut has been changed. Attached pic will show the change.

Steps to Reproduce:
1. Select cell of row(s) to be deleted.
2. Alt+s+w  to delete rows


Actual Results:
nothing happens

Expected Results:
rows get deleted. I have installed 7.3 to regain function as I use it a lot.


Reproducible: Always


User Profile Reset: No

Additional Info:
rows should have been deleted.

Comment 1 matthess 2023-05-23 03:49:36 UTC

Created attachment 187449 [details]
screenshot of version 7.3 versus  version 7.5

Comment 2 Stéphane Guillou (stragu) 2023-05-23 10:00:45 UTC

Confirmed, we now have two conflicting accelerators since 7.4, both using R: Insert Rows and Delete Rows.
As a workaround, you can still toggle between the two options and then press Enter.

Julien, this started at 52a695d2ceb4231a9fcc419959e29023ecef037b
Right before that commit, we had "o" for deleting rows.

Testing in recent master build, we have at least three conflicts in this menu:
- Insert ~Rows vs Delete ~Rows
- Insert ~Cells vs Delete ~Columns vs Cell ~Comments
- Insert Page ~Break vs Delete Page ~Break

Can we at least go back to W for Delete Rows?

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: f4c24da1e7f11664e0d2f688d2531f068e4a3bc0
CPU threads: 8; OS: Linux 5.15; UI render: default; VCL: gtk3
Locale: en-AU (en_AU.UTF-8); UI: en-US
Calc: threaded

Comment 3 ady 2023-05-23 14:15:25 UTC

(In reply to Stéphane Guillou (stragu) from comment #2)
> As a workaround, you can still toggle between the two options and then press
> Enter.

That's not what happens in my system. Once you press the first R, the submenu opens, so pressing again R will not jump to select the next R-action. IOW, the first R blocks the next R shortcut.

OTOH, [CTRL]+[+] and [CTRL]+[-] are working as always; this does not mean that the menu shortcuts should not be improved.

Comment 4 Julien Nabet 2023-05-23 17:37:52 UTC

I've submitted the revert on gerrit here:
https://gerrit.libreoffice.org/c/core/+/152169

Still today, I don't understand how to manage accelerators. For example,
at a moment, I thought the goal was to remove the "~" which indicated the key but how to be sure to have "Ctrl-C" to map copy command then?

So accelerator management must take into account:
- localization
- keyboard type
- OS (for Linux OS/Env : gtk/kde/others)
- least surprise (see above the Ctrl-C command)
- mimic MsOffice so people won't submit a new bug just for a different accelerator
- potential conflicts for commands (like here)
- duplicates so we don't have to type several types the shortcut to reach the one we want
(did I forget some?)

Comment 5 Julien Nabet 2023-05-23 18:13:12 UTC

Cherry-pick for 7.5 submitted to Jenkins here:
https://gerrit.libreoffice.org/c/core/+/152106

Comment 6 Julien Nabet 2023-05-24 11:53:19 UTC

(In reply to Julien Nabet from comment #5)
> Cherry-pick for 7.5 submitted to Jenkins here:
> https://gerrit.libreoffice.org/c/core/+/152106

It's been pushed.