Created attachment 204251 [details]
CALC - keyboard shortcut - function name

It's true that for keyboard shortcuts, no helpful tooltip is shown. If you go to menu items, you will see info for the individual items.

(In reply to Buovjaga from comment #2)
> It's true that for keyboard shortcuts, no helpful tooltip is shown. If you
> go to menu items, you will see info for the individual items.

Hmm, I'm not sure what happened earlier, because now I can see the tooltips. Maybe there is some state that the tooltips are not shown and some processing needs to happen?!

Can you do more testing?

Version: 26.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a76f0371596f0037444c40fe3dcad5b4fef18c24
CPU threads: 4; OS: Linux 6.17; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded

The tooltips *only* appear in the 'Functions' block of the 'Keyboard' tab, but they do not show for the actual assignments in the UI's upper listing of 'Shortcut Keys'. Currently all that is shown on mouseover anywhere in the area of the UI is the generic tooltip: "To quickly find a shortcut in this list, simply press the key combination".

This differs from the other panels of the 'Customize' dialog, where a tooltip (with UNO and shortcut if any) as assigned to the control is shown on mouseover. 
The tooltip duplicates what is shown in the 'Description' (though no Description was added for the Notebookbar customizations, but they get the same tooltips). 

It would be helpful to Keyboard customization if somehow similar descriptive tooltip could be shown on mouseover of the UNO assignments listed with their 'Shortcut Keys'.

Seems this didn't get picked up as bug 112237 was implemented with https://gerrit.libreoffice.org/c/core/+/140142

@Jim, what do you think, can the work on bug 112237 be expanded?

(In reply to V Stuart Foote from comment #4)
> @Jim, what do you think, can the work on bug 112237 be expanded?
Sure can! If we want to make this a hack for a beginner I will supply code pointers. If we would like this enhancement sooner than later, please let me know ;)

(In reply to BDF from comment #0)
> 1. Open the keybinding menu and search for eg. footnote
> 2. The text alone does not tell you what it does. There also is no
> description displayed on hovering with mouse
IMO the tooltip on the functions list is sufficient. The mentioned workflow is not to look through the assigned shortcuts and find those that can be overwritten.

We should rather invest on a complete redesign of the dialog, bug 115527 and other.

(In reply to Heiko Tietze from comment #6)
> (In reply to BDF from comment #0)
> > 1. Open the keybinding menu and search for eg. footnote
> > 2. The text alone does not tell you what it does. There also is no
> > description displayed on hovering with mouse
> IMO the tooltip on the functions list is sufficient. The mentioned workflow
> is not to look through the assigned shortcuts and find those that can be
> overwritten.
> 
> We should rather invest on a complete redesign of the dialog, bug 115527 and
> other.

Issue of OP was that the description doesn't show--but it does. Just only on the Function listbox when user filters by search.

Comment 4 suggests an overlooked implementation issue in that for the Keyboard panel, an onmouseover of an assigned function should show tooltip with details of the associated UNO assigned. *For consistency with the other customization panels*.

Full redesign of the customization dialog aside, this current inconsistency on the Keyboard panel should be tweaked for better UX. Providing details of the actual UNO assigned to accelerator/shortcut that is now missing to put it on par with the other panels.

(In reply to V Stuart Foote from comment #7)
> (In reply to Heiko Tietze from comment #6)
> > IMO the tooltip on the functions list is sufficient.
> Issue of OP was that the description doesn't show--but it does. Just only on
> the Function listbox when user filters by search.

BDF, do you agree on INVALID or expect the tooltip also on the upper "shortcut keys" list?

Created attachment 205018 [details]
CALC - bug 169659 - keyboard shortcuts - DE Wortverbinder

(In reply to Heiko Tietze from comment #8)
> 
> BDF, do you agree on INVALID or expect the tooltip also on the upper
> "shortcut keys" list?

Well, my initial comment was not about showing a tooltip.
The original headline was "[Feature request] CALC - Improve description of keyboard shortcut binding names". Buovjaga seems to have changed it to the current headline. As the init comment is also not about tooltips, I'll change the description back to what it was. 

As the initial goal was to improve the label for it to represent what it does (eg. "Footnote" -> "Insert footnote") I don't think that there was an improvement on that front yet. The tooltip is nice, but why would we go the Microsoft route and hide something one layer deeper in a context menu if there is no need for it (here: hide information in a tooltip that only shows on hover (= extra manual work) if the same information is better suited as button lable).



There seems to be a tiny mistake in the german version (see attached file) as the label ("Beschriftung" - is this one a 'description' if it's usually only the label name?) and the help ("Direkthilfe") seems to be flipped.
However, this is actually what I had in mind as goal. You search for the function name or label (eg. 'footnote' - whatever this is actually called; here: "Wortverbinder") and you are presented on first glace what it actually does (eg. 'Insert footnote'; here "Wortverbinder einfügen"). IMO there is no reason to hide this info in a tooltip.

Created attachment 205019 [details]
CALC - bug 169659 - keyboard shortcuts - DE Fett

Same for "Fett" ('bold') in german.
- Label: "Fett"
- Help: "Fett" (+ keyboard shortcut that is also visible on the side)

OK, and what does the cyan colour _do_? (Of course this is the function that makes the font bold, but that's not written anywhere).

There is the keyboard shortcut in the help ("Direkthilfe") line that is also presented right next to it (red). That does not make even sense for a custom shortcut as they are presented in the list on the right as well (maybe it does for eg. special keys on a stream deck that are not listed at the top)

My suggestion:
> Menu Entry
  - Label: Schriftstärke: Fett ('font weight: bold") 

> Pop-up menu
 (- Lable: not needed as the menu entry lable is descriptive enough)
  - Help: Schriftstärke des Texted zu Fett ändern ('change text font weight to bold')
  - Command: No changes, but maybe moved to the bottom

(In reply to BDF from comment #9)
> Well, my initial comment was not about showing a tooltip.
> The original headline was "[Feature request] CALC - Improve description of
> keyboard shortcut binding names". Buovjaga seems to have changed it to the
> current headline. As the init comment is also not about tooltips, I'll
> change the description back to what it was. 

In your original description you had:
(In reply to BDF from comment #0)
> 2. The text alone does not tell you what it does. There also is no
> description displayed on hovering with mouse

But what you are now explicitly asking would mean that we change command labels *globally* - we shouldn't have different labels for each location.

(In reply to Buovjaga from comment #11)
> In your original description you had:
> (In reply to BDF from comment #0)
> > 2. The text alone does not tell you what it does. There also is no
> > description displayed on hovering with mouse
> 

A mistake by me that I didn't see it, yet it was not a suggestion to have a tooltip.

(In reply to Buovjaga from comment #11)
> But what you are now explicitly asking would mean that we change command
> labels *globally* - we shouldn't have different labels for each location.

I have no idea how the internals really work. My guess was that it just uses the existing (not very descriptive) labels.
I am not suggesting to change the labels globally (is there a way to not do it, I don't know).
But as "Wortverbinder" shows: There is a possible option to separate the global label from the line that is shown in the menu (even it looks like it was a mistake here).

("Wortverbinder" is located in menu Einfügen > Formatierungszeichen > Wortverbinder; EN: Insert > Formatting Mark (?) > Word joiner (?) - according to https://help.libreoffice.org/latest/en-GB/text/shared/01/formatting_mark.html)

Unfortunately, the labeling of controls/buttons/menu entries is complex and depends on the class of label required. Issue can not be with individual button assignments. It is global affecting all keyboard assignments.

See the work up in bug 108458 to understand why individual controls get labels of varying complexity depending on location in the UI.

And why here, the issue with *namings* on the assigned area of the Keyboard tab of the customize dialog would be better served by exposing full tooltip as done on the other tabs. Adjusting the individual "binding names" (including needed translations) are unmaintainable.

Correct way is framework of how Maxim and Jay resolved things for bug 108458, but the Keyboard tab of the Customize dialog needed the additional tweak of exposing to user the full tooltip description of a shortcut's assigned UNO.

Here is a better example of categorizations:

consider the string "Center" (so maybe as "Zentrieren" in Deutsch).

In the Customize -> Keyboard tab on the 'Functions' search field enter that string.

On the Category column

1. select 'All commands' --> what commands show in the 'Functions' column?

2. change Category selection to 'Frame' --> what commands show?

3. change Category selection to 'Format' --> what commands show?

Point is that no matter what *binding name* is used--due to duplication and needs for terse command names--the only reasonable means for a user to asses the controls function is the detail provided in the complex tooltip.

While the command names of shortcuts already assigned (as exposed in the upper panel) otherwise hide their function due to their terseness.

Clearly not just a Calc UI issue, the example clips are all from Writer ;-)

And I hope from a read of see also bug 108458 that folks gain a sense of issues in curating and assigning names to UNO commands appropriate to their use in the UI.

Yes, the UI for making keyboard shortcut assignments certainly needs the work on bug 115527

But the multi-line tooltip at 7.0.0 on close out of bug 108458 by Jim and Heiko is the status quo--done without requiring a massive rehash of command names and translations.

And my suggestion in comment 4 was to bring status quo of exposing multi-line tool tips onto the Customize -> Keyboard tab for browsing the upper shortcut listing--giving parity with the other customize dialog tabs.

And that alone would give users greater understanding of the controls bound to each shortcut. Even when those names are necessarily terse.

(In reply to BDF from comment #9)
> As the initial goal was to improve the label for it to represent what it
> does (eg. "Footnote" -> "Insert footnote")...

(In reply to V Stuart Foote from comment #15)
> And my suggestion in comment 4 was to bring status quo of exposing
> multi-line tool tips onto the Customize -> Keyboard tab...

Nothing to say against the dynamic hover tooltip but it does not solve BDF's issue. Which I still don't really understand - a clear use case like "I want to assign a new shortcut to the "Bold" function and wasn't able to do so because..." would help.

Regarding the command labels I wrote a blog post a while a ago: https://design.blog.documentfoundation.org/2018/02/28/easyhacking-all-about-terminology/

Don't think we can show anything else but Bold or Insert Word Joiner in the list. With huge effort we might be able to add some kind of extended tooltip explaining the function - but l10n people surely don't like this. And still there is no use case that would be solved by that.

Created attachment 205043 [details]
205019: CALC - bug 169659 - keyboard shortcuts - EN multi

(In reply to Heiko Tietze from comment #16)
> (In reply to BDF from comment #9)
> > As the initial goal was to improve the label for it to represent what it
> > does (eg. "Footnote" -> "Insert footnote")...
> 
> [...]
>
> Which I still don't really understand - a clear use case like "I want
> to assign a new shortcut to the "Bold" function and wasn't able to do so
> because..." would help.
> 

Regarding the tickets and the blog post I have to work through them when I have a little bit more time on my hands.

Regarding the use case: 
=> Notes:
- The assumption is that you do *not* know LibreOffice inside out, know every row of code by name and have also not replaced your set of prayers with your rosary with UNO commands (TLDR: You are a rather new user).
- Numbers in brackets (eg. (1) ) refer to the attached image

I want to assign a new shortcut to the "Bold" function and wasn't able to do so because it was unclear to me what the function behind the label does and what would really happen when I press the shortcut.

When you want to make a text bold, the menu tree tells you what the menu entry will do: Format > Text > Bold (the format of the text will be changed to bold). If you click on the UI button for making the text bold, the visual style of button itself tells you that you are about to change the font style.
If you want to assign a keyboard shortcut and search for "bold", neither the label nor the tooltip (or the UNO command name) tells you what the function really does (5). This is probably a rather bad example as even new users more than likely know about font styles.

The footnote is maybe a better example as there are more options. When you want to insert a footnote, the menu tree again tells you what the menu entry will do (Insert > Footnote/Endnote > Footnote; you will insert a footnote) and the UI button shows the tooltip 'insert footnote' on hover. It is clear what happens in your document when you press the button.
However "footnote" in the keyboard shortcuts window does not say what it will do in your document. If you search for "footnote" (3) you get "Edit Footnote/Endnote", "Footnote" (what does it do?), "Footnote/Endnote" (wdid?), Footnote/Endnote Settings x2 (Is there difference? There has to be a difference otherwise it wouldn't be listed, right?), "Insert Special Footnote/Endnote".

The grammatical mood of the menu text would may be best as (short) imperative: Insert Footnote!
You can also think about it as controlling your PC with your voice. User: "Footnote!"; PC: Footnote _what_? Add footnote? Edit footnote? Delete footnote? Transform footnote to endnote?
If the text is sufficiently precise to be used as voice command for the PC, it is also able to give the user a clear representation what will happen: If I bind key "X" to "Insert Footnote", it will insert a footnote on button press. If I bind key "Y" to "Footnote", ??? will happen.

"Word joiner" is a good example in english as well. You search for "word joiner" (1) and without viewing the tooltip you know from just reading the function label that if you bind this function to kex "X" it will insert a word joiner on button press.
The label and the tooltip also seem to be reversed in the english version as well for word joiner (2).
"Insert Special Footnote/Endnote" (4) would also be a good example. You may not know what's so special about a "special footnote", but you know that if you bind this function to key "X" you will insert one of them.

Created attachment 205044 [details]
CALC - bug 169659 - keyboard shortcuts - footnote example

I made a side by side comparison of what the difference between the status quo (left) and my suggestion (right) is:

- function name: As said, a short imperative that says in one line what it does: What happens in the document on button press?
(This would be the main issue of this feature request and if this alone would be changed, this feature request would be fully done)


- tooltip, label: The label was removed as it presents no additional information that helps the user to understand what is done here (footnote - footnote; double the text but no additional information)
- tooltip, tooltip: The tooltip is more descriptive. This would be more useful for eg. "Special Footnote" to say what's so special about it). Here it also kinda only doubles text without adding information.
- tooltip, command: The command was moved to the bottom as this is the least important information for the average user.

(In reply to BDF from comment #17)
> [...]
> The footnote is maybe a better example as there are more options. When you
> want to insert a footnote, the menu tree again tells you what the menu entry
> will do (Insert > Footnote/Endnote > Footnote; you will insert a footnote)
> and the UI button shows the tooltip 'insert footnote' on hover.
> [...]
>

Thinking about the UI during lunch if there may is an easy solution.

We could use the tooltip instead for a label in the keyboard shortcut window, couldn't we?
The answer is No and the option to merge (or if merged: split) cells in Calc would probabaly be a good example as the tooltip is rather long.

However, this might also be a good example for a solution.
The menu entry already has a good label even not 100% accurate: "Verbinden und zentrieren" (probably "merge and center" in english)
The tooltip gives you more information what will happen in the sheet: "Zellen verbinden und zentrieren beziehungsweise trennen, je nach aktuellem Status" (en: merge and center or split cells, depending on their state) .

(In reply to BDF from comment #17)
> I want to assign a new shortcut to the "Bold" function and wasn't able to do
> so because it was unclear to me what the function behind the label does and
> what would really happen when I press the shortcut.
If you don't know what Bold does you need to learn everything from scratch. 

> The footnote is maybe a better example...
Label: Footnote
Command: .uno:InsertFootnote
Tooltip: Insert Footnote

Not sure why we use a short form as label in this case and not something like
Label: Insert Footnote
ContextLabel: Footnote

Basically the idea is to have some meaningful name and something shorter for the menu Insert > Footnote. This needs to be fixed for each command individually.

> "Insert Special Footnote/Endnote" (4) would also be a good example. You may
> not know what's so special about a "special footnote", but you know that if
> you bind this function to key "X" you will insert one of them.

Neither you know from Insert > Footnote and Endnote > Insert Special Footnote/Endnote... The envisioned explanation aka extended tip for commands might tell you something like "Shows a dialog to pick a different character for numbering" but it is a lot of effort and I doubt beginners with no clue about Bold or Footnotes would customize the UI. 

Still -1 from my side

(In reply to Heiko Tietze from comment #20)
> [...]
> Basically the idea is to have some meaningful name and something shorter for
> the menu Insert > Footnote. This needs to be fixed for each command
> individually.
> 

Boiled to the task: Yes, that's all.

(In reply to Heiko Tietze from comment #20)
> [...]
> The envisioned explanation aka extended tip for commands
> might tell you something like "Shows a dialog to pick a different character
> for numbering" but it is a lot of effort and I doubt beginners with no clue
> about Bold or Footnotes would customize the UI. 
> 

I don't know where the explanation / extended tip for command "Shows a dialog [...]" would fit in.

It would probably be detail work that makes a more polished look for pro users.
Even in general I dislike Apple's software, there is something positive to be said about their eye for detail. I guess this is probably where my suggestion is heading.

As to me this does not look like a major change, but rather like a grindy (yet rather simple) task, I would be fine if it end up on the 'TODO later' pile and I could try to implement this myself (due to lack of time, it would probably take at least until 2026-09 though).

If the existing label is kept as fallback, it doesn't matter if l10n is finished in time or not at all. 

While talking about bug 151665 yesterday I found more examples in the menu entries to track changes. "Vorherige", "Nächste", "Annehmen" or "Ablehnen" (en: previous, next, accept, reject) are named so in the keyboard shortcuts menu. Again very clear what they do from their location in the menu structure Edit > Changes > Next, but no so in a flat list with other commands.

Searching for "nächste" (en: next) in the keyboard shortcuts menu:
- "Nächste"
- "Nächste Seite" (en: next page)
- "Nächster Datensatz" (en: next data set)
It seems like there wouldn't be that many entries after all to care about as 'next page' and 'next data set' wouldn't need the suggested treatment.

Created attachment 205066 [details]
CALC - bug 169659 - keyboard shortcuts - DE Kommentar

Another example with comments ("Kommentar")

You can see the actions for comment entries "ausblenden", "bearbeiten", "ein-/ausblenden", "löschen" and "anzeigen" (en: hide, edit, show/hide, delete, show) and their entries are labeled as such.

Yet the entry to _add_ a new comment is not labeled as such. It's tooltip says "Kommentar einfügen" (en: insert comment). If you hover over the other entries (hide, edit, etc) you can see that their label as well as their tooltip are the same. 
(If we turn the issue upside down: Would it hurt for the menu entry to be called eg. Insert > Foot-/Endnote > Insert Footnote?)


Considering all of this, this might be more an issue with consistency rather than a need for dedicated improvement of any description.
I don't think we should just use the tooltip as menu entry label as eg. the Calc option to merge (if merged split) cells is quite long and 'merge and center' seems to be accurate (enough even though not perfect).

@Rafael, thanks for the see also link to bug 138725 had forgotten some of that discussion, and Maxim's and Justin's tech notes toward the bottom.

Simply put, here the *best approach for now* remains as in comment 4 and comment 5
to make the full tooltip--with its configured UNO, its Label, Tooltiplabel, Context label and Properties--made available in the assigned Shortcut area and not just the Function column after a search. Giving parity to the other Customize tabs to be able to identify what is already assigned.

Then, some full redesign of the Customize -> Keyboard could implement something more to provide descriptions and UI appropriate button names (and their associated l10n).

For example since we've now got an SQLite instance with our python support would think we could possibly get away from the convoluted entries (and l10n translation effort) held now in the GenericCommands.xcu

While poking at these piecemeal is a recipe for incomplete/inconsistent change that is the worse "change for changes sake". 

And gets an emphatic -1 from me to do it like that.

We discussed the topic in the design meeting.

Some kind of "descriptive label" in addition on the command solves this issue and other but has an heavy impact on documentation and l10n. With little benefit, OTOH, since you can read the API documentation or do trial and error for the few unclear commands.

The current categorization is sufficient, and if this or the command needs fine-tuning as currently discussed in bug 169766 or bug 169767, for example, we should handle this per command.

OK with the => NAB, but split off function Tooltip for assigned kb Shortcut suggestion of comment 4, comment 5 into a new BZ issue bug 170528

Bug 170517 asks for "Add description for UNO dispatch commands that lack them (toolbar)".