Description: This has been first noted in Bug 142959, but I think it deserves a separate ticket. IMO the selection border in Calc (i.e. the border that marks the current cell) is drawn in a suboptimal way. It's drawn *within* the cell space thus eating space from the information in focus (the current cell). IMO Excel does it in a smarter way. Excel draws the border around the cell, but the border is *beyond* the cell so that the "interesting" information is not "cropped". See the attached images that should explain what I mean. Steps to Reproduce: Create an empty sheet and put the "cursor" to the cell B2. Actual Results: The selection border is within the cell. Expected Results: The selection border is beyond the cell. Reproducible: Always User Profile Reset: No Additional Info: This would make Calc visually more attractive.
Created attachment 174089 [details] Selection in Calc
Created attachment 174090 [details] Selection in Excel
Made the rectangle slightly larger and adjust it according the selection. When you zoom in the line width grows up to 4px.
I very agree. The active cell border should be drawn around the current cell. This was the best behavior MS Excel ever did. There may still compatibility-issues inside LO Calc with double cell orders but drawing a 2 pixel wide highlighting border (or maybe even 3) should solve this. This would address the problem that Calc covers the current cell border color.
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c32994e22ff291b0227ed74de6d0d050cf0901c8 Resolves tdf#143733 - Make selection border wider It will be available in 7.4.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Thanks for implementing! Are there screenshots of the new feature? If possible, with different zoom levels. Could you attach them to the issue? Thank you!
Created attachment 177730 [details] Screenshot Zoom at 50, 100 and 200% using KDE but with gtk3 VCL.
Thank you for creating the attachment! May I add some comments? 1. Zoom 50%: The border is very uneven. Top and right lines are much thicker than the bottom and left ones. Besides, the bottom line is *within* the cell (and the subject of this ticket was to place it outside the cell). But I personally never work at 50% zoom hence this case is not important for me. 2. Zoom 100%. I see that the left and top lines are half within and half outside the cell. Could we make the lines completely outside the cell so that no inner space is eaten by the border at all? The right and the bottom lines are mainly *within* the cell, i.e. the border is not drawn in a symmentical way. Could you please also fix that? 3. Zoom 200%. Same comments as for 100% apply. Also, because there are still issues with this, could we reactivate the ticket? I think it would be an overkill to open a new one for those. Thank you!
(In reply to al.le from comment #8) > 1. Zoom 50%: The border is very uneven. Some aliasing or rounding issue, haven't seen it on Windows. Ultimately I cannot do much without spoiling the 100% too much. Goal was to keep the size at 100% as close as possible to what we had before and to make it smaller at 50% and reasonably larger when zoomed in. Plus, lines should always be centered on the border. > 2. ...Could we make the lines completely outside the cell Yes, but why? To keep the content free of formatting? Please also consider left- and top-most cells. Please test the patch with a nightly build. Looking at pictures can be misleading. And yes, you can reopen the ticket if needed.
If I'm not mistaken, the border would look better if you add "+1" to the right and bottom coordinates (which was deleted with the commit). At least with 100% and 200%. I.e. basegfx::B2DRange aRB(rRA.Left() - MinSize - fZoom, rRA.Top() - MinSize - fZoom, rRA.Right() + MinSize + fZoom + 1, rRA.Bottom() + MinSize + fZoom + 1);
Since the result is still not 100% satisfying, I reactivate the ticket.
> Please also consider left- and top-most cells. I checked how it's done in Excel. They have marks in the row and column headings that mark the current cell. The marks have the same color as the border. If e.g. a left most cell is selected, the mark becomes the left side of the border. Since LO does not have such marks, this solution would not fit here. Also, I've checked that Excel draws the border very accurately regardles of the zoom. There are no rounding effects at all. Everything is always exact to the pixel.
fml2: can you confirm that have you tested a recent daily build? If so, do you find the current state satisfactory? https://dev-builds.libreoffice.org/daily/master/current.html
I've tried it with the build 2022-04-13 03:23:47. The border looks better now, i.e. it is drawn symmetrically around the cell. But the main point of this issue is still missed since the border is still drawn *within* the cell and not "outside" of it.
[Automated Action] NeedInfo-To-Unconfirmed
Verified in 24.2, and added to release notes: https://wiki.documentfoundation.org/index.php?title=ReleaseNotes%2F7.4&type=revision&diff=677789&oldid=650328
Coming from bug 154815 (the wider border now cuts off parts of my cell text, see attachment): Is there any chance to make the adaption of selection border width with zoom level optional or, respectively, make the actual width configurable somehow?
*** Bug 154815 has been marked as a duplicate of this bug. ***
Created attachment 193895 [details] Focus rectangle outside New tentative patch https://gerrit.libreoffice.org/c/core/+/166870 moves the focus rectangle out of the actual cell. It considers the zoom factor; the screenshot is taken at 100%.
Not sure about the extra padding between cell border and focus rectangle. Makes it larger than necessary to just prevent cutting off highlighted cell content. Even cuts considerably into neighboring cells now on top of that. Also looks a bit strange to me. Could this extra padding be avoided/removed? Would probably be OK then. (I would actually still prefer the much more subtle solution of simply having a thinner or configurable width for the focus rectangle, though.)
How does this look for the cell A1?
(In reply to flklb-bugs from comment #20) > Not sure about the extra padding between cell border and focus rectangle. > Makes it larger than necessary to just prevent cutting off highlighted cell > content. Even cuts considerably into neighboring cells now on top of that. > Also looks a bit strange to me. > > Could this extra padding be avoided/removed? Would probably be OK then. See related bug 108240. It would be useful to avoid hiding cell borders. That's what Apple's Numbers does, for example. But it's true that Numbers' cursor is significantly thinner: attachment 188313 [details].
(In reply to flklb-bugs from comment #20) > (I would actually still prefer the much more subtle solution of simply > having a thinner or configurable width for the focus rectangle, though.) Introduced for bug 158958 per expert option NoteIndicator.
(In reply to Heiko Tietze from comment #23) > (In reply to flklb-bugs from comment #20) > > (I would actually still prefer the much more subtle solution of simply > > having a thinner or configurable width for the focus rectangle, though.) > Introduced for bug 158958 per expert option NoteIndicator. No. NoteIndicator influences the comment indicator, not the width of the selection border.
(In reply to ady from comment #24) > NoteIndicator influences the comment indicator /me facepalm ;-)
Heiko Tietze committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9e7d70230212ab95cda957a0fe51e37f7ca95021 Related tdf#143733 - Cell focus must not cover content It will be available in 24.8.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I say let’s take the change slowly, avoiding both knee-jerk reactions and unnecessary bikeshedding. And avoid reopening old bugs :)
There is a regression from 7.1 that is influencing how this looks after a certain number of rows: bug 153624 comment 9.
@Heiko Tietze Maybe, you could consider possibility to make this change optional (implement some checkbox in settings or something). I very much realise the rationale behind this request, but the issue has never troubled some of users. And new look does not appease anyone. Anyway, it is always good to have a choice, especially, when it comes to aesthetics (admittedly, it means more work for a programmer...).
(In reply to Sergey Nemna from comment #29) And new look does not appease anyone. More opinions please. I'm against the suggested option for this visual detail.
(In reply to Heiko Tietze from comment #30) > (In reply to Sergey Nemna from comment #29) > And new look does not appease anyone. > More opinions please. > > I'm against the suggested option for this visual detail. Well, enforcing changes in something people have got used to without providing option to switch back is typical for... some companies. I mean irreversible changes done without good, obvious and well-justified reasons. I am for changes, but against enforcing. But it is just a personal opinion, feel free to disregard it.
(In reply to Sergey Nemna from comment #31) > (In reply to Heiko Tietze from comment #30) > > (In reply to Sergey Nemna from comment #29) > > And new look does not appease anyone. > > More opinions please. > > > > I'm against the suggested option for this visual detail. > > Well, enforcing changes in something people have got used to without > providing option to switch back is typical for... some companies. I mean > irreversible changes done without good, obvious and well-justified reasons. > I am for changes, but against enforcing. > > But it is just a personal opinion, feel free to disregard it. Having an option always means an additional maintenance cost. Every option needs to have its own automated testing, code maintenance to adapt to compiler and standard changes etc.
Welcome to the core issue of discussing UI. Let me add another personal opinion: I for one am enjoying the clear selection and the fact it is outside the selected cell helps me to focus on the cell content and prevents messing around with cell content and. decreasing visibility of e.g. cell comment indicator. Also cell highlighting has come a long way on macOS. We went from "no support for system accent color" to supporting that and ensuring good visibility for both dark and light mode. UX has improved a lot for the past years and are now in a good state. Nice to see the progress. +1 for the change.