Created attachment 175675 [details]
selected cell color - contrast too low

Created attachment 175676 [details]
Firefox - LO blue default highlight color comparison

Clearly NAB. Selection color comes from system theme and whether darker or lighter depend on many aspects. Plus, Apple Numbers draw the rectangle in addition to the cell frame and FF uses two frames. You may ask to draw the lines bolder but I'd disagree too as it looks ugly on some other OSes. For example Ubuntu with the orange highlight is quite nice with the current solution and would be overly bold if made more obtrusive.

If NAB means NOTABUG I disagree. Poor visibility of important UI elements clearly is a problem.

Sidenote: the light highlight colors work great with Application Colors > LibreOfficeDev Dark but for light mode (default) they should be adjusted.

I agree with Steve that there isn't enough contrast as displayed when using the light highlight color. But personally, I would rather it stay black (when in light mode), as it is in 7.2. I don't see a benefit for it following the O/S highlight color. Perhaps this should be a user-configurable option?

To make my point clear: I disagree to deviate from system theme colors. Certainly we should care about good contrast, which could be done by bolder border lines (bug 143733; abandoned patch at https://gerrit.libreoffice.org/c/core/+/121491), a different position, and bigger decorations (the grip rectangle is very small, maybe due to the high resolution). And personally I'm all in for user customization but got some pushback for my initial proposal.

My take here: duplicate of 143733.

(In reply to Heiko Tietze from comment #7)

> Certainly we should care about good contrast, which could be done by bolder
> border lines (bug 143733; abandoned patch at
> https://gerrit.libreoffice.org/c/core/+/121491), a different position, and
> bigger decorations (the grip rectangle is very small, maybe due to the high
> resolution). 

All that would certainly help. Maybe once that is implemented it's good enough, but without seeing it I can't say. 

> And personally I'm all in for user customization but got some
> pushback for my initial proposal.

I'm not sure what pushback you received to this, as I don't see it in either Bug 143733 or Bug 142959. Anyway, I agree with Timur in https://bugs.documentfoundation.org/show_bug.cgi?id=142959#c11 that we should just add another option to Application Colors->Spreadsheet and have it default to the system highlight color. Seems like that would resolve all conflicts on this.

@Heiko: how is this bug here a duplicate of #143733, which is about making the border wider for better visibility, while this bug here is about using colors that provide good contrast?

Both bugs are about the current border lacking visibility however the solutions differ and are certainly not a duplicate of each other.

And re: deviating from system colors - it certainly makes sense to not deviate. But I fail to understand how the current very light blue used in LibreOffice should be or match the macOS blue system accent color. Attaching a screenshot of the system color selection and the blue shown there is completely unrelated to the blue used in LibreOffice. The macOS accent colors would solve the contrast issue with the current color choices from LibreOffice. Where is LibreOffice getting the color values from?

Could you link the push back you are referring to?

Created attachment 177239 [details]
macOS system accent colours

(In reply to steve from comment #9)
> @Heiko: how is this bug here a duplicate...

You state an issue with a ticket not request a special solution.

I have the same problem and confirm it for macOS

Created attachment 177632 [details]
LO 2022-01-18 w patch from #143733

Attached new screenshot: LO 2022-01-18 w patch from #143733:
https://bugs.documentfoundation.org/show_bug.cgi?id=143733#c5

re-read https://developer.apple.com/design/human-interface-guidelines/macos/visual-design/color/ `system colors` section: Apple specifically recommends not to hardcode colors.

What seems to happen is that with systemBlueColor selected as system highlight color in System Preferences on macOS, LO uses systemCyanColor for cell highlighting.

As per https://bugs.documentfoundation.org/show_bug.cgi?id=146996 raising target may resolve the problem with system accent color in cell selection.

The plan is to raise target for LO 7.5 to macOS 10.14, which would happen July 2022 and be released Feb 2023.

We use selectedTextBackgroundColor, which is not hard-coded. You can change it as Accent Color in your preferences. And raising the target will not automatically improve anything.

Talked to Heiko and this is the summary:

macOS uses
- Accent colour (defaults to blue)
- Highlight colour (defaults to light blue)

This makes sense as highlight color is used when highlighting e.g. text. In the end this (again) is about good contrast. Marking black text with blue results in less contrast than marking black text with light blue.

LO currently uses macOS 10.13 as target. macOS 10.13 has no understanding of accent color. So when build target will be raised to macOS 10.14 it will be possible to utilize Accent color.

What would solve the problem this bug is about (not enough contrast in cell selection color) would be if LibreOffice used Accent Colour as cell selection color. Currently it uses Highlight colour resulting in the bad contrast especially in light (default) color scheme.

So the plan is to wait for raising the build target to macOS 10.14 (July 2022), revisit then and ideally this problem will be solved after cell selection color is changed to use Accent color.

Created attachment 178014 [details]
How excel draws the border

Here, as a reference, an image (see Attachment #178014 [details]) that shows how Excel draws the border and ensures that it is well visible in every color situation. The attachment image should be zoomed in to ses the details well.

My understanding of how Excel draws the border:

1. Draw the border around the cell with the stanard border color.

2. Draw the "inner border" with the standard background color (it's only visible if the cell's background color is changed). This ensures that the cursor is visible even if the cell background color is set to the color of the standard border.

3. Draw the drag handle in the standard color.

4. On the left and top of the drag handle, draw lines in the standard background color. This ensures that the handle is visible even if the cell background color is set to the color of the standard border.

*** Bug 147500 has been marked as a duplicate of this bug. ***

(In reply to steve from comment #18)
> macOS uses
> - Accent colour (defaults to blue)
> - Highlight colour (defaults to light blue)
> 
> ...
> 
> LO currently uses macOS 10.13 as target. macOS 10.13 has no understanding of
> accent color. So when build target will be raised to macOS 10.14 it will be
> possible to utilize Accent color.

I see this code in electron [1] (MIT license) Objective C++ file:

std::string SystemPreferences::GetAccentColor() {
  NSColor* sysColor = nil;
  if (@available(macOS 10.14, *))
    sysColor = [NSColor controlAccentColor];

  return ToRGBAHex(skia::NSSystemColorToSkColor(sysColor),
                   false /* include_hash */);
}

I see a discussion about run-time API availability check [2], mentioning that it is introduced in XCode 9 (our baseline is 12.5 [3]).

This is the related documentation from Apple [4], [5].

It *seems* to me that we have everything required to make it work on systems that support the accent color, without bumping requirements (which should happen ~soon anyway, IIUC).

[1] https://github.com/electron/electron/blob/bd10b19b0cdc46cdbadb570af89305e64541b679/shell/browser/api/electron_api_system_preferences_mac.mm#L374
[2] https://stackoverflow.com/questions/34013293/why-does-objective-c-not-have-api-availability-checking
[3] https://opengrok.libreoffice.org/xref/core/README.md?r=3469f697#42
[4] https://developer.apple.com/documentation/swift/objective-c_and_c_code_customization/marking_api_availability_in_objective-c
[5] https://developer.apple.com/documentation/appkit/nscolor/3000782-controlaccentcolor

(In reply to Mike Kaganski from comment #22)

Se also c18 for a summary. In a nutshell: our current target for macOS 10.13 is not pointing to the correct accent color. Could imagine a conditional switch for macOS (easy hackable) until the target will be 10.14.

*** Bug 150126 has been marked as a duplicate of this bug. ***

The problem still persists specially in MacOS 12.x and raised with version 7.3 of LO. Using the default selection color of the OS, the cell selection border is nearly invisible. Changing the gridline color in LO doesn't help, as the cellselection color is so massive dimmed, that it is nearly invisible. Changing the selection color in the MacOS system settings to a darker one is a workaround, but as this affects the text selection color in all other applications too, this is very unpleasant. It would be much better when the cell selection color could be set inside LO.

https://bugs.documentfoundation.org/show_bug.cgi?id=145080#c18 mentions that target would be raised to macOS 10.14 Mojave in July 2022. It is now end of september so polite ping as to the state of rasing macOS target, which is a requirement to address this contrast issue using accent color instead of highlight color for cell selection in calc.

(In reply to Kollien from comment #26)
> The problem still persists specially in MacOS 12.x and raised with version
> 7.3 of LO.

Please don't change the "version" field to a more recent one: it is used for the "earliest version affected as far as we know", which helps us pinpoint what created the issue in the first place.

FYI LO 7.5 has raised macOS target to 10.14.

(In reply to steve from comment #27)
> https://bugs.documentfoundation.org/show_bug.cgi?id=145080#c18 mentions that
> target would be raised to macOS 10.14 Mojave in July 2022. It is now end of
> september so polite ping as to the state of rasing macOS target, which is a
> requirement to address this contrast issue using accent color instead of
> highlight color for cell selection in calc.

Yes, it was raised: https://git.libreoffice.org/core/commit/0c96561a567fd7dbb394a1a44479a42aa149bcc7

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/258686a58f909ab04c7281c05f15882eb400748e

Resolves tdf#145080 - Use accent color for focused cell

It will be available in 7.6.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 focused cell is now colored according the accent color on macOS. Which is a darker blue in case of automatic but you can set any color in the system options. 

Accent colors are not (yet) available on Gnome and Qt (KDE enhanced the color palette) and I also didn't look into details Windows as it is more tricky. Could be a future enhancement.

(In reply to Heiko Tietze from comment #32)
> The focused cell is now colored according the accent color on macOS. Which
> is a darker blue in case of automatic but you can set any color in the
> system options. 

Will be interesting to see what happens with some of the options, seeing it has been an issue in other parts of the UI: bug 154624

Did you test with Graphite?

(In reply to Stéphane Guillou (stragu) from comment #33)
> Will be interesting to see what happens with some of the options...

The patch added the Accent color to our set using the highlight color for any OS but macOS. And the accent color is used only for the focused cell + row/col header in Calc. Works with the standard configuration, haven't tested anything else.

Another hallelujah improvement for LO on macOS 🙏

Finally cell selection visibility has improved *a lot* for both dark and light mode - even when using graphite as highlight color, which I do not recommend.

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: f3aab159f1c1e00c25e6b4ca1e50813bc343f4f3
CPU threads: 8; OS: Mac OS X 13.4; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded

Created attachment 187506 [details]
2023-05-25 accent color respected dark

Created attachment 187507 [details]
2023-05-25 accent color respected light

Addendum: One could argue, that using accent color for row + column highlighting is a bit too aggressive / too much.

Would using Highlight color for that instead work? Apple Numbers uses that solution to keep the overall UI less busy and focused.

(In reply to steve from comment #38)
> Would using Highlight color for that instead work? Apple Numbers uses that
> solution to keep the overall UI less busy and focused.

Apple Numbers uses an own color set, at least for me, and the focused cell has a green frame. But anyway, less aggressive col/row header makes sense. Have you filed a ticket?

Heiko Tietze committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/306093f8f82a646a2a82ebfc57fbef70af2d30a7

Related tdf#145080 - Less obtrusive col/row header color on macOS

It will be available in 7.6.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.

Created attachment 187553 [details]
2023-05-28 dark with fixed col row color

Created attachment 187554 [details]
2023-05-28 light with fixed col row color

Was busy the past days and had not filed a bug.
@heiko: thanks a lot for addressing the col row colors to something less aggressive. Verified and think the solution you found works great.

Version: 7.6.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 20873f073ae4a9478f0a84355f779a2176bd2ec8
CPU threads: 8; OS: Mac OS X 13.4; UI render: Skia/Metal; VCL: osx
Locale: en-US (en_DE.UTF-8); UI: en-US
Calc: threaded