LibreOffice's icons need to have a transparent background instead of white background so to blend with Windows on Dark Mode instead of showing a white square behind it on certain user interface elements, as is the case when trying to "Open With" a file with LibreOffice (picture attached).
Steps to Reproduce:
1. Configure Dark Mode on Windows 10 (go to Settings app, search for "dark", choose default application mode as "dark").
2. Open File Explorer, go to a folder where there are any of Microsoft Office file types (.doc/.docx, .ppt/.pptx, .xls/.xlsx).
3. Open the shortcut/pop up menu on the file (mouse's right button), go to the "Open With" sub-menu.
LibreOffice's icon has a white square behind it.
LibreOffice's icon should have a transparent background so to not show the white square when running Windows on Dark Mode.
User Profile Reset: No
Please see the attached picture to see clearly what is happening.
Created attachment 148068 [details]
"Open With" menu showing one of LibreOffice's icons with a squared white background on Windows on Dark Mode
Kind of torn or this. But for Windows builds it *is* premature pending MS publication of needed C++ API for handling themeing for Windows dark mode as in bug 118320
Otherwise, confirm the project's Branding with Tango styling of the ODF MIME types  that OS/DE pick up do not have a transparent background. The white background is not pleasant when OS with a dark themed DE associates our branding icons with ODF MIME file types. Or if used for the LibreOffice module launchers.
Two ways to represent the ODF MIME types.
1) color icon background dynamically in response to theme.
2) create a light, a dark, and multiple high contrast sets of icons
When put into use, these would effectively replace the Tango themed MIME type branding--so result would have to remain suitable for Marketing/Branding needs.
The icons shown in Windows Explorer are just plain ICON resources , either in form of stand-alone .ICO files, or embedded into PE binaries. They have all capabilities required for correct transparency, and are not theme-dependent. So I disagree with broadening of the initial proposal; keeping things simple helps to do the right things step-by-step.
(In reply to Mike Kaganski from comment #3)
> ... are not
> theme-dependent. So I disagree with broadening of the initial proposal;
> keeping things simple helps to do the right things step-by-step.
Sure, but current set of Tango theme MIME icons all have a solid gradient background color--grey shading on white. While the HC icons have a solid black background.
So the existing Tango design does not lend itself to simply setting a color transparent--the icons would just look wrong.
Meaning redesign, adopting an icon theme that looks presentable with a transparent bg (and probably dynamic fg color)--or a more ambitious bg/fg response to DE theme--is still going to be needed.
Created attachment 148070 [details]
Screenshot with transparency visible in main Explorer window, and absent in menu
I'm afraid that there's a misconception here. While it might be a need for some design changes, this request clearly has nothing to do with that; and the design-related tasks need an own issue.
This issue is about the Windows icons that are mostly placed at sysui/desktop/icons; and they have .ICO format. They *already do contain transparent background*, and the background is OK when Explorer shows the icons in the main window (see screenshot's right marked icon). But when an "Open With" menu is used, the icon transparency is somehow ignored.
This might well be a Windows bug, where our advanced icon format (32-bit with alpha) is converted to, say, 16-colors with mask... or something like that. This is clearly a technical issue, that might have a technical solution (like adding some dedicated icon formats to the resource), and is orthogonal to the design considerations.
(In reply to V Stuart Foote from comment #4)
> (In reply to Mike Kaganski from comment #3)
> > ... are not
> > theme-dependent. So I disagree with broadening of the initial proposal;
> > keeping things simple helps to do the right things step-by-step.
> Sure, but current set of Tango theme MIME icons all have a solid gradient
> background color--grey shading on white. While the HC icons have a solid
> black background.
> So the existing Tango design does not lend itself to simply setting a color
> transparent--the icons would just look wrong.
> Meaning redesign, adopting an icon theme that looks presentable with a
> transparent bg (and probably dynamic fg color)--or a more ambitious bg/fg
> response to DE theme--is still going to be needed.
I created four screenshots to show there is no need to do a redesign, only to add transparent background on all icons embedded at "%ProgramFiles%\LibreOffice\program\soffice.bin" (the file that is referenced at "DefaultIcon" subkeys on every HKLM\Software\Classes\LibreOffice.<file extension>).
* When showing a shorcut file icon, Windows gets its' icon path from the .lnk file itself. In the case of LibreOffice's Start Menu program folder, the icons come from soffice.exe/sbase.exe/scalc.exe/sdraw.exe/simpress.exe/smath.exe/swriter.exe. Those icons have transparent background and so they appear correctly on Light Mode and Dark Mode, i.e., without black or white background square because transparent means the color behind the icon, as two of the attached pictures shows.
* When showing the Start Menu LibreOffice icons, Windows gets its' icons the same way on the earlier paragraph. As those icons have transparent background, doesn't matter the color the Start Menu is, Windows never shows a white background behind them, and so the Start Menu accent color is shown behind those icons.
* When showing the Open With shortcut menu, Windows gets its' icon path from the Registry key at HKLM\Software\Classes\LibreOffice.<file extension>\DefaultIcon, which is "%ProgramFiles%\LibreOffice\program\soffice.bin,<icon identifier>", because either HKLM\Software\Classes\<file extension>\(Default), HKLM\Software\Classes\<file extension>\OpenWithList subkeys or HKLM\Software\Classes\<file extension>\OpenWithProgIDs\(Default) points to it. In this case, those icons doesn't have transparent backgrounds, but white backgrounds, and so Windows paints the white background as a white square behind the icon.
Created attachment 148075 [details]
LibreOffice's Start Menu Programs folder on light mode, to show the icons there have transparent background
Created attachment 148076 [details]
LibreOffice's Start Menu Programs folder on dark mode, to show the icons there have transparent background
Created attachment 148077 [details]
LibreOffice's Start Menu listing, to show the icons there have transparent background and so Windows paints the accent color behind them, to show their transparent background
Created attachment 148078 [details]
Example of files from where Windows gets the icons, to show it's from soffice.exe and from soffice.bin
... and now try changing the registry entries to point to soffice.exe,0 or swriter,0 - and see that they will still have white background. The soffice.bin's icons are the same icons that are included into .exe files; they do have the transparent background. The problem seems to be that Windows handles *the same* icons differently when showing the in different scenarios.
Or alternatively, you can change a shortcut's icon to come from .bin and see them.
Think we all agree on this as a bug, the white background has to be transparent.
(In reply to Heiko Tietze from comment #13)
> Think we all agree on this as a bug, the white background has to be
But it's not only that. Something extra needs to be done. I tried what Mike Kaganski suggested before he even wrote here and it didn't work. I thought I needed a restart, so I decided to check next time I restarted Windows. It didn't work after rebooting.
Created attachment 151350 [details]
same issue with dark theme on Linux
On Linux Mint (19.1, cinnemon) with dark theme (Mint-Y Dark) several icons can not be perceived.
With effort in bug 132022, Tango will be dropped from the supported icon themes (but kept available as extension). That makes this issue as WF.