Created attachment 194305 [details] ODG file explaining the issues Calc now has a new cell outline for the selected cell, whereby the outline is drawn a bit more distance from the actual cell. This is certainly an improvement and gives a more modern feel to Calc, but it still has 2 issues: 1) The square used for dragging is not drawn correctly, and if the zoom is above 220% it gets disconnected from the cell outline, giving a weird impression of a bug 2) The distance between the cell outline and the cell should not be proportional to the zoom level. When the zoom level is too high, the distance between the outline and the cell becomes too much. We should use an absolute distance, similar to the one when the zoom is 100% See attached ODG files with more detailed explanation on the issues. Tested with Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: 1bd9747a126a3e82b6093c2b4af3b3a74774a3e9 CPU threads: 16; OS: Linux 6.8; UI render: default; VCL: kf5 (cairo+xcb) Locale: pt-BR (pt_BR.UTF-8); UI: en-US Calc: CL threaded
(In reply to Rafael Lima from comment #0) > 1) The square used for dragging is not drawn correctly, and if the zoom is > above 220% it gets disconnected from the cell outline, giving a weird > impression of a bug I had a observed the same and wanted to report the issue. > 2) The distance between the cell outline and the cell should not be > proportional to the zoom level. When the zoom level is too high, the > distance between the outline and the cell becomes too much. We should use an > absolute distance, similar to the one when the zoom is 100% Wouldn't this be an issue at lower zoom levels? Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: ae798781ef4df7a1fdef13af0bc459bf4f6e7b4c CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded
Reproducible with Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: eb3ae3234e098e1ee605624b0cac4c90436628d0 CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: threaded
(In reply to Stéphane Guillou (stragu) from comment #1) > Wouldn't this be an issue at lower zoom levels? I don't think this would be an issue... I tested it in 30% zoom and it looks fine, because the distance at 100% is not a lot. There's also the issue with the line width, because it increases and decreases with zoom. Maybe this should also be a fixed value (as Google Sheets does). Also, at some zoom levels (such as 95%) the distance at the bottom and right sides are larger than the distances at the top and left sides.
(In reply to Stéphane Guillou (stragu) from comment #1) > (In reply to Rafael Lima from comment #0) > > 1) The square used for dragging is not drawn correctly, and if the zoom is > > above 220% it gets disconnected from the cell outline, giving a weird > > impression of a bug > I had a observed the same and wanted to report the issue. I don't understand what is described here as "not drawn correctly". IIUC, there is some (not-fixed, proportional?) distance between the squared fill handle and the "active-cell line", in whichever zoom factor. Other than that, what exactly is "different and wrong" when zooming-in and dragging the fill handle? At which exact detail should we be looking (in comparison to 100% zoom, or in comparison to older versions)? > > > 2) The distance between the cell outline and the cell should not be > > proportional to the zoom level. When the zoom level is too high, the > > distance between the outline and the cell becomes too much. We should use an > > absolute distance, similar to the one when the zoom is 100% > Wouldn't this be an issue at lower zoom levels? If there is an issue at lower zoom levels (or at high screen resolutions?), maybe there should be both lower and upper limits / thresholds – the distance (between the cell limits and the "active-cell line") should not be shorter than ‘x’ value nor larger than ‘y’ value, and the distance would vary in between those 2 limits according to zoom or screen resolution.
(In reply to ady from comment #4) > I don't understand what is described here as "not drawn correctly". I was referring to the square not following the rectangle and eventually getting disconnected at higher zoom levels. Not sure if some additional thing was meant by Rafael's "not drawn correctly".
I don't see an absolute value as a solution; a slightly smaller multiplicator might be okay. Feel free to hack it. ScGridWindow::UpdateCursorOverlay() in sc/source/ui/view/gridwin.cxx, see https://gerrit.libreoffice.org/c/core/+/166870.
(In reply to Heiko Tietze from comment #6) > I don't see an absolute value as a solution Please forgive my ignorance. If I may ask, why? What's the reasoning? I think of the active-cell line marker in a similar way as other auxiliary UI elements: * auxiliary lines such as active-cell border line mark, selected-cells background color, trace-dependent and trace-precedent lines and arrows, the fill handle, comment indicator... are all examples of a secondary auxiliary layer; * cell contents, cell results, graphs, and even cell borders applied by the user, are part of one main layer. So, again, please forgive my ignorance... I don't see the reason to make the auxiliary artifacts directly proportional to the zoom factor exactly the same as cells, graphs and other main items. I can understand the possible need to tweak the auxiliary layer when it is not displayed adequately under some conditions (color contrast, screen resolution, zoom factor, dark theme...), but growing/shrinking these auxiliary items proportionally to zoom factor would seem to me (and to my workflow) a negative point. OTOH, I'm just a common user that might not understand enough about UX.
(In reply to Stéphane Guillou (stragu) from comment #5) > I was referring to the square not following the rectangle and eventually > getting disconnected at higher zoom levels. So it is also about the distance for you. Maybe there should be a distance between the cell's limit and the (now outer) active-cell line marker, but a different (smaller) distance between the latter and the fill handle (?).
(In reply to Heiko Tietze from comment #6) > I don't see an absolute value as a solution; a slightly smaller > multiplicator might be okay. Feel free to hack it. Thanks for the pointer... I'll try to come up with an alternative design and CC you on the patch.
(In reply to ady from comment #7) > (In reply to Heiko Tietze from comment #6) > > I don't see an absolute value as a solution > If I may ask, why? 1px is 10% of the total cell height at 25% but 0.01 at 600%. To make the frame clearly outstanding from the cell content you need to adjust the distance according the zoom factor. Of course we can abstain from this look and feel and just make it start outside the cell with zero distance.
(In reply to Heiko Tietze from comment #10) > 1px is 10% of the total cell height at 25% but 0.01 at 600%. To make the > frame clearly outstanding from the cell content you need to adjust the > distance according the zoom factor. Of course we can abstain from this look > and feel and just make it start outside the cell with zero distance. Let me put an example of the difference that I am trying to convey. If a user sets borders to a cell, those borders are chosen by the user and I see this as part of a main layer, not an auxiliary layer. Cell borders might be considered of lesser importance than cell contents, or formulas, but they are still part of user's choice, and they have a specified width (among other properties). OTOH, cell's limits are surrounded by gridlines, which are usually displayed – gridlines could be hidden by user's choice, but that's not the point here. The gridlines are an auxiliary artifact (therefore, they are never on top of cell borders added by the user), and users don't need to see their width in a proportional ratio in relation to the cell's size (width/height). As long as the gridlines mark the cell's limits without interfering with real work, they fulfill their role. Making the gridlines grow in the same proportion as the cells when zooming-in would be counterproductive. I see the active-cell surrounding line in a similar way as gridlines. As long as the active-cell line is clearly seen, without blocking other more-relevant items (cell content, cell border, comment indicator...), it does not need to have more/less (now outer) distance in relation to the cell's limit, whichever the zoom factor. The outer distance could be maintained. When zooming-in, I don't need to see the active-cell line more clearly than with another zoom, as I am focusing on some main item, not on auxiliary ones. This is just the way I see this matter, as a user. Experts could of course have a deeper and broader understanding of these things. BTW, zoom factors in Calc go as far as 400%, not more than that.
WIP patch here: https://gerrit.libreoffice.org/c/core/+/167945
(In reply to Rafael Lima from comment #12) > WIP patch here: LGTM
Rafael Lima committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/a764f661e0e1b94af128cc2290ee6510adad5ffd tdf#161234 New design for the cell outline 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.
Thanks Rafael, I see the disjointed square issue fixed in: Version: 24.8.0.0.alpha1+ (X86_64) / LibreOffice Community Build ID: a2b00082114b443962715a671b8bbb17733d6453 CPU threads: 8; OS: Linux 6.5; UI render: default; VCL: gtk3 Locale: en-AU (en_AU.UTF-8); UI: en-US Calc: CL threaded