What I like in the current implementation is that I can see ALL keys that are assigned to a command--not only the new assigned/edited one but also the other already assigned keys. The mockup seems to copy the toolbar customization where only one command can be edited.

Also an additional command--to make possible what Heiko suggested in bug 115052 comment 3--can be inserted to assign a key also by pressing it instead of clicking through some lists.

What are the other items of the selection list where "Function keys" is shown as first item? Should the key list kept short with a list for function keys, a second list of modifier1 keys, a third list of modifier2 keys, etc.? I personally like the possibility to see all keys and assigned commands in a single list to scroll here and there without having to click at something and without loosing any change I made meanwhile when looking around.

I should have scrolled down in the attached mockup. ;-) The selection list titled "Function keys" also includes the other modifier keys and an "All" list item. My last paragraph in comment 1 is answered.

(In reply to Thomas Lendo from comment #1)
> What I like in the current implementation is that I can see ALL keys that
> are assigned to a command--not only the new assigned/edited one but also the
> other already assigned keys. The mockup seems to copy the toolbar
> customization where only one command can be edited.

The mockup doesnt change this fact when the filter drop down is set to 'All'. The mockup has filter set to 'Function keys' which is why only the Fn keys are shown.

> Also an additional command--to make possible what Heiko suggested in bug
> 115052 comment 3--can be inserted to assign a key also by pressing it
> instead of clicking through some lists.

An add button works fine in that kind of workflow used in desktop environment shortcut assignment, but isnt useful in this workflow.

(In reply to Thomas Lendo from comment #1)
> Also an additional command--to make possible what Heiko suggested in bug
> 115052 comment 3--can be inserted to assign a key also by pressing it
> instead of clicking through some lists.

Didn't remember this mockup which nicely fits into the customization. Freely defined shortcuts are not so easy to implement but this solution is feasible as an (advanced) esayhack.

Created attachment 139936 [details]
All shortcut keys of a command are visible in one place

(In reply to Yousuf Philips (jay) (retired) from comment #3)
> (In reply to Thomas Lendo from comment #1)
> > What I like in the current implementation is that I can see ALL keys that
> > are assigned to a command--not only the new assigned/edited one but also the
> > other already assigned keys. The mockup seems to copy the toolbar
> > customization where only one command can be edited.
> The mockup doesnt change this fact when the filter drop down is set to
> 'All'. The mockup has filter set to 'Function keys' which is why only the Fn
> keys are shown.
Jay, your answer is what I meant in paragraph 3 in my previous comment.
What I meant here is shown in the attached screenshot of the Customize dialog.

(In reply to Thomas Lendo from comment #5)
> Jay, your answer is what I meant in paragraph 3 in my previous comment.
> What I meant here is shown in the attached screenshot of the Customize
> dialog.

Okay i get what you mean now. Yes this functionality would be lost with the new design. If it is a feature that is deemed necessary, then a 'Current Keys' listbox could appear under the command listbox.

(In reply to Thomas Lendo from comment #1)
> Also an additional command--to make possible what Heiko suggested in bug
> 115052 comment 3--can be inserted to assign a key also by pressing it
> instead of clicking through some lists.

Thinking more about this, a plus button could appear in the middle next to add and remove, which would open up a dialog that had a field in it that a user can press the shortcut key they want to assign to the already selected command.

Latest posting with mockups is here https://design.blog.documentfoundation.org/2015/01/22/how-to-make-libreoffice-customization-usable/ (havent looked into the documents so it might be the same)

(In reply to Heiko Tietze from comment #7)
> Latest posting with mockups is here
> https://design.blog.documentfoundation.org/2015/01/22/how-to-make-
> libreoffice-customization-usable/ (havent looked into the documents so it
> might be the same)
(added a comment there)

*** Bug 139293 has been marked as a duplicate of this bug. ***

*** Bug 52335 has been marked as a duplicate of this bug. ***

*** Bug 146409 has been marked as a duplicate of this bug. ***

*** Bug 153335 has been marked as a duplicate of this bug. ***

*** Bug 159845 has been marked as a duplicate of this bug. ***

In the Configure Shortcuts problem, one has to establish a relation between two potentially very long lists:

1.) the list of all allowed key combinations,
2.) the list of functions to be invoked by them.

Some or even many elements of both lists may remain unassigned, in fact, shortcuts are only useful, if one can memorize them. So even an advanced user will at most use a dozen or so of them.

Shortcuts in LO are insensitive to context. Each assign key combination may invoke at most one function. But several shortcuts can be assigned to one and the same function (I assigned combinations with Ctrl-Super in addition to Ctrl-Alt, because Ctrl-Super can be pressed together with the thumb, at least on my keyboard. One can maintain the default ones, as long as no conflicts arise.

List length for the relations can be reduced by categorizing:

* by keys present in the combination
* by range of topics on the other list.

Currently the second list is organized by categories on the lower part of the dialog. But it is not always obvious, into which category a particular one falls. Therefore there is a search function. Unfortunately it does not find occurrences in collapsed subcategories, e.g. Heading 1, 2, ..., even if the category All is selected. I consider this a bug.

As there is a search function on the second list, one might consider dealing with a single long list which shortens itself while one is typing a search item.

In a similar manner, the first ist might be provided with a search field: If you press keys in sequence, they are added to the list and the list of keys shortens itself while keys are accumulated: e.g. F shows all combinations with F, if one added a modifier, e.g. Shift, it reduces itself to combinations with Shift-F, if one adds Ctrl, only combinations with Ctrl are shown.

In the search field, this might be shown as »Ctrl Shift F« and if one deletes F from that, i.e. »Ctrl Shift«, the list becomes larger again. 

An alternative would be to take any alphabetical key as »Alphabetic« and show this placeholder instead. In addition one could center the resultant list around it. Then all numeric keys would be treated as »Numeric«, all edit keys as »Edit«, all Function keys as »Fx« and all other keys as »other«, but then one needs to provide a scrollable overview of proper height.

One can completely do without the intermediate categories in the functions part. I would show the function names and below each  - if present- the key combinations assigned to them as a right-adjusted entry. 

Then one has only two lists: both can be long and scrollable: one might display them side by side, each with its search field to the left of it. I would arrange delete and other finalization keys at the bottom of the dialog.

If a key combination is already assigned and it shall be assigned differently, one first has to delete the previous assignment.

It looks like these settings are stored in LOs elephant memory, which under  Linux is ~/.config/libreofficedev/4/user/registrymodifications.xcu. I would prefer a separate file for it, in order to more easily transplant the selected configuration to another user.