[Libreoffice-bugs] [Bug 115052] Allow other keys than from US keyboard as shortcut keys

Tue Mar 24 22:48:39 UTC 2020

https://bugs.documentfoundation.org/show_bug.cgi?id=115052

--- Comment #18 from Janvi <janvi at veith.net> ---
Hello Heiko & UI team,  this bug #115052 is mentioned in my related issues list
but IMHO none of the related issues of any mentioned bugs hits identical 
problems than I tried to describe in bug #131316

To follow your KDE link I booted Kubuntu from USB stick and tried the keyboard
customization dialog what is obviously a result of GSoC2011. The dialog looks
nice but disqualifies for use inside a text editor for several reasons. Most
important: It does not support key key sequences described in bug #131316.

Example for key combination (like it is LO now but not all free combinations
possible)

cntl + shift + q is to press the 3 keys cntl - shift and q same time.
Practically this is already a simple state machine for the reason, a keyboard
reports key up/down codes but I consider this as a pure logical combination.

Example for key sequence (as bug #131316 tries to describe)

cntl + q - s what is to press the two keys cntl  and q, then release both (or
only one or none) and then press the key s. This requires further states for a
state machine implementation. Cntl-Q enters first state, and s enters second
state while the s key used without preceding cntl-q is writing a „s“ character
to the text or doing something else. #131316 mentioned editors can do this.

Here is a „who is who“ keyboard emulation table for some well known text
editors, unfortunable incomplete with many questions marks:

https://en.wikipedia.org/wiki/Comparison_of_text_editors#Key_bindings

Most of them are programmers editors, but some are also multi purpose for
office documents and programmers. Almost all of them can be considered as
„legacy“ style but some are maintained up on today by its enthusiastic user
communities.

To understand the situation, we have to dig a into computer history. Otherwhile
bug reports like: In situation xx shorcut yy is not working“ will continiue and
any patches will make the patchwork more complicated. The first 2 columns of
the link are IBM CUA and MacOS.  Remarkably, this are NO text editors but UI
frameworks while the remaining columns are editors. For the same reason, a 
sustainable patch should be implemented equivalent to this columns.

There is no discussion about todays LO default configuration for Macintosh
should be MacOS and for Microsoft IBM-CUA but the way to reach this should be
different from what LO is doing now. Ideally users expect to be exactly
compatible with Word behaviour.

In the time before the MFC (Microsoft Foundation Class) every editor for CPM
and later DOS came with its own printer driver, screen driver and of coarse its
own keyboard bindings. Starwriter by Marco Börries already supported mouse.
Beside being an LOs ancestor it is a prig candidate for that editor category
with extensive use of key sequences why I mentioned him in my bug report
#131316. That time faded out with Apple, Microsoft SDK/GDI and later the MFC.
Writing a text editor suddenly becomes easy. Framworks like Qt allow system
independend development. Derive your application from the correct class and it
will do what users expect becouse it behaves like everything else. This is a
great benefit as application developers dont have to write a single line for
displays or printers and things like graphical print-preview or PDF output are
simply working. Same time the users dont have to learn how to print a sheet of
paper for every application separate.

Unfortunately, this is not a benefit for the keyboard as some power of the
legacy system keyboards disappeared thereby. And worse, it is not possible to
bring this back by any custom configurations. Further this is not only true for
keyboard bindings but also and less known for mouse input. This bug report only
covers the keyboard bindings. Any OO class concepts with pre wired keyboard
functionality comes to its limits as system wide predefined shortcuts are in
conflict with customized user setup wishes in some situations. An example is
given for Mozilla below. 

With other words: A sustainable solution for LO  (at least for the writer)
should not use any inherited class behaviour for keyboard. A new keyboard input
instance needs to go back to very basic keycode inputs. Key codes are numeric
values for a physical hardware key. Unless character codes, key codes are not
influenced by the system language setup nor any character what is printed on
the key button nor by its modifier keys shift, cntrl, alt or other meta
modifier keys. 

To get in touch with the key codes you can try one of the many pages like 
https://www.w3.org/2002/09/tests/keys.html 

This page also allows to try the keyboard predicament using Mozilla or any
other browser what is also true for LO keyboard setup: Backspace goes to
previous URL for a W10 machine, while cntl-Q is going to quit the browser tabs
for a Gnome desktop. Both cases, this keys cannot be used for a user
assignment. For a web browser or even a spreadsheet calculator this may be
acceptable but never for a document text editors input. For this reason users
will always complain like: In situation xx shorcut yy is not working“. 

There are only very  few combinations „hard wired“ by OS like cntl-alt-del for
Windows and everything else should be allowed. To approximate the many keyboard
problems closer, I suggest to split the task as following:

1) writing a real time state machine to process all keyboard inputs including
UI setup dialog what includes conflict management

2) modifing all used LO classes to disable any default assignments from
keyboard. This should be feasable at least for the Writer. 

3) connect output from 1 to 2

4) configure a default setup for Windows / Apple to make the keyboard like
before.

Improvements according to the many related but reports should be easy now.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/libreoffice-bugs/attachments/20200324/dc7d7fe6/attachment-0001.htm>