I have a spreadsheet where the first column is effectively a header column that I need to keep in view when editing the rest of the table. To achieve this, I positioned the splitter/divider-bar so that the left side contained just column 1 and then my scrolling on the right wouldn't effect the column to the left. So far so good. If I want to edit a cell in column 1 (on the left side of the divide), I wouldn't expect my carefully chosen positioning of the content to the right of the bar to change but as soon as I click in a cell in the left side copy of column 1, the right side scrolls that cell into view too, which is exactly the opposite of what the splitter bar is there to achieve. I don't need two identical instances of the same content in view. I have tried this with selection of cells in col-1 through col-3 on the left and it's the same behaviour My expected behaviour is that on the right the content doesn't scroll in response to selection on the left. Interestingly, the same ISN'T true if I select a cell on the right. The left side DOESN'T scroll!
Also seen on LibreOffice 7.5.3.2 on Linux (OpenSuse Tumbleweed X86_64)
I think what you are after is the "freeze row / column" feature instead of the screen splitter. https://help.libreoffice.org/7.5/en-US/text/scalc/guide/line_fix.html Closing as "not a bug" but let me know if I got that wrong.
I didn't know about the freeze first col/row but that leaves the use case where I have multi row or col headers that I want to 'freeze'. I'd expect the splitters to behave as I described irrespective of the freeze facility. It's still a bug and fixing it would make a more effective solution for multi row/col headers - perhaps add 'freeze using splitters' to the menu
(In reply to Greg from comment #3) > I didn't know about the freeze first col/row but that leaves the use case > where I have multi row or col headers that I want to 'freeze'. I'd expect > the splitters to behave as I described irrespective of the freeze facility. > It's still a bug and fixing it would make a more effective solution for > multi row/col headers - perhaps add 'freeze using splitters' to the menu I have to separate my reply in 2 parts: * The use case presented. * The behavior reported. As for the use-case, there are _either_: * Menu View > Split Window; XOR, * Menu View > Freeze Rows and Columns; XOR, * Menu View > Freeze Cells > Freeze First Column; XOR, * Menu View > Freeze Cells > Freeze First Row. Using one of those alternatives replaces the other alternatives that might have been in use up to that point. This solves the needs of the presented use-case. As to the reported behavior regarding the Split Window, I cannot reproduce it under Windows. If the focus is already on a cell that is seen on the left side *but the same cell is _not_ seen* on the right side of the split view, then the right side is kept unchanged when editing that cell on the left side.
Thanks @stragu OK, I acknowledge that the use-case is somewhat catered for with the freeze menu options but a) unlike the splitter bar solution, the freeze option caters for only one row and column to be frozen b) given that other similar products, with considerably larger market share and UX budgets have opted for doing this with splitter bars. I'd submit that they are an easier solution than having to delve into two levels of menu, both in regards to the immediate ease of execution and the intuitiveness. The current _Freeze_ menu solution should be updated to cater for multiples The _Splitter_ bars should be made functionally equivalent to the _Freeze_ options. And I suggest should be homed at the origin (top left). The control affordance should be visually discernable from the row and column resizer bars
Re my comment of functional equivalence: The Freeze option should include multiples and should show a distinguishable marker in the same row/column as the row/column resizer lines. When deployed, it should use the splitter bars as its means of execution with the additional property of freezing everything to left (col)/ top (row). The splitter bar should probably have a visual indication to show its frozen/scrollable mode The splitter bars will reveal duplicate columns/rows which may or needn't be frozen but which should provide an option to toggle frozen state. It should, when deployed maintain the correct state in the _Freeze_ menu hierarchy
Just another thought re Homing The existing splitter bar widgets are pretty illogically positioned 1/ The row one is top-right 2/ The column one is bottom-right To be logically consistent, the column one should be bottom-left or the row one also bottom-right I suggest that sine these are most likely to be used for showing row/column headers which will be positioned left and top, the splitter widgets should both be placed top-left, at the origin. The direction of mouse travel could determine the type or there could be a control for each at the origin
Bug reports should be about one single issue. Let's focus on what's in the summary: focus moving on one side of the splitter when interacting with the other. (Regarding the position of the controls, please open a new report.) (In reply to Greg from comment #0) > My expected behaviour is that on the right the content doesn't scroll in > response to selection on the left. I can't reproduce that with: Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 695e8742da850bbb15c2e6d2b5d4c99a0daf4925 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Can you please test again in a recent version, preferably 24.2?
This seems to have been fixed for the release I'm using: Version: 24.2.2.2 (X86_64) / LibreOffice Community Build ID: 420(Build:2) CPU threads: 32; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+wayland) Locale: en-GB (en_GB.UTF-8); UI: en-GB Calc: threaded
Thank you for testing again. Let's close this one as "works for me" then, as we're not sure what fixed it. Please open a new report for each single enhancement request you've identified (e.g. control position). Thanks!