Description: Improve column/row highlighting in Calc After Sahil's patches for bug 33201 we have the opportunity to highlight current rows/columns by cursor placement (use Tools -> Options -> LibreOffice Calc -> View -> Column/Row highlighting option for enabling). It works great if you select only one cell. But if you try to select cell range then that feature doesn't work as I expected. Look at the image in attachment -> I selected some cell range but Calc highlighted only one row and only one column instead all rows/all columns for cell range. I suggest to change current behavior to more right. Steps to Reproduce: - Actual Results: Columns/rows highlighting works only for one selected cell even if you selected some cell range Expected Results: Columns/rows highlighting works for any amount of selected cells Reproducible: Always User Profile Reset: No Additional Info: Version: 24.2.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a9ad36ae46ff76c0d59b0d170314fdd3a9ee5d35 CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win Locale: ru-RU (ru_RU); UI: en-US Calc: CL threaded
Created attachment 191301 [details] Image with problem
I tend to agree with this. The first time I tested the feature, I was expecting that selecting a range would highlight all rows and columns in the selection. The resulting behavior is also weird when cells are merged and when the user select multiple ranges.
FWIW, the additional row+column highlighting is supposed to help in easier location of the cell that has the current focus. Expanding the extra row+column highlighting to cover every selected range might be counterproductive regarding the original goal of the feature. IMO, the new optional row+column highlighting should be relevant for cell's _focus_, not for range _selection_, which already has its own highlight, both on the cell/range itself and on the row/column headers. In the "simpler range" case, the "home" cell of the selection has its row+column highlighted, so the range is easily seen, not to mention it is all already highlighted by itself and at the row/column headers. What would be expected to be highlighted if there are several non-contiguous ranges selected? IMO, that would not be useful. BTW, as an additional help for users, the traditional Name Box shows the cell or range (either focused or selected). I'm not convinced that expanding the row+column highlighting to the entire selection would be an improvement; I'm worried it would be counterproductive.
I'm with Ady
So should the extra highlighting be deactivated in case multiple cells are selected?
(In reply to m.a.riosv from comment #4) > I'm with Ady Me too. => NAB/WF And I think it's not a good idea to switch the feature on/off depending on range selection.
(In reply to ady from comment #3) > In the "simpler range" case, the "home" cell of the selection has its > row+column highlighted, so the range is easily seen, not to mention it is > all already highlighted by itself and at the row/column headers. Note that the goal of the column/row highlight feature is not *finding* a focused / selected cell: the real goal os to have an easy way to see the *context* - i.e., the other cells in the same row and in the same column, like headers, correspondig record data, and so on. Finding the cell is only a not-really-important aspect here, with borders and cell highlichting and row/column header highlighting already serving "find it" goal. And the "see the related data" is a good reason to implement Roman's proposal; with a limitation of only simple case - at least initially. Multi-selection could *possibly* also use it - but that is debatable.
(In reply to Mike Kaganski from comment #7) > And the "see the related data" is a good reason to implement Roman's > proposal Highlighting is useful for contrast, to bring attention to some area. Too much different highlighted areas would beat the goal, and can even be counterproductive. If we talk about seeing related data, Calc lacks the (basic) possibility of tracing precedents (and dependents) on cells located on other worksheets (tdf#63087); that's much more relevant and much more useful regarding related data IMO.
(In reply to ady from comment #8) > Highlighting is useful for contrast, to bring attention to some area. Too > much different highlighted areas would beat the goal, and can even be > counterproductive. Highlight is useful for whatever is useful for a user who enables the feature. Multiselection is not a topic here yet, given that my wording was "with a limitation of only simple case"; for simple case, there will be no more "different highlighted areas" than with current implementation - only size of the areas will be different. > If we talk about seeing related data, Calc lacks the (basic) possibility of > tracing precedents (and dependents) on cells located on other worksheets > (tdf#63087); that's much more relevant and much more useful regarding > related data IMO. This is completely irrelevant. Please avoid such a bad thing as "let's not do something that some person can easily do, just because I thikk there is also another possible related improvement, not necessarily as easy or suitable for the person who implemented *this* feature".
(In reply to ady from comment #8) > If we talk about seeing related data, Calc lacks the (basic) possibility of > tracing precedents (and dependents) on cells located on other worksheets > (tdf#63087); that's much more relevant and much more useful regarding > related data IMO. Additionally, this is a *wrong* idea. Tracking precedents / dependents is completely orthogonal to the basic idea of tables as structured representation of data: precedents / dependents allow to *build* the data, but not to *use* it - because table represents records, with came type of data in each record in the same position; each record having different data belonging to the same entity. Seeing different pieces belonging to the same entity; or same data of different entities - is the most important aspect of *tabular* representation. Comapring apples to oranges, and calling aspects of *creating* tables "much more useful" than aspects of *using* tables is counter-productive.