Calc-active cell indicator is outside the cell framework 24.2.3.2 -> 24.8.0.3

See these 2 screenshots and the active cell marking between versions, how do I get this back from 24.2?

How it was (and how I would like it) on the left and on the right with 24.8

I have searched and tried several ‘solutions’, ea. I can change the color but not the overflow in to neighboring cells (which is annoying as it partially hides their values)

According to the release notes it is a deliberate change as a result of an enhancement request tdf#143733.

1 Like

Tnx. It overflows (hindering view) in to neighboring cell values, any idea how to disable this?

Let me emphasize why this is a bad idea,
Untitled
With numbers the 4 is questionable.
With letters the f is totally unclear, the i is questionable.
Being forced to move the active cell focus in order to see/verify values is a bad idea on top of a bad implementation.

How office2019 does it at the top:
How an earlier LO does it at the bottom:
Untitled

I would welcome a compromise between the view in 24.2 and the current view in 24.8 !
edit: yes looks fine in office2019

I’ve reverted back to 24.2, how do we/I get this issue to the developers to at least implement an on/off toggle?

Feature requests

Done, 162624 – Calc-active cell indicator is outside the cell framework 24.2.3.2 -> 24.8.0.3

Noting this comment in tdf#161709:

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.

Let me answer it here, to avoid an unrelated discussion in the bug tracker.

We actively do not want LibreOffice to be infinitely configurable. Yes, every single new toggle is a Cambrian explosion. Because every such new toggle doubles the space of possible configurations, and so doubles the load on the community to test it, and maintain it. A small and innocent toggle like discussed there would mean, among other things, that any change related to the Calc UI would require testing not only one new toggle in a default configuration and a default view mode, but e.g.:

  • how does this toggle work with dark mode;
  • how does this toggle work with high contrast mode;
  • how does this toggle work with Windows, GTK, KDE, qt, gen, macOS integrations;
  • how does this toggle work with Page Break view mode in all abovementioned setups;
  • how does this mode work without headers shown - in all abovementioned setups;
  • how does this mode work with frozen rows/columns - again, in all abovementioned setups;
    … and so on, each next bullet meaning we need to test this bullet against every abovementioned bullet.

This means, in our already existing multitude of settings, that every innocent two-state toggle means literally hundreds of new tests, that ideally should be done to maintain the feature, not to say what a configuration with multiple states would incur. We do want changes that make the overall state better for most, and do not require new configurations.

Indeed, this is not possible to only stay within the existing configurations. We do introduce changes requiring configurations, where necessary. But every such increase must be very well thought; and this change is not one of them - we just need to polish existing state to the point where it pleases more users than before, not a new configuration.

There had been some push-back against this change before the release of 24.8, and a demand that it at least not be included in the release (and in fact backed out). See the heated discussion in tdf#161709.

Current state of affairs: The rectangle was changed to be similar to MSO Excel’s and GDocs’.

@louserdt24 Note that feedback has been sought in tdf#161709 - you may wish to participate further.

Taken from BT.
(In reply to Eyal Rozenberg from comment #70)

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.

I’m not blaming or pointing fingers but that is what QC (Quality Control) is for as a process, a change like this rolled in 24.8 would never have passed QC as it not only hinders users (entry users, accountants, etc.) but even more visually impaired users.

… only if it agreed with you as a whole. Which was obviously not the case (as Eyal mentioned there in the bug). And of course, your expectation overall is wrong, with LibreOffice development intentionally involving users (the brave souls ready to test the for early adopters versions X.Y.0) into the final polishing, which you participate here in (thank you), and which shouldn’t be accompanied with finger-pointing of any kind. Basically, you are the (part of) QA (quality assurance)/QC of the project.