Bug 37230 - Calc shift-ctrl-down/up/left/right keystroke changed its behaviour
Summary: Calc shift-ctrl-down/up/left/right keystroke changed its behaviour
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: ux-advise (show other bugs)
Version:
(earliest affected)
3.4.0 release
Hardware: x86-64 (AMD64) Linux (All)
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.0
Keywords:
: 39438 44389 44556 52239 54679 61534 71536 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-05-15 10:10 UTC by cunio
Modified: 2014-06-22 13:28 UTC (History)
21 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 cunio 2011-05-15 10:10:06 UTC
Previous stable version of LO - 3.3 has quite different behaviour of shift-ctrl-down/up/left/right keystroke.

I would write the old one is well more practical.

How to see the BUG:
1. Lets say I have x values in A column starting from row 1 to 25.
2. When I want to create some y values y=x*x for example,
3. I create formula =A1*A1 in B1 cell, then I copy it to a clipboard (CTRL-C).
4. Then I select (shift-left) cells B1 and A1.
5. When I use shift-ctrl-down:
* in LO3.3 the keystorke selects rows 1-25 of the columns A and B, now I can using shift-right select only column B1:B25 and paste the formula. 
* in LO3.4beta5 the keystorke selects all the A and B column :(, so I cannot use it just to fill the appropriate cells (B1:B25) 

I want back the previous behaviour, the new one is useless
Comment 1 cunio 2011-05-20 04:30:12 UTC
LO 3.4 rc1 - the problem still persists,
Comment 2 Andrew G. Stack 2011-07-20 12:48:23 UTC
My apologies if this is spamming the bug-list but I can confirm that this issue still exists in LibreOffice 3.4.1, OOO340m1 (Build:103).  Since Excel made this change in functionality some time ago, one can argue that this isn't a bug, but a feature.  However, if so, it made using shift-ctrl-arrow as a selection method almost entirely useless, as the original bug submitter stated.  I realize we can't dictate what changes are made in functionality, but I'm another user that would greatly appreciate reverting to the old behavior (or having the option to do so), so much so that I've switched back to an old version of openoffice.org that doesn't do this.

Incidentally, there is a long-standing bug in OO and LO where shift-ctrl-arrow takes your to random corners of the spreadsheet as well, but unfortunately I can't find a way to reproduce it reliably so it'll have to wait.

Thanks for your attention!
Comment 3 m.a.riosv 2011-07-20 14:28:06 UTC
+1 Andrew
Comment 4 Petr Mladek 2011-07-21 05:52:56 UTC
Heh, this can't block the release => lovering severity.

I guess that the behavior has been changed because of compatibility with Excel. Many people might be used to it. We can't make all people happy and can't change the behavior with every release.

I add into Kohei (Calc developer) and Christiph (design team member) into CC. I wonder what they think about it.
Comment 5 Kohei Yoshida 2011-07-21 06:26:50 UTC
Actually the old behavior was a bug because it wasn't using the cell cursor position as the focal point of navigation when expanding selection with keyboard.

And before anyone jumps in, this is not something we can make configurable.  That would make the maintenance a total nightmare.

So, this "new" behavior is not a bug, but the old behavior was.

Sorry if this caused confusion for some people.  But unfortunately there is nothing to fix here.
Comment 6 Andrew G. Stack 2011-07-21 06:42:42 UTC
Kohei, thanks for your response, I understand what you're saying because the selected cell doesn't change as I select blocks of text.  However, I'm going to attempt to convince you that it should:  If I hit an arrow-key, it shifts the selected cell that direction, this is normal navigation of the spreadsheet.  Now, if I hold shift down while hitting that arrow key, it no longer shifts the selected cell anywhere.  Why the inconsistent selection rules?  Is there some productivity enhancement that you get by only selecting a new cell if you're not holding down shift?
Comment 7 Kohei Yoshida 2011-07-21 06:52:03 UTC
(In reply to comment #6)
> Kohei, thanks for your response, I understand what you're saying because the
> selected cell doesn't change as I select blocks of text.  However, I'm going to
> attempt to convince you that it should:  If I hit an arrow-key, it shifts the
> selected cell that direction, this is normal navigation of the spreadsheet. 
> Now, if I hold shift down while hitting that arrow key, it no longer shifts the
> selected cell anywhere.  Why the inconsistent selection rules?  Is there some
> productivity enhancement that you get by only selecting a new cell if you're
> not holding down shift?

Andrew, please open a new bug and attach a test document for this.  What you are describing is not the same as what the reporter described.  There is one known bug that *may* be affecting your particular use case in presence of hidden rows or columns, but that's not what the original reporter has reported.  And my above reply is in response to the original report.
Comment 8 Kohei Yoshida 2011-07-21 06:54:00 UTC
NOTABUG once again in reference to the *original* report.
Comment 9 willy.bueno 2012-03-06 00:00:59 UTC
If anyone uses Calc with tens of thousands of rows like I do, they would agree this is a bug. Because the old behavior has been the behavior since I remembered it using OOO v1.x until LibO v3.3x. If the old behavior was a bug, then it would have been a bug for the past decade. I also don't understand why a superior function is dropped in favor to be compatible to an inferior software. Please bring the BUG back.
Comment 10 von_klatka 2012-03-06 02:57:54 UTC
Using 3.3 until someone brings the bug back.
Comment 11 Andrew G. Stack 2012-03-06 05:54:50 UTC
I issued another bug report on this issue, where we had a more detailed discussion:

https://bugs.freedesktop.org/show_bug.cgi?id=39438

As you can see, the devs really aren't interested in resorting to the old behavior on this issue.  I suspect this is because for some time Excel has done it this way and the Libreoffice devs don't want to deviate from Excel's behavior.  This design decision is really very unfortunate because it means there is no longer any enhanced functionality of Libreoffice relative to Excel, so the result is that I don't want to use either of them now, but when I do have to do something in a spreadsheet, I just use Excel now because it's more universal and the graphing features are easier to deal with.
Comment 12 willy.bueno 2012-03-07 02:58:56 UTC
I wonder if there are any Excel users who uses this particular key stroke combination. It's useless. So if no one uses it in the other camp, how can it be a deviation then. It's like crippling LibO to be like the crippled Excel. Please, I need that bug.
Comment 13 willy.bueno 2012-05-21 04:44:31 UTC
OOo released v3.4 with the bug
Comment 14 crxssi 2013-07-29 20:21:28 UTC
Sorry to comment on a closed "bug", but this issue is extremely important to me (and my 150 business users), and it seemingly has become political.  No matter how many times it is dismissed, many people believe the change in behavior has severely crippled a feature that has been in use for many, many years.  My "power" spreadsheet users are very upset at this change.

The original report (by "cunio") is perhaps too simplistic an illustration and doesn't impart the scope of the problem.  However, the root cause of the issue that Cunio is exactly the same as what Andrew is saying.

I can supply several examples where it is now impossible to quickly and easily select large ranges of cells in Calc with this "new" behavior, if necessary.  here is one such example:

* Create a new spreadsheet.
* Type a list of labels from F20:F25. For the test, you just need a few, but pretend it were many thousands or even sections with gaps in it too.
* Without inserting data and just using ONLY THE KEYBOARD to navigate, change the background color of the cells in the empty column next to your data (G20:G25)  How will you do this easily?
 
Previous behavior solution:
 
* Place your cursor on G20.
* Hold <shift> and press left (selects F20:G21)
* Hold <control><shift> and press <Down>  (select F20:G25)
* Hold <shift> and press <Right> (selects F20:F25) <- what we want 
* Change background color

The new behavior would require someone to press the arrow keys thousands of times, or pressing the page down key hundreds of times, or scrolling forever with the mouse wheel while holding down <shift>.  The old behavior could solve the problem with just a few keystrokes.

This change also broke compatibility with previously recorded macros and will continue to break compatibility with OpenOffice (which does not have this behavior).  Those macros would have expected the active cell to be at the end of a selection, not the beginning.

After much research, it is apparent that this issue has been reported many times and in many different ways.  And quite a few people are upset about the change and yet we can find really no advantage to the changes that were made.  People that are not expert spreadsheet users are not going to care either way.  People coming from Excel are probably not going to care either way, because they have not lost anything.  But those who are more advanced users who have spent a decade or more using OpenOffice and now LibreOffice who are suddenly forced to work around a "broken" behavior are very much going to care.

PS- We tested Gnumeric 1.12 where the cursor action is similar to this change made in LO and yet, somehow, they are able to get the process right by using an invisible cell cursor "locator", so they are able to have the "best of both worlds."  Try it and see...
Comment 15 Joel Madero 2013-07-29 22:18:15 UTC
@crxssi - 

Kohei is one of two experts in Spreadsheet and he has said what was going on - the prior behavior was a bug - a bug that was useful in your case but a bug none the less. 

If your company needs a different behavior there are options including getting a developer in house to work on it as all of the code is available and ready to be poked at -- LibreOffice is quite easy to build (for such a large project) and then you or a developer in house can implement whatever changes you need/want, extensive documentation is online for building and hacking. 

Another option is of course paying for support through a company or waiting to see if the change is implemented for gratis at some point.

Despite this being a show stopper (perhaps) for your company - in the grand scheme of things it is not for the project as a whole - please reference the below flowchart to get an idea how we prioritize (it's one of a few things that go into the order of how bugs are fixed) -  https://wiki.documentfoundation.org/images/0/06/Prioritizing_Bugs_Flowchart.jpg

Kohei - could we somehow incorporate the functionality without the buggy part? If not - I'll avoid commenting further.

Thanks!
Comment 16 crxssi 2013-07-29 22:40:49 UTC
@Joel Madero 

We don't consider it a show stopper right now, but it is near the top of our current "most annoying things about LO" list.  Although based on that flow chart, it seems to place at "Minor:  Makes it substantially harder to make high quality work or require users to not use some features."  Kinda surprised me.

My (our) position is that the old behavior was not a bug, there was nothing broken and it worked just fine.  But if there HAD to be a change for some reason, then my Gnumeric example must kick in... Gnumeric made a similar rework of the controls but without the issues people are reporting here about LO.  I even tested it again today just to make absolutely sure.

Of course, people will all vary in what they believe, and sometimes complex/muddy issues like this one end up with some people not understanding what is meant or even arguing different points or parts without knowing it.  I might be one of them, who knows.  My intent is just to make sure my users have tools that work well for them.
Comment 17 Kohei Yoshida 2013-07-30 02:42:12 UTC
Enhancement request. Make the cursor behavior configurable.  BTW, there were people who requested the current behavior based on how Excel behaves.  So, whatever change we might end up doing MUST be configurable.

If someone cares enough to work on this, we'll be glad to review your patch.
Comment 18 Michael Meeks 2013-07-30 08:15:55 UTC
The gnumeric behaviour sounds interesting; having a compatibility option would be great if someone came up with a patch - although hiding that in the 'about:config' style options piece makes a lot of sense I think.

Thanks for your feedback; we're just in a holding pattern for someone to be interested enough to patch this I guess :-) Joel - thanks for helping to explain things so clearly !
Comment 19 cunio 2013-07-30 11:37:57 UTC
I'm really glad the bug has changed it status to enhancement. I am strongly supporting adding the old one behaviour back this or other way.

As I wrote in the beginning of the topic the old one ctrl/shift/cursor keystroke mode is much more practical regardless of its origin and I see a some supporting votes here.

Thanks
Comment 20 Michael Meeks 2013-07-30 12:24:34 UTC
Cunio: I'm glad you're encouraged; if someone wants to implement this in a suitable way, that's great - we like code contributions. Ultimately code is the form of 'vote' that really counts :-)
Comment 21 Joel Madero 2013-07-30 14:13:19 UTC
Version is the oldest version that we know the problem exists - reverted change of version
Comment 22 Joel Madero 2013-07-30 14:21:45 UTC
PLEASE STOP CHANGING THE VERSION - Read my comments before changing the top part

Actually from history I'm marking this as 3.4.0 release as it looks like that's earlier version that we knew it existed

Please don't mess around with the top section at all unless you know what you're doing as it just wastes QA members time reverting changes
Comment 23 tmacalp 2013-07-30 14:33:48 UTC
Sorry about that!  I didn't change the version intentionally.  I added myself to the cc list at the same time you changed the version, so it reverted.
Comment 24 Joel Madero 2013-07-30 14:39:14 UTC
and again....;)
Comment 25 crxssi 2013-07-30 14:48:32 UTC
I suggest if we want to keep THIS bug/enhancement as the "main" one, then these can now be closed marked as duplicates of THIS bug/enhancement:

Bug 54679
Bug 52239
Bug 61534

Of course, they all still contain valuable information and examples.

I also know the following closed bug reports are also the same issue being reported here, and I personally think they should ALSO be marked as duplicates here to make that clear:

Bug 44389
Bug 44556
Bug 39438
Comment 26 Tomaz Vajngerl 2013-07-31 11:46:43 UTC
OK - I'll try to implement this. Any code pointers?
Comment 27 crxssi 2013-07-31 23:37:20 UTC
*** Bug 54679 has been marked as a duplicate of this bug. ***
Comment 28 crxssi 2013-07-31 23:39:36 UTC
*** Bug 52239 has been marked as a duplicate of this bug. ***
Comment 29 crxssi 2013-07-31 23:41:25 UTC
*** Bug 61534 has been marked as a duplicate of this bug. ***
Comment 30 crxssi 2013-07-31 23:42:51 UTC
*** Bug 44389 has been marked as a duplicate of this bug. ***
Comment 31 crxssi 2013-07-31 23:45:21 UTC
*** Bug 39438 has been marked as a duplicate of this bug. ***
Comment 32 crxssi 2013-07-31 23:48:00 UTC
*** Bug 44556 has been marked as a duplicate of this bug. ***
Comment 33 Tomaz Vajngerl 2013-08-05 20:46:36 UTC
I managed to make this work and the solution is very simple. I don't see any side effects so I guess this is it.

Now I need to make this configurable - any suggestions how to best do this, code pointers? I never made anything configurable and it is too hot to explore by myself. :) Thanks.

Regard, Tomaž
Comment 34 crxssi 2013-08-05 22:44:17 UTC
@Tomaz:

Great news!  I can't help with coding, unfortunately.  But if you are looking for a suggestion as to where it could be placed and worded, I would recommend one of two places:

Tools-> Options-> Calc-> Compatibility-> Key Bindings
 or
Tools-> Options-> Calc-> General-> Input Settings

Wording the actual option will be challenging.  Perhaps an option like "Use legacy cursor movement behavior when selecting" It really is hard to describe in a short phrase.  Another option might be in the upcoming about:config stuff, but I have no idea when/if that is available.
Comment 35 Joel Madero 2013-08-06 02:32:36 UTC
We need UX input for where to place it. Requesting such input now
Comment 36 Commit Notification 2013-08-16 15:54:25 UTC
Tomaž Vajngerl committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=462b28770e4fa3dfa6fe4af71a6776cceb4c4640

fdo#37230 Add legacy cell selection behavior and config. option



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 37 Tomaz Vajngerl 2013-08-16 16:08:30 UTC
Hi,

I have pushed this change to the master. Currently I added a checkbox in (Tools-> Options-> Calc-> General-> Input Settings) and named it "Use legacy cursor movement behavior when selecting". Once I get UX input i will change this accordingly. 

Regards, Tomaž
Comment 38 Kohei Yoshida 2013-08-26 21:55:45 UTC
Per comment 18, the original idea, and one that I agree with, is to hide this option in the brand new "Expert Config" page (formerly known as the "about:config" page), instead of adding yet another check box in our already crowded General options page.  Since the Expert Config lists all options from the configuration tree, no extra work is needed to add items to that list.
Comment 39 Cor Nouws 2013-11-13 20:55:23 UTC
*** Bug 71536 has been marked as a duplicate of this bug. ***
Comment 40 bfoman (inactive) 2014-02-20 18:36:53 UTC
(In reply to comment #37)
> Once I get UX input i will change this accordingly. 

Marking as NEEDINFO as a try to get one.
Comment 41 tmacalp 2014-02-26 04:24:03 UTC
I think this bug should just be closed as “resolved fixed,” since the current implementation addresses the originally reported issue.  Another bug should be opened to modify the toggle location, if anyone is still concerned about cluttering up the calc general options page.

But in my opinion,

* The toggle IS worthy of being featured in its current location, not hidden in the expert config page.  Many users have requested this feature since LO first changed it.  If there is any doubt about its popularity, just look at all of the duplicates and the number of cc's.

* The expert config page is currently very difficult to use and is not yet ready to be the only location for a useful toggle like this.  I love the concept of expert config, but it currently opens at around 1800 pixels wide(not resizable), contains thousands of other options, and is not searchable.

* The reimplemented “Legacy” behavior currently comes as the default in LO 4.2.1, and I think it should stay that way.  It appears to be the gnumeric implementation described above.  It really is a fantastic compromise between old and new behavior.


Whatever the case, thank you very much for the fix and for giving users a choice!  It is a great enhancement and needs to be listed in the 4.2 release notes.
Comment 42 Burak Ural 2014-02-26 07:18:01 UTC
I definitely agree on your comments.

I hope they do not change the behaviour.
Comment 43 panoworks 2014-03-06 11:26:30 UTC
I know the bug tracker isn't the place for 'me too' comments, but to heck with it: me too!  I'm glad that not only 1. It apparently was possible to modify, 2. It apparently was possible to make into a toggle, but 3. It was put in a place where it's easily accessible.  I, for one, am now zooming about the spreadsheet like a bat out of hell without ending up in strange places, spreadsheet limits, or smacking my forehead and using any number of workarounds to get things done.  I would like to thank Tomaž and anybody else involved for making this happen.

I see it didn't make it into the release notes, perhaps as it's still in NEEDINFO state and may still be relocated in the future, so here's my vote for keeping it right where it is and making mention of it in the release notes when applicable.  The only bit I'd maybe change is the name of the toggle - however, that hinges entirely on it not being described in the documentation yet.  Once described, and I'd be happy to help, the toggle name itself would become more clear. ( The same applies to e.g. 'Expand formatting' )
Comment 44 Andrew G. Stack 2014-03-06 11:36:33 UTC
Hello, I am out of the office from March 3rd-13th.  I will only be in intermittent e-mail contact.  If urgent, you can contact Valinda Hubbs  (hubbsvm@ornl.gov; 865-574-4971).
Comment 45 crxssi 2014-03-08 07:19:56 UTC
(In reply to comment #41)
> I think this bug should just be closed as “resolved fixed,” since the
> current implementation addresses the originally reported issue. [...]

I agree with everything you said.

It should be closed as "fixed".
It should be properly documented.
It should be left "on" as default, like it is now.
It should not be moved to expert config.

This is, indeed, a great fix.
Comment 46 OfficeUser 2014-05-14 21:49:15 UTC
After these discussions I have filed a new bug 78711 to request finally a better solution for CTRL+SHIFT+ARROW selection.
Comment 47 Cor Nouws 2014-06-22 13:28:53 UTC
(In reply to comment #41)
> I think this bug should just be closed as “resolved fixed,” since the
> current implementation addresses the originally reported issue.

Yep - doing so now.
Thanks all for their insights.

> Another bug
> should be opened to modify the toggle location, if anyone is still concerned
> about cluttering up the calc general options page.

Anyone ?