Download it now!
Bug 78711 - Improve CTRL+SHIFT+ARROW selection to detect over full range
Summary: Improve CTRL+SHIFT+ARROW selection to detect over full range
Status: RESOLVED WONTFIX
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
4.2.3.3 release
Hardware: Other All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-05-14 21:47 UTC by OfficeUser
Modified: 2016-09-19 16:47 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
TestCase.ods (11.52 KB, application/vnd.oasis.opendocument.spreadsheet)
2014-05-14 21:47 UTC, OfficeUser
Details

Note You need to log in before you can comment on or make changes to this bug.
Description OfficeUser 2014-05-14 21:47:00 UTC
After the discussions in Bug 37230 and Bug 78534 I'm filing a new bug to request finally a better solution for CTRL+SHIFT+ARROW selection.

This solution shell...

- Have a fixed cursor position
- Detect empty/filled and filled/empty transitions over the full selection range (not from a single focal point cell)


For better understanding I provide the following demonstration:

- Open the attached TestCase.odf
- Make sure cursor is set to cell D1
- While holding down SHIFT+CTRL click arrow-left
- While holding down SHIFT+CTRL click arrow-down

Resulting selection: A1:D6

Expected selection (Excel): A1:D4
Comment 1 OfficeUser 2014-05-14 21:47:51 UTC
Created attachment 99046 [details]
TestCase.ods
Comment 2 OfficeUser 2014-05-14 21:51:25 UTC
*** Bug 78534 has been marked as a duplicate of this bug. ***
Comment 3 tmacalp 2014-05-15 01:32:21 UTC
Just to make sure I understand this, you're proposing a third behavior where the selection stops when ANY of the cells on the front of the selection range collide with a empty/non-empty cell?  Basically, it perform a select to block margin on each cell in your currently selected range and stop at the first collision? 

For instance, if we have a selection of A1:C1, and we press ctrl+shift+down, you want it to stop when we encounter ANY change in columns A, B, or C?

In certain situations, that behavior would make things MUCH less efficient than even the non-legacy mode.  For instance, if you had lots of randomly populated columns, it would render ctrl+shift+arrow entirely useless.

I don't have any way to test this under MS Excel, but is this behavior really the new standard?  I see no use for this behavior unless it already is an established standard and is implemented as another option for compatibility.  Even if that is the case, it would still be an enhancement request.  I will mark it as such.

Whatever is decided, please do not modify the newly implemented "Use legacy cursor movement behavior when selecting."  I understand it will no longer be checked by default starting in 4.3, but that's fine as long as it's easy to enable.  I still see it as the only useful selection mode available.
Comment 4 crxssi 2014-05-15 02:42:21 UTC
I don't understand how this bug report is a duplicate of bug 78534 or why it needed to be created.  In any case...

If what tmacalp describes is correct, the proposed third behavior is even more whacky than the recent non-legacy behavior.  Personally, I don't care what Excel does (nor can I find out, since I have no access to it).  I am more concerned with what makes sense.

I and many of my users have been GREATLY upset by the changing of the CTRL+SHIFT+ARROW behavior in LO 4 (to supposedly match the completely illogical Excel behavior), and ecstatic that an option to turn on the proper, 15-year "legacy" behavior was recently added.  Even the mention of another change to CTRL+SHIFT+ARROW behavior makes me want to scream...
Comment 5 OfficeUser 2014-05-15 06:56:31 UTC
After more investigation I found out that Excel does not detect over the full range.

But nevertheless I think this idea is worth to be discussed for LibreOffice.
Comment 6 Joel Madero 2014-05-17 03:08:51 UTC
Hm so this is consistent with Microsoft Office - I'm not sure that this would be good at all ( personally it would interrupt a workflow that I'm used to). That being said, I will request additional input before closing as WONTFIX.
Comment 7 OfficeUser 2014-06-20 05:18:05 UTC
@tmacalp:

You are right, I am proposing a third behaviour. You are understanding my proposal correctly.

1)
[ ] Use legacy cursor movement behaviour when selecting

2)
[X] Use legacy cursor movement behaviour when selecting

3)
My proposal in this Bug 78711.


In fact Excel uses 1), not 3). Saying that Excel would behave like 3) was my mistake. But nevertheless I like number 3). This is why I remain commited to this Bug 78711.
Comment 8 Cor Nouws 2014-06-22 13:25:52 UTC
.
Comment 9 Robinson Tryon (qubit) 2015-12-18 10:24:09 UTC Comment hidden (obsolete)
Comment 10 Xisco Faulí 2016-09-19 16:47:54 UTC Comment hidden (obsolete)