Bug Hunting Session
Bug 79466 - CONFIGURATION: feature request - key mappings
Summary: CONFIGURATION: feature request - key mappings
Status: RESOLVED INVALID
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.4.2 release
Hardware: Other Windows (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: BSA
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-30 21:01 UTC by pb
Modified: 2018-09-22 20:36 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description pb 2014-05-30 21:01:36 UTC
Problem description: 
Insert column key mapping is different than Excel.

Steps to reproduce:
not applicable

Current behavior:

Expected behavior:
alt-i alt-c should insert a column.

I don't see any way to customize that behavior.  For example, you could either let me customize the menu-walking keys, or you could let me assign multi-key keyboard shortcuts.

I haven't checked, but I assume that also the row insert will not be alt-i alt-r.
              
Operating System: Windows 7
Version: 4.2.4.2 release
Comment 1 m.a.riosv 2014-05-30 22:09:35 UTC
If you have a row(s)/column(s) selected:
[Ctrl][+]    (Ctrl and + keys)
inserts the row(s)/column(s).

If you have selected cell(s)
[Ctrl][+]
opens a box to select what and how to insert.

To eliminate [Ctrl][-] works in the same way.

The proper is change the importance from normal to enhancement, but I think it is a loss battle, I as know it has been so from ever.

To customize the keyboard.
Menu/Tools/Customize - Keyboard.
you can see there all the shortcuts.
Comment 2 pb 2014-05-30 23:02:52 UTC
Yes, it is an enhancement.
I'm aware that there are other ways to do the same thing.
However, a program that wants to emulate the behavior of another program, namely Excel, should have a UI compatibility mode, in particular offer a mode where the keystrokes are the same for the same function.

So, I will reopen this and mark it as an enhancement.

Unfortunately, the "feedback" process from the app did not seem to offer any choice as to whether the report is a bug or enhancement.  I guess that is yet another bug.
Comment 3 m.a.riosv 2014-05-30 23:38:50 UTC
Why do you think LibreOffice wants to emulate Excel?, have you see such comment emitted from LIbreOffice?

Sorry but I think LibreOffice it's not a free clone of excel, and it is not intended to be.

Are users asking for that.
In my case I have use excel exceptionally in more than thirty years, so they are not defaults for me, but in this case calc have the same defaults as 123.
Even more as I have found, those are default keys in excel.
http://excel-tips.blogspot.com.es/2005/08/insert-new-row-or-column-excel.html

Get a community consensus for those changes in defaults, seems to me near to impossible.

In anyway of course you are free to ask for what you like, this is a free community. But please understand that others like myself also are free not to be agree with those changes.
Comment 4 pb 2014-05-31 00:31:53 UTC
Wow, you guys are quite fascist!  First of all, it's obvious that all of LibreOffice is mainly an open source version of microsoft's products, and that makes sense, since those are the most widely used such products.  Perhaps the designers of LibreOffice or its predecessors felt that the defaults in 1-2-3 were more intuitive, so decided to use those, rather than the weird ones that microsoft chose.  Nevertheless, the great bulk of users I'm quite confident migrate to LO from MS, not from Lotus/IBM.

Second, I am suggesting that you allow customization of some keystrokes that are currently not customizeable.  The keystrokes I want are not able to be customized.  That, too, is due to bad design.  In addition, the customization UI is poorly designed.

Furthermore, the logic you present in your link is that "excel can do X, LO can also do X, therefore your suggestion that because excel can do Y LO should also be able to do Y is invalid."  That is specious reasoning.

I am not going to create a political movement before I suggest an improvement.  If those who do the coding do not want to change it, fine, there is plenty of other work that needs to be done.  But don't tell me to build some consensus.  Decide what to do based on the merits, not on politics.
Comment 5 pb 2014-05-31 00:37:25 UTC
Actually, I just noticed that even in your link about excel, the very first comment is:

----
Randy said...
    Why not just use the keyboard shortcuts for the menu options to insert rows and columns? That is:
    Alt-i, r = insert row
    Alt-i, c = insert column
----

Those are exactly the ones I was looking for in my original bug report.  (Although I think I said alt-i, alt-c, not just alt-i, c (on my version they both work).

And, those are also excel defaults.
Comment 6 Michael Meeks 2014-05-31 16:25:56 UTC
pb: I'm amused at your political slur; particularly while recommending not talking to eg. the UX guys to build consensus, but just doing it unilaterally ! =)

Either way - personally I'd like the k/b shortcuts to be as configurable and familiar to people as possible. That raises some significant challenges with the existing menus - as you outline below. I like both your ideas for multi-key shortcuts [ we want to get those emacs users included ], and/or configuring menu shortcuts [ I imagine that could already be done by disabling / renaming / adding menu items with the shortcut you want ? ].

Anyhow - patches that meet the needs of both existing, and new users [ ie. don't just tweak the shortcuts ;-] gratefully received - we're never short of good ideas for things to work on; only of people to put in the hard work to make them happen.

m.a.riosv: thanks for the reason & sanity you bring =)
Comment 7 pb 2014-05-31 17:42:36 UTC
(In reply to comment #6)
Thank you for a less dismissive reply.

The multi-key shortcut already exists -- it is the keyboard walk of the menus.  In this case, it is alt-i (insert menu), l (co*l*umn).  In the case of excel, it is instead alt-i (insert menu), c (*c*olumn).  The only difference is in the choice of which letter represents "column."  I don't know why that choice was made;  maybe it was a conscious decision for a good reason (e.g., to be the same as 1-2-3), or maybe it was a random decision (e.g., 'c' had been used for something else already, or just totally random).

At this point, whether or not there was originally a rational reason to use 'l', there are probably people who already use it, and therefore would be unhappy if it were changed.

The more general solution, as we both point out, is to make the multi-key keyboard mappings customizable.  Yes, I am an emacs user, for even longer than mariosv either did or didn't use excel (not sure exactly what he meant), so multi-key keyboard mappings are not exactly a groundbreaking technology.

If there is no rational reason to use 

> pb: I'm amused at your political slur; particularly while recommending not
> talking to eg. the UX guys to build consensus, but just doing it
> unilaterally ! =)
> 
> Either way - personally I'd like the k/b shortcuts to be as configurable and
> familiar to people as possible. That raises some significant challenges with
> the existing menus - as you outline below. I like both your ideas for
> multi-key shortcuts [ we want to get those emacs users included ], and/or
> configuring menu shortcuts [ I imagine that could already be done by
> disabling / renaming / adding menu items with the shortcut you want ? ].
> 
> Anyhow - patches that meet the needs of both existing, and new users [ ie.
> don't just tweak the shortcuts ;-] gratefully received - we're never short
> of good ideas for things to work on; only of people to put in the hard work
> to make them happen.
> 
> m.a.riosv: thanks for the reason & sanity you bring =)
Comment 8 pb 2014-05-31 17:44:28 UTC
(In reply to comment #7)
Sorry, excise that last line:  "If there is no rational reason to use ";  should have been deleted.

> (In reply to comment #6)
> Thank you for a less dismissive reply.
> 
> The multi-key shortcut already exists -- it is the keyboard walk of the
> menus.  In this case, it is alt-i (insert menu), l (co*l*umn).  In the case
> of excel, it is instead alt-i (insert menu), c (*c*olumn).  The only
> difference is in the choice of which letter represents "column."  I don't
> know why that choice was made;  maybe it was a conscious decision for a good
> reason (e.g., to be the same as 1-2-3), or maybe it was a random decision
> (e.g., 'c' had been used for something else already, or just totally random).
> 
> At this point, whether or not there was originally a rational reason to use
> 'l', there are probably people who already use it, and therefore would be
> unhappy if it were changed.
> 
> The more general solution, as we both point out, is to make the multi-key
> keyboard mappings customizable.  Yes, I am an emacs user, for even longer
> than mariosv either did or didn't use excel (not sure exactly what he
> meant), so multi-key keyboard mappings are not exactly a groundbreaking
> technology.
> 
> If there is no rational reason to use 
> 
> > pb: I'm amused at your political slur; particularly while recommending not
> > talking to eg. the UX guys to build consensus, but just doing it
> > unilaterally ! =)
> > 
> > Either way - personally I'd like the k/b shortcuts to be as configurable and
> > familiar to people as possible. That raises some significant challenges with
> > the existing menus - as you outline below. I like both your ideas for
> > multi-key shortcuts [ we want to get those emacs users included ], and/or
> > configuring menu shortcuts [ I imagine that could already be done by
> > disabling / renaming / adding menu items with the shortcut you want ? ].
> > 
> > Anyhow - patches that meet the needs of both existing, and new users [ ie.
> > don't just tweak the shortcuts ;-] gratefully received - we're never short
> > of good ideas for things to work on; only of people to put in the hard work
> > to make them happen.
> > 
> > m.a.riosv: thanks for the reason & sanity you bring =)
Comment 9 Michael Meeks 2014-05-31 18:56:32 UTC
> Thank you for a less dismissive reply.

Now then; lets be friendly =) Your summary re-hashes what we've discussed helpfully.

> Yes, I am an emacs user

Hah - I sniffed out a fellow developer who cares about, and could help implement this; which is great news =) want some code pointers ? I guess ideally we would configure multi-key mappings inside framework/ - however, particularly ones beginning with Alt ie. M-<x>; which is strongly bound to the menus will prolly need help from VCL.

Failing that, it would be well worth (as Mario suggests) just asking the UX advise or users list to see if people would complain if the English accelerator for this one was changed to make it more familiar for people: possibly we don't need much coding here; but as Mario says - we do indeed need to ask / build a bit of consensus there =) [ AFAICS we have changed several keybindings in the last while - my insert->image is not where it used to be eg. ;-].

Thanks !
Comment 10 pb 2014-05-31 20:09:45 UTC
(In reply to comment #9)

While I count myself as a programmer, I'm not sure I merit the label "developer."  What's worse, my coding in recent years has been fairly trivial stuff, I don't have much time to devote to it these days, my previous looks at open-source code have left me at sea due to lack of documentation, and I'm not currently even set up to actually run a compiler.

But, if you point me to the file(s) that are involved, I can at least look at it.

Also, I don't know how to communicate with the ux people, other than right here?

> > Thank you for a less dismissive reply.
> 
> Now then; lets be friendly =) Your summary re-hashes what we've discussed
> helpfully.
> 
> > Yes, I am an emacs user
> 
> Hah - I sniffed out a fellow developer who cares about, and could help
> implement this; which is great news =) want some code pointers ? I guess
> ideally we would configure multi-key mappings inside framework/ - however,
> particularly ones beginning with Alt ie. M-<x>; which is strongly bound to
> the menus will prolly need help from VCL.
> 
> Failing that, it would be well worth (as Mario suggests) just asking the UX
> advise or users list to see if people would complain if the English
> accelerator for this one was changed to make it more familiar for people:
> possibly we don't need much coding here; but as Mario says - we do indeed
> need to ask / build a bit of consensus there =) [ AFAICS we have changed
> several keybindings in the last while - my insert->image is not where it
> used to be eg. ;-].
> 
> Thanks !
Comment 11 m.a.riosv 2014-05-31 22:23:21 UTC
Hi Michael,
thanks for the intervention.
I don't see too much understanding from their side, but hope the fire is 
off.

Best regards.
Miguel Ángel.


El 31/05/14 18:25, bugzilla-daemon@freedesktop.org escribió:
> https://bugs.freedesktop.org/show_bug.cgi?id=79466
>
> Michael Meeks <michael.meeks@collabora.com> changed:
>
>             What    |Removed                     |Added
> ----------------------------------------------------------------------------
>               Status|UNCONFIRMED                 |NEW
>             Severity|normal                      |enhancement
>                   CC|                            |michael.meeks@collabora.com
>       Ever confirmed|0                           |1
>
> --- Comment #6 from Michael Meeks <michael.meeks@collabora.com> ---
> pb: I'm amused at your political slur; particularly while recommending not
> talking to eg. the UX guys to build consensus, but just doing it unilaterally !
> =)
>
> Either way - personally I'd like the k/b shortcuts to be as configurable and
> familiar to people as possible. That raises some significant challenges with
> the existing menus - as you outline below. I like both your ideas for multi-key
> shortcuts [ we want to get those emacs users included ], and/or configuring
> menu shortcuts [ I imagine that could already be done by disabling / renaming /
> adding menu items with the shortcut you want ? ].
>
> Anyhow - patches that meet the needs of both existing, and new users [ ie.
> don't just tweak the shortcuts ;-] gratefully received - we're never short of
> good ideas for things to work on; only of people to put in the hard work to
> make them happen.
>
> m.a.riosv: thanks for the reason & sanity you bring =)
>
Comment 12 pb 2014-05-31 22:52:48 UTC
(In reply to comment #11)
In view of the continuing hostility, I retract my offer to look at the code.

> Hi Michael,
> thanks for the intervention.
> I don't see too much understanding from their side, but hope the fire is 
> off.
> 
> Best regards.
> Miguel Ángel.
> 
> 
> El 31/05/14 18:25, bugzilla-daemon@freedesktop.org escribió:
> > https://bugs.freedesktop.org/show_bug.cgi?id=79466
> >
> > Michael Meeks <michael.meeks@collabora.com> changed:
> >
> >             What    |Removed                     |Added
> > ----------------------------------------------------------------------------
> >               Status|UNCONFIRMED                 |NEW
> >             Severity|normal                      |enhancement
> >                   CC|                            |michael.meeks@collabora.com
> >       Ever confirmed|0                           |1
> >
> > --- Comment #6 from Michael Meeks <michael.meeks@collabora.com> ---
> > pb: I'm amused at your political slur; particularly while recommending not
> > talking to eg. the UX guys to build consensus, but just doing it unilaterally !
> > =)
> >
> > Either way - personally I'd like the k/b shortcuts to be as configurable and
> > familiar to people as possible. That raises some significant challenges with
> > the existing menus - as you outline below. I like both your ideas for multi-key
> > shortcuts [ we want to get those emacs users included ], and/or configuring
> > menu shortcuts [ I imagine that could already be done by disabling / renaming /
> > adding menu items with the shortcut you want ? ].
> >
> > Anyhow - patches that meet the needs of both existing, and new users [ ie.
> > don't just tweak the shortcuts ;-] gratefully received - we're never short of
> > good ideas for things to work on; only of people to put in the hard work to
> > make them happen.
> >
> > m.a.riosv: thanks for the reason & sanity you bring =)
> >
Comment 13 pb 2014-06-01 07:12:46 UTC
Ok, I have figured out how to trick the UI into behaving the way I want.

There appears to be some (not immediately obvious to my feeble brain) algorithm that decides which letter of the submenu command will be used for keyboard walking of the menus, as opposed to that being hardwired.  (In the version of excel I use, the user can set this letter with a sentinel character in the command name via the customize feature, which incidentally is incredibly klunky in excel, but I see no similar sentinel char mechanism in LO.)

So, it turns out that it appears to be sufficient to use the LO customization UI to just change the order of submenus in the 'insert' menu, so that 'Cells...' comes after 'Columns' rather than the default of before.  In that case the mystery algorithm chooses the 'C' of 'Columns' (presumably because it is seen sooner), rather than the 'C' of 'Cells...', and therefore "alt-i alt-c" inserts a column as I want.

However, although this behavior allows me to achieve my desired keystroke behavior, it is actually a bug:

Namely, changing the *order* of items in a menu should not also have the side effect of changing the *keystroke sequence* that invokes that command.
Comment 14 Michael Meeks 2014-06-02 09:52:53 UTC
pb: glad you found a workaround; some people are more offended by being called certain names than others, JFYI.

http://www.libreoffice.org/get-help/mailing-lists/

I'd poke the design list, or if you're actively going to code on it the 'ux-advise' list =)

Also - by now this bug is waay too long and tangled, I'd re-file in a more pithy form with a 'see also' reference to this one in order to have a helpful discussion.

Thanks !
Comment 15 Thomas Lendo 2018-09-22 20:36:45 UTC
I close this bug as INVALID due to comment 14 four years ago. Please open a new bug with a specific enhancement proposal.