Created attachment 194909 [details] Cell selection rectangle in LO 24.2, 24.8 and MS Excel Sometime over the past few months, the cell selection rectangle was altered - enlarged, so that instead of covering several pixels on the side of the cell, it skips a few pixels outside, then covers several pixels in the surrounding cells. This is very bad: It trades one readability problem for another, larger, readability problem - larger in affected area in number of cells. The previous state of affairs was better. And even better would be to make the selection rectangle narrower, and draw it on both sides of the cell border - like MS Excel does. Attaching a collage of screenshots to illustrate this.
We are having a similar discussion in bug 161709. How about we mark this one as duplicate and have the discussion there?
(In reply to Rafael Lima from comment #1) It's not really the same complaint: Aesthetics vs hiding other cell contents. Let's start by marking these related and I'll join the discussion there.
also see bug 143733 bug 161204 bug 161234 *** This bug has been marked as a duplicate of bug 161709 ***
(In reply to V Stuart Foote from comment #3) > also see > bug 143733 > bug 161204 > bug 161234 Those are all fixed bugs. Anyway, this is not a dupe.
Of course it is, as your comments in the existing discussion on bug 161709 confirm . While the see also list of comment 3 are germane to how the current state of the cell selection outline has evolved. And frankly it would be nice if you would take the time to review BZ for issues (open or resolved) before spamming us all and opening new orphaned/nuisance bugs for issues already under review. That leaves less mess in BZ for QA review to have to clean up. And when QA does edit, how about graciously accepting when you've been called out on redundant submission and accepting the decision. *** This bug has been marked as a duplicate of bug 161709 ***
(In reply to V Stuart Foote from comment #5) > Of course it is, as your comments in the existing discussion on bug 161709 > confirm. So, you're saying that because I obliged Rafael to conduct the discussion on one bug, this bug should be marked duplicate? Great way to incentivize courtesy on BZ. > And frankly it would be nice if you would take the time to review BZ for > issues (open or resolved) before spamming us all and opening new > orphaned/nuisance bugs for issues already under review. I actually do that, but BZ search is rather weak so sometimes it misses. And it's easier for me to miss when it's not a part of the bug tree which I'm familiar with. I will try and remember to enable the search for resolved bugs rather than sticking to unresolved ones. > That leaves less mess in BZ for QA review to have to clean up. And when QA > does edit, how about graciously accepting when you've been called out on > redundant submission and accepting the decision. "Grace" means not making arbitrary decisions after a previous discussion went a different way. LO QA is a collaborative effort, not something embodied in your person. Argue your case like anybody else. If you were to suggest you wanted to roll up the two bugs into one, change the title of 161709 accordingly, then mark this one as a dupe - I would have no problem with that.
*** This bug has been marked as a duplicate of bug 161709 ***