Description: Cell selecting fat border looks ugly especially if you selected some cell range. After Rafael's patches we have a strange cell selecting border. And it works ugly if you try to select a cell range (look at the screenshot) I suggest to do one of variants below: 1. Revert Rafael's patches 2. Expand cell selection fat and ugly border to all selected cell range Steps to Reproduce: - Actual Results: - Expected Results: - Reproducible: Always User Profile Reset: No Additional Info: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: d2eab48f697a1e6097778158f623f11306ac7a3d CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: ru-RU (ru_RU); UI: ru-RU Calc: CL threaded
Created attachment 194848 [details] First screenshot
Created attachment 194849 [details] Second screenshot
Precise positioning on Linux. Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 41d26f14fffdb701f6e7ef459a11577725cd0d27 CPU threads: 32; OS: Linux 6.9; UI render: default; VCL: kf5 (cairo+xcb) Locale: de-DE (en_US.UTF-8); UI: en-US Calc: threaded
But confirming the deviance on Windows.
(In reply to Heiko Tietze from comment #4) > But confirming the deviance on Windows. From the screenshot there appear to be a pixel deviation to the right and at the bottom. Is that what you're seeing? I can try to fix it to make sure the distance is the same in all sides. Let me know if this is the expected result.
FTR the wider border was a fix for bug 143733 which requested to make the border wider (actually it is the active cell overlay). Then in bug 161204 we adjusted this new overlay to make it behave better when zooming in and out. At first I found it a bit weird, since I had never seen it before in any other application. But after some time, I found that having a wider cell outline is actually helpful and looks quite nice. IMO the current state does not look ugly. It can be adjusted to look more symmetric, but it is not as ugly as you make it sound.
(In reply to Rafael Lima from comment #5) > From the screenshot there appear to be a pixel deviation to the right and at > the bottom. Is that what you're seeing? Yes, maybe some rounding issue?
(In reply to Rafael Lima from comment #5) > (In reply to Heiko Tietze from comment #4) > > But confirming the deviance on Windows. > > From the screenshot there appear to be a pixel deviation to the right and at > the bottom. Is that what you're seeing? > > I can try to fix it to make sure the distance is the same in all sides. > > Let me know if this is the expected result. Hm, in addition my take was to extend that fat border for all selected cell range, like on mockup (see attach).
Created attachment 194854 [details] Mockup
(In reply to Heiko Tietze from comment #7) > Yes, maybe some rounding issue? Probably a rounding issue. I'll look into it.
(In reply to Roman Kuznetsov from comment #8) > Hm, in addition my take was to extend that fat border for all selected cell > range, like on mockup (see attach). This is what MSO does (except the wider outline) and I would not be against this. However, this proposal would be a total departure from what Calc does. Calc has always had an overlay for the active cell and another for the selection, which is different from what you see in other spreadsheet applications. The existence of a wider active cell outline only made it more obvious. If you would like to propose the change in this mockup, then this ticket should be an enhancement that changes an existing feature.
(In reply to Rafael Lima from comment #11) > This is what MSO does (except the wider outline) and I would not be against > this. We pondered over this option and rejected as it hides the active cell. Typing over a multi-selection is possible in both LibreOffice as well as Excel but only we show clearly where the input goes. Remember, you can select from top to bottom or left to right but also vice versa ending up at the unusual position.
(In reply to Heiko Tietze from comment #12) > Typing over a multi-selection is possible in both LibreOffice as well as > Excel but only we show clearly where the input goes. Remember, you can > select from top to bottom or left to right but also vice versa ending up at > the unusual position. There are other scenarios in which showing the active cell in a different way than the selected area is useful. For example: select a range, type-in, [ENTER] OR [TAB] > the "next active cell" is limited to cycle within the selected range after each [ENTER] or [TAB]. So, showing the active cell in a different way than the selected area is relevant. Another example: multiple non-adjacent ranges are selected. BTW, I do not reproduce this in: Version: 24.8.0.0.beta1+ (X86_64) / LibreOffice Community Build ID: 1b61abc4451d38984338b750d85770ec9871060a CPU threads: 4; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Raster; VCL: win Locale: en-US (es_AR); UI: en-US Calc: threaded So: (In reply to Roman Kuznetsov from comment #0) > Additional Info: > Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community > Build ID: d2eab48f697a1e6097778158f623f11306ac7a3d > CPU threads: 16; OS: Windows 10 X86_64 (10.0 build 19045); UI render: > Skia/Raster; VCL: win > Locale: ru-RU (ru_RU); UI: ru-RU > Calc: CL threaded @Roman, perhaps you could test an updated (beta)?
When selecting a single cell, the new border is not drawn over the grid, as it used to be in LO 24.2. This looks weird to me, as it is drawn over the adjacent cells. I would have prefered the older way.
Created attachment 194883 [details] Screenshot of the current master build (In reply to Mihai Vasiliu from comment #14) > When selecting a single cell, the new border is not drawn over the grid, as > it used to be in LO 24.2. The active cell is drawn over the selection... this has always been that way, and the new patches do not change that order. See attached image showing how the overlays are rendered in the current master, built from source today. Notice that the Active Cell is drawn above the selection overlay. Maybe you're using an older build.
(In reply to Rafael Lima from comment #15) > Created attachment 194883 [details] > Screenshot of the current master build > > (In reply to Mihai Vasiliu from comment #14) > > When selecting a single cell, the new border is not drawn over the grid, as > > it used to be in LO 24.2. > > The active cell is drawn over the selection... this has always been that > way, and the new patches do not change that order. > > See attached image showing how the overlays are rendered in the current > master, built from source today. Notice that the Active Cell is drawn above > the selection overlay. > > Maybe you're using an older build. Sorry, maybe I was not clear enough. I am comparing the cell selection padding from 24.2 vs 24.8. See the screenshot for how the main selected cell blue border is exactly over the grid in 24.2. In 24.8 however, the blue border of the main selected cell has some padding, thus being drawn over the adjacent cells. I am saying that this looks weird and I prefer the old behaviour. Attachements added.
Created attachment 194885 [details] Cell selection with no padding in 24.2
Created attachment 194886 [details] Cell selection with padding in 24.8
(In reply to Mihai Vasiliu from comment #18) > Created attachment 194886 [details] > Cell selection with padding in 24.8 Your screenshot is not using the latest code... wait a few more days and your Calc will look the same as the screenshot I attached. However, notice that even in your screenshots, the Active Cell is above the Selection overlay.
(In reply to Mihai Vasiliu from comment #16) > In 24.8 however, the blue border of the main selected cell has some padding, > thus being drawn over the adjacent cells. > I am saying that this looks weird and I prefer the old behaviour. Indeed, this is because of the fix for bug 143733. @Heiko, do you think we should make this optional? Maybe an expert config?
(In reply to Rafael Lima from comment #20) IDK what was the exact decision on bug 143733 (fixed value or zoom-variable or whatever) nor the size of the distance/gap left between the cell grid line and the active cell marking line. I would (anyway) suggest (as an alternative compromise) that leaving a fixed-size 1 pixel distance outside the cell grid line would still serve the purpose of not blocking anything within the cell. There are other reasons to the recent changes in the active cell marking, so IDK whether this suggestion would still answer to all considerations.
Created attachment 194894 [details] Scrrenshot by LO current dev 25.2 I still dislike it =(
IIRC, the relation/contrast between border colors, background color, active cell selection color, dark themes... were also part of the considerations.
(In reply to Roman Kuznetsov from comment #22) For some reason, in my system I don't see the deviance. There is the new gap, but it is not easy to see anything asymmetrical regarding the distances around the cell grid lines. When selecting multiple cells, the asymmetry is not in the distance, but rather in the "selection" color, because the active cell has 3 sides with a (white) gap and 1 side filled with the "selection" color. Maybe the "selection" color should cover all 4 sides between the grid line and the active cell line when more than one cell is selected and the selection includes the active cell. Other selected ranges would/should not be affected (when non-adjacent ranges are selected too).
(In reply to ady from comment #24) > Maybe the "selection" color should cover all 4 sides between the grid line > and the active cell line when more than one cell is selected and the > selection includes the active cell. Other selected ranges would/should not > be affected (when non-adjacent ranges are selected too). To be clear, when the active cell has focus but no cell is selected, there is no "selection" color, so the current behavior seems symmetrical in my system.
*** Bug 161740 has been marked as a duplicate of this bug. ***
Created attachment 194910 [details] How LO 24.8 focus rectangle hides adjacent cell contents at 100% (MSO, LO 24.2, LO 24.8) Adding a comparative grid of screenshots and related comments from the related bug 161740: While the aesthetics of this focus rectangle are annoying, the more significant problem IMHO. Is cell content being hidden. If a wide rectangle is drawn on the inside, it will hide the cell's own contents; and if a wide rectangle is drawn on the outside (especially with the extra pixel(s) of clearance from the active cell edge) - it will hide other cells' contents, and possibly more than just one. That is really detrimental and frustrating, requiring artificial movement just to figure out what the cell actually contains. I believe that the width must be _limited_, and moreover, must be split between the inside and the outside of the cell, so that none of their contents is drawn over by the focus rectangle, nor touched at the adjacent pixel. That is to say - Excel gets it right. :-(
(In reply to Eyal Rozenberg from comment #27) > Created attachment 194910 [details] > 5 Screenshots exemplifying how LO 24.8 rectangle hides adjacent cell > contents; MSO, LO 24.2, LO 24.8 > > Adding a comparative grid of screenshots and related comments from the > related bug 161740: > > While the aesthetics of this focus rectangle are annoying, the more > significant problem IMHO. Is cell content being hidden. If a wide rectangle > is drawn on the inside, it will hide the cell's own contents; and if a wide > rectangle is drawn on the outside (especially with the extra pixel(s) of > clearance from the active cell edge) - it will hide other cells' contents, > and possibly more than just one. That is really detrimental and frustrating, > requiring artificial movement just to figure out what the cell actually > contains. > > I believe that the width must be _limited_, and moreover, must be split > between the inside and the outside of the cell, so that none of their > contents is drawn over by the focus rectangle, nor touched at the adjacent > pixel. That is to say - Excel gets it right. :-( Excellent collage of screenshots! I really agree that the way Excel displays the selection is the best. We should follow the same strategy in my opinion.
(In reply to Eyal Rozenberg from comment #27) > Created attachment 194910 [details] May I ask, what's the difference between attachment 194910 [details] and attachment 194909 [details]?
To be honest, the first time I used the new "wider active cell outline" I found it a bit weird at first, but quickly got used to it. It is not as bad as most people are claiming it to be. But that's just me... I do not oppose the change to the Excel style of displaying the active cell (as in attachment 194910 [details]). It should not be difficult to implement this in the code. However, this is more of a design decision, so I'd like to hear Heiko's thoughts on this as well. At first I thought of having a new option where the user could choose whether to use the new "wider outline" or the "traditional outline" (the latter could even be the Excel style outline). However, as discussed in the Telegram group, some people opposed the idea of having another option in LO. So, I'm divided here... All I can say is that I'll volunteer to implement whatever ends up being decided.
(In reply to Rafael Lima from comment #32) > I do not oppose the change to Whichever the change, please keep in mind all the points that have been already discussed before, such as contrast with background color, dark theme, contrast against borders' color (which is not the same as the grid line), not blocking contents of cells, other UI artifacts such as (tracing) arrows or comment/notes indicators, effects of zooming levels (IMO, the active cell layer should _not_ be proportional to zoom)... It is unfortunate (to say the least) that just one user asks something and a developer at some point decides to implement it without any deeper/wider thought about implications nor input from other users/developers, triggering dozens of additional reports and requests with all sorts of corrections and reverts, even to the point of having to discuss whether one report is a dupe of another or it is a different minor aspect about the same broader topic. To be clear, I'm not against changing the active cell marker line. I'm just saying, please consider prior discussions related to the topic.
(In reply to ady from comment #33) > It is unfortunate (to say the least) that just one user asks something and a > developer at some point decides to implement it without any deeper/wider > thought about implications nor input from other users/developers That is an important point, but I would like to stress that: * Most LO bugs, including important, fundamental and widespread ones, are just "one user asking for something". Sometimes they're asking for something which millions need, sometimes they're asking for something only they care about. * I also believe we lack sufficient evaluation/discussion of the implications of design decisions. I wonder if this one has even been on the agenda of a design meeting; or maybe it has, and I didn't notice it because its significance was not obvious from the agenda item phrasing? At any rate, even if one such meeting discusses them - it's still just 3-5 people typically in attendance, and not all of them have an opinion on everything... * And yet, a counterpoint is that our resources are limited in terms of time and people to engage in such UI/UX deep-dive reviews. The cushion for things which slip by devs/QA are the user running betas.
(In reply to Rafael Lima from comment #20) > @Heiko, do you think we should make this optional? Maybe an expert config? No, it's a design decision and either way you find users who don't like it.
Created attachment 194922 [details] Cell selecting in Excel 2019 I still can't understand why you made it. Excel 2019 looks good in this case
Created attachment 194923 [details] Cell selecting in Google Docs Ah, now I see where you find this solution. And it looks much better in GDocs now than we have in current LO Calc
This patch ensures that the cursor is always symmetrical with respect to its cell. https://gerrit.libreoffice.org/c/core/+/169546
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/81f2185c111b7d8154a2de128d490a0a9e822f19 tdf#161709 Make selection rectangle symmetric at any zoom level It will be available in 25.2.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.
This latest patch fixes the symmetry issue. The cherry-pick for the 24.8 branch is in Gerrit. TBH after using this wider outline for some time, I now find it quite normal to use.
Rafael Lima committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/027cbc70f446af91c982c98474027f36ec554e8a tdf#161709 Make selection rectangle symmetric at any zoom level It will be available in 24.8.0.2. 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.
Please, see the new situation in master. For me, with this new design I consider this bug fixed.
(In reply to Rafael Lima from comment #42) > Please, see the new situation in master. > > For me, with this new design I consider this bug fixed. It's not as bad as before, but I would say it's still a bug. There is no distance between the rectangle and the baseline of the cell above. And if there's text which goes below the baseline, then we're really screwed. For example, q and g look exactly the same - cut off at the baseline.
(In reply to Eyal Rozenberg from comment #43) > It's not as bad as before, but I would say it's still a bug. There is no > distance between the rectangle and the baseline of the cell above. And if > there's text which goes below the baseline, then we're really screwed. For > example, q and g look exactly the same - cut off at the baseline. Isn't that the case with any cell's border (which is not exactly the same as the cell's grid limit)? (BTW, I don't see a meaningful conflict with "q" or "g" ATM, so maybe a screenshot and full version information would help?) I admit I don't understand what the (new?) goal is (or should be?) within the current status of the active cell line/marker. Let's recap... The recent changes that were introduced to the active cell's line started as a request to move the line outside the cell's own grid, in order to make a clearer distinction between cell's borders and cell's active line marker, and to reduce the overlap between the latter and the cell's (own) content, while still marking the active cell prominently-enough (or even more prominently than before). This naturally extends not only to having the focus on some cell, but also to selecting a cell (and/or a range). If the active cell line marker exists (i.e. is shown), then it has to be "somewhere" on screen. Either it overlaps with the grid lines, or with cell's borders, or with some cell's content. Whichever the case, the combination of colors (and themes, and light/dark modes) is always a factor. Another factor are additional screen artifacts such as tracing arrows, comment indicator, auxiliary lines (e.g. hidden rows/columns), cell's tool-tips, etc. If the active line is conflicting with the content of _another_ (adjacent) cell, that situation is better than conflicting with the content of the active cell. 1. Another consideration for improvement is the width of the line itself. Since the active cell line is an auxiliary layer (similar to the grid limit, as oppose to actual cell's borders), then making the line itself narrower reduces the conflict against other on-screen artifacts. 2. The gap/distance between the active cell line and the grid could also be a consideration, but I am not sure about the results in practice. 3. There is always the potential to "play" with transparency, and/or background/foreground layers (where the active cell line should be on the "background" against cell's content/font). 4. The only way to avoid every-and-all possible conflict would be to hide the active cell line. For instance, in theory, you could have the recently-added "Column/Row Highlighting" option set to ON, while having no active cell line (and no "fill handle" either). Beware that the selection background color should not be hidden in this case. I do not know whether there is some (advance/experimental) setting for that.
(In reply to ady from comment #44) > Isn't that the case with any cell's border (which is not exactly the same as > the cell's grid limit)? (BTW, I don't see a meaningful conflict with "q" or > "g" ATM, so maybe a screenshot and full version information would help?) The LILILI example is already enough to illustrate the failing of this design. But I'll make one soon. > I admit I don't understand what the (new?) goal is (or should be?) within > the current status of the active cell line/marker. The current status of the active cell line/marker _is_ the problem. > Let's recap... > > The recent changes that were introduced to the active cell's line started as > a request to move the line outside the cell's own grid This major design change was made with little discussion and basically no solicitation of user feedback. Certainly without due consideration of its impact. Repeating my comment in bug 143733: The change should never have happened before a near-consensus or wide majority was reached about how the cell border should look and effect contents. > it has to be "somewhere" on screen. That's true, and there's a tradeoff involving: * Cell contents visibility when selected * Cell contents visibility when adjacent cell is selected * Cell padding width (for use when selecting) * Active Cell rectangle width * Strength of the Active Cell rectangle (e.g. transparency and such) Instead of settling what this tradeoff should be in a discussion process, we're seeing different points in the design space implemented. That wasn't the right way to handle this the first time (bug 143733) and IMNSHO isn't the right way to handle it now. No disrespect to Rafael's work of course. > If the active line is conflicting with the content of _another_ (adjacent) > cell, that situation is better than conflicting with the content of the > active cell. 1. On the contrary, I would say that messing with the contents of the _active_ cell is much better than messing with the content of _other_ cells. Why? If you've selected the cell, you're going to edit it. When you edit it, you change the contents anyway, and you get full visibility anyway while typing and in the formula display. But the cell, say, above is something you want to be very readable, for context. 2. That's a false dichotomy. We don't have to hide the contents of any cells. Just look at the Excel example in attachment 194910 [details]. Of course - it's a four-way tradeoff like I mentioned above For decades, we've preferred drawing the cell Active Cell rectangle on the inside. That was a decent choice. It can be renegotiated for sure, but the opposite choice is wrong and bad.
From a user's perspective (mine and some colleagues of mine), I personally prefer the Excel version from attachment 194910 [details] or at least the older LO 24.2 style. Both seem fine and we never had any visible issue with them, although we slightly prefer Excel's interpretation because the spacing is not so narrow as LO's and gives a better sensation. But of course this is only our subjective opinion and just something that hasn't bothered us. But we don't quite like the new look in LO 24.8, for the reasons described in the previous comments (with the overlapping of LILILILI content etc).
(In reply to Eyal Rozenberg from comment #45) > The LILILI example is already enough to illustrate the failing of this > design. But I'll make one soon. I am not saying that I am in favor of one layout or another. Referring to some image in this report can be misleading, while recent patches have modified the results. For example, as of 54294119b9a3c80d2cb5d37030117f38d3f7f538 (24.8) ...and/or as of: 553c128e3fdc4b9612c1150b30d7b89df2ae6fdd (25.2) ...I am seeing a different result than previously-attached screenshots. > This major design change was made with little discussion and basically no > solicitation of user feedback. Certainly without due consideration of its > impact. As usual; what's new? (That's not to say that any particular feedback would had been on-time and/or relevant.) At any rate, please always review the results (at least regarding the active cell line marker) with the very latest (24.8 or 25.2) Dev version in order to keep the discussion relevant.
(In reply to ady from comment #47) > As usual; what's new? Well, the difference is one of the most-used parts of the Calc UI, as opposed to some rarely-used dialog. So there's more push-back of "hey, why did they do this without asking?"
(In reply to Rafael Lima from comment #42) > For me, with this new design I consider this bug fixed. Me too. The OP's issue of with range selection is solved. Rafael, please change the state to FIXED. Reasonable follow-up issues should be reported in extra tickets.
(In reply to Heiko Tietze from comment #49) > (In reply to Rafael Lima from comment #42) > > For me, with this new design I consider this bug fixed. > Me too. The OP's issue of with range selection is solved. Rafael, please > change the state to FIXED. Reasonable follow-up issues should be reported in > extra tickets. While OP simply complained about how things "look ugly", this bug has become wider in scope that that. The title has already been changed to reflect that. Let us please not stick our head in the sand. The bug is not fixed.
(In reply to Heiko Tietze from comment #49) > Me too. The OP's issue of with range selection is solved. Rafael, please > change the state to FIXED. Reasonable follow-up issues should be reported in > extra tickets. Setting this to FIXED. Let's move follow-up issues to new tickets.
Rafael, You (and others) have decided to mark other tickets regarding the unacceptable and detrimental change to the active cell rectangle as duplicates of this one, accepting the expansion of this ticket's scope. And now, you've decided to close this ticket, supposedly because other issues should be handled in separate tickets. This, despite not getting agreement for the specific changes you made here, or for the notion that issues need to be handled separately. Playing "ticket whack-a-mole" like that is unacceptable.
(In reply to Eyal Rozenberg from comment #52) > Playing "ticket whack-a-mole" like that is unacceptable. Can you imagine how discouraging this tone might be for volunteers?
(In reply to Heiko Tietze from comment #53) > Can you imagine how discouraging this tone might be for volunteers? Well, I'm also a volunteer; but you're right, I forgot Rafael is not a "hardened veteran" and that him asking for your opinion is at the same time asking for your approval or guidance. So, I take back my laying of responsibility. I'm sorry, Rafael, I should actually be placing the responsibility, or the blame, on Heiko for this situation. Not just with the two bugs, but with pushing forward on the basis of the acceptability of 143733 rather than taking that back to the drawing board. Heiko, will you do the honors and reopen the bug?
(In reply to Eyal Rozenberg from comment #54) > Heiko, will you do the honors and reopen the bug? => comment 49 If you think the cell focus feature has room for improvements or if you dislike design aspects, please file a new ticket (or reopen one of the duplicates). So far all work has been done intentionally and iteratively with good reasons. Design choices and even some UX aspects may not be your first choice but are always done to solve problems of other users. Please keep this in mind.
(In reply to Heiko Tietze from comment #55) That is all backwards. You're assuming what's committed right now is the "status quo". It's not acceptable as such. What should happen is a backout of the patch for 143733 and the changes here. And then, if someone can establish consensus, or at least a wide majority, in support of a change - let that change be implemented. > If you think the cell focus feature has room for improvements or if you > dislike design aspects, please file a new ticket (or reopen one of the > duplicates). So far all work has been done intentionally and iteratively > with good reasons. The reasoning for the change in 143733 were faulty, but that is a mistake and/or a failure of process. The reasoning here is also faulty, but here everything is basically out in the open and still there is the strange insistence. > Design choices and even some UX aspects may not be your > first choice but are always done to solve problems of other users. Please > keep this in mind. I've read the original bug, and the change does not even properly resolve the problem the original reporter pointed out. They complained about "eating space from the information in focus" and suggested Excel's strategy. The new implementation (before and after the changes here) "eats space" from the information in other cells - essentially shifting the problem elsewhere. But even if he had been very happy with the change - others are quite unhappy with it; and the current state of affairs has objective deficiencies which the discussion in the original ticket did not even consider. In fact, our best indication is that fml2 would have repeated his original suggestion, of taking the Excel approach.
Created attachment 195452 [details] Active cell rectangle hides surrounding cell contents (nightly from 2024-07-19) Note the partial content hiding in the cells above and below the active cell, and the complete hiding in the two cells to the left and right.
Created attachment 195462 [details] screenshot bug 161709 LO 24.8.0.1.0+ Build ID ec62d4ec690b636293afa625f3519e7d7b101f1f (In reply to Eyal Rozenberg from comment #57) > Created attachment 195452 [details] The surrounding active cell line marker will overlap "something, somewhere". The result will also depend on the colors, type and size of fonts, cell alignment, border type and width, zoom level... I am attaching a similar screenshot, with a different result than attachment 195452 [details]. Again, this does not mean that I favor one layout or another.
(In reply to ady from comment #58) Come on, ady... your screenshot is at zoom 300% or so. If it wasn't clear enough - the occlusion/hiding complaints are about zoom level 100%. Of course such problems tend to worsen if we zoom out and to improve or disappear if we zoom in.
(In reply to Eyal Rozenberg from comment #59) > (In reply to ady from comment #58) > > Come on, ady... your screenshot is at zoom 300% or so. > > If it wasn't clear enough - the occlusion/hiding complaints are about zoom > level 100%. Of course such problems tend to worsen if we zoom out and to > improve or disappear if we zoom in. The point of attachment 195462 [details] is to show how I am seeing a different result. There are no "hidden intentions". For example, the overlap between the "qp" characters and the active cell line marker is not the same as in other screenshots in this report, and I have a similar impression when I zoom out (with relevant natural consequences of zooming out, of course). This shows how the font type, size, zoom level and many other factors have an influence on the result. I could also intentionally search for a combination of factors that would be particularly negative for the current layout. The active cell line is an _auxiliary_ layer, and this why I claim that there should be no direct proportion when zooming, the line should be partially transparent (but only against cell's content/font, and only on overlapping pixels) while having clear contrast against colors of other screen artifacts, its width should be rather thin (not fat, but still clearly seen), the gap should be the minimum possible in order to be distinguishable but no more than that... Similar conditions should go for comment indicators, tracing arrows, grid lines, spell-checking underline... These should be all _clearly_ seen (this was not always the case in the past), but should rather not block anything in the main layer. In contrast, fonts and real cell borders are examples of main layers. I have more than enough accessibility difficulties with the UI and my weak eyes (by LO/Calc limitations, in part imposed by LO developers' decisions). I have participated in several reports about these Calc limitations. So, unfortunately, I am forced to use varying zoom levels, depending on what exactly I am focusing on. Moreover, I also use the OS magnifier, in addition to Calc's zoom levels (for example for the crippled formula bar). So, yes, I am forced to use zoom, continuously. I would suggest that, if something (like the active cell line marker) conflicts with something else on screen, users could at least attempt to overcome the problem by using the zoom level. Sometimes it is enough, but I am very well aware that sometimes it is a painful UX. As I said, I am not saying I favor the new layout (nor the older one). Each one has pros and cons. If anyone thinks my attachment 195462 [details] has no use for this discussion, please, by all means, feel free to ignore it.
This change should have been reverted as was discussed in the original bug. All the fixes notwithstanding, it was a terrible idea from the very start and it's sad it was actually released.
(In reply to khagaroth from comment #61) Because of comments like this I will never touch the Calc UI again.
(In reply to Heiko Tietze from comment #62) > (In reply to khagaroth from comment #61) > Because of comments like this I will never touch the Calc UI again. Heiko, that comment is perfectly on spot, except perhaps for the use of the word "terrible", which could have been toned down. And regarding its angry tone: We can't release a highly-visible UI degradation, and not expect some user disgruntlement. I did try to channel that sentiment and raise this issue in one of the last design meetings before the release was finalized, but there was no willingness to reconsider the decision.
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/3b4a8406c2e7f4f6a7ac43e192fdb8ef266d4b6d tdf#161709 Remove extra space between cursor and cell edges It will be available in 25.2.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.
The See also bug 162624 requests a toggle implemented to allow users to restore a pre 24.8 cell border. Since Eyal reopened this BZ NEW guess question of providing a toggle can drag on here.
(In reply to V Stuart Foote from comment #65) > The See also bug 162624 requests a toggle implemented to allow users to > restore a pre 24.8 cell border. Since Eyal reopened this BZ NEW guess > question of providing a toggle can drag on here. The extra space has been removed in master. Let's wait for the patch to be cherry-picked for the 24.8 branch.
(In reply to V Stuart Foote from comment #65) > The See also bug 162624 requests a toggle implemented to allow users to > restore a pre 24.8 cell border. Since Eyal reopened this BZ NEW guess > question of providing a toggle can drag on here. Everything evolves, LO included. This does not mean we should abandon features without a 100% audience. It does mean we should enable evolution as a selectable frame. It also does not mean a single UI value is the same as a Cambrian explosion. We should have a single UI value related to a frame, adapt features in that frame and let the users decide which frame to use.
*** Bug 162624 has been marked as a duplicate of this bug. ***
Created attachment 196009 [details] revised spacing of active cell overlay, wef. 20240825 master against 25.2.0 Showing overlay spacing is back onto cell border with latest patch, looks to match MSO and Google Docs.
(In reply to Rafael Lima from comment #66) > The extra space has been removed in master. While I am personally ok with the final result (Excel-like active cell rectangle dimensions and width) - it would still have been more appropriate to at least sound out the intended change ("So, everyone, can we settle this if I commit a change which does XYZ?", wait a while, act if no significant opposition). Less critical, I suppose, when we're not right before a release. Anyway, I do want to thank you for making the extra effort of working on this, despite facing (my and other people's) criticism. > (In reply to V Stuart Foote from comment #65) > > The See also bug 162624 requests a toggle implemented to allow users to > > restore a pre 24.8 cell border. Since Eyal reopened this BZ NEW guess > > question of providing a toggle can drag on here. So, @louserdt24 and others - what do you all think? Is the Excel-like rectangle good enough? To be the single-and-only style of the active cell rectangle?
OK, https://gerrit.libreoffice.org/c/core/+/172266 needs backport to 24.8.x with some thought of untangling the related overlay for Autofill contrast outline, https://gerrit.libreoffice.org/c/core/+/170354 @Heiko, getting burnt like this I can understand if you don't want to touch Calc, but you have my full confidence in any case -- Stuart
(In reply to Eyal Rozenberg from comment #70) > So, @louserdt24 and others - what do you all think? Is the Excel-like > rectangle good enough? To be the single-and-only style of the active cell > rectangle? If it's like in 24.2 then yes, as this would match MS-Excel.
(In reply to louserdt24 from comment #72) > If it's like in 24.2 then yes, as this would match MS-Excel. It's not like in 24.2 - which does not match MS-Excel. Excel has a thinner rectangle than LO 24.2 Please have a look at attachment 194910 [details] for examples. The MS-Excel one is very similar to what we have now.
(In reply to Eyal Rozenberg from comment #73) > (In reply to louserdt24 from comment #72) > > If it's like in 24.2 then yes, as this would match MS-Excel. > > It's not like in 24.2 - which does not match MS-Excel. Excel has a thinner > rectangle than LO 24.2 > > Please have a look at attachment 194910 [details] for examples. The MS-Excel > one is very similar to what we have now. Ah yes, sorry missed the attachment example, looks good, if the difference is more then 1 pixel reducing it to only 1 pixel wider (than excel) would be better.
In the current release 24.8.0.3, it’s more difficult to get the mouse + sign at the bottom right of a cell when you want to draw the content of this cell in one direction to fill the adjacent cells; the embedded cell edge and selected cell rectangles confuse it.
I tested the latest master implementation, it looks exactly how I always wanted it. This Excel-style is the best in my opinion. The line is non-intrusive for neither the current cell or the adjacent cells. Also it looks the most pleasant, by using the already existing grid lines as reference. It's a pitty this decision wasn't discussed properly in a meeting and led to people being allegedly offended here in the comments. I hope this will be ported to 24.8 for the next update and that will please everyone.
(In reply to maison from comment #75) > more difficult to get the mouse + sign at the bottom right of a cell Are you sure about that? I think the drag-handle square has the same size as in LO 2024.2.
(In reply to V Stuart Foote from comment #71) > OK, https://gerrit.libreoffice.org/c/core/+/172266 needs backport to 24.8.x > with some thought of untangling the related overlay for Autofill contrast > outline, https://gerrit.libreoffice.org/c/core/+/170354 Indeed... this is why I haven't backported it yet. I'll speak with Xisco on how to proceed here (I'll CC him on the patch and question him).
Also, I'm setting this to FIXED, as it's only awaiting the backport.
Follow-up: macOS cell highlighting is off balance: https://bugs.documentfoundation.org/show_bug.cgi?id=162646
Rafael Lima committed a patch related to this issue. It has been pushed to "libreoffice-24-8": https://git.libreoffice.org/core/commit/6766aae5d0d615445eda55077c0e94514b4c25d4 tdf#161709 Remove extra space between cursor and cell edges It will be available in 24.8.2. 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.
Rafael Lima committed a patch related to this issue. It has been pushed to "libreoffice-24-8-1": https://git.libreoffice.org/core/commit/98e92c15855d2faf3021c0e3b3987997f49b9b85 tdf#161709 Remove extra space between cursor and cell edges It will be available in 24.8.1. 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.