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
LO 3.4 rc1 - the problem still persists,
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!
+1 Andrew
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.
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.
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?
(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.
NOTABUG once again in reference to the *original* report.
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.
Using 3.3 until someone brings the bug back.
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.
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.
OOo released v3.4 with the bug
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...
@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!
@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.
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.
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 !
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
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 :-)
Version is the oldest version that we know the problem exists - reverted change of version
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
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.
and again....;)
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
OK - I'll try to implement this. Any code pointers?
*** Bug 54679 has been marked as a duplicate of this bug. ***
*** Bug 52239 has been marked as a duplicate of this bug. ***
*** Bug 61534 has been marked as a duplicate of this bug. ***
*** Bug 44389 has been marked as a duplicate of this bug. ***
*** Bug 39438 has been marked as a duplicate of this bug. ***
*** Bug 44556 has been marked as a duplicate of this bug. ***
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ž
@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.
We need UX input for where to place it. Requesting such input now
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.
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ž
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.
*** Bug 71536 has been marked as a duplicate of this bug. ***
(In reply to comment #37) > Once I get UX input i will change this accordingly. Marking as NEEDINFO as a try to get one.
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.
I definitely agree on your comments. I hope they do not change the behaviour.
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' )
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).
(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.
After these discussions I have filed a new bug 78711 to request finally a better solution for CTRL+SHIFT+ARROW selection.
(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 ?