Currently if the preview thumbnail icons for LO-linked files are enabled on Windows, the thumbnail shows a (zoomed-out) page of the file, with a black border, then a white "frame" to expand to the usual icon size, with an LO icon added at the bottom-right corner. This looks nice with a white background (e.g. the default setting of a Windows Explorer window), however with a dark background (e.g. the desktop with customized wallpaper), the white "frame" looks rather odd and out of place. It would be nice if the "frame" is changed from white to transparent, so that the thumbnail icon adapts well for both light and dark background.
Hello Ming Hua, Could you please add a screenshot of the problem you are referring to ?
Created attachment 154428 [details] Icon on dark background (problematic)
Created attachment 154429 [details] Icon on light background (fine)
(In reply to Xisco Faulí from comment #1) > Hello Ming Hua, > Could you please add a screenshot of the problem you are referring to ? Definitely, added. These are the default size (called "medium", I believe) icons. The frame is more prominent when using "large" and "extra large" icons.
Never seen this icon. Where do you download (and maybe you could add the first couple of lines from the about dialog, it's copyable)?
(In reply to Heiko Tietze from comment #5) > Never seen this icon. Where do you download (and maybe you could add the > first couple of lines from the about dialog, it's copyable)? The official MSI installer from https://www.libreoffice.org/download/download/ . The "About LO" info: Version: 6.2.8.2 (x64) Build ID: f82ddfca21ebc1e222a662a32b25c0c9d20169ee CPU threads: 2; OS: Windows 10.0; UI render: default; VCL: win; Locale: zh-CN (zh_CN); UI-Language: en-US Calc: threaded
Confirmed. On Windows 10 Home 64-bit en-US with Version: 6.3.2.2 (x64) Build ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU threads: 4; OS: Windows 10.0; UI render: GL; VCL: win; Locale: en-US (en_US); UI-Language: en-US Calc: threaded and recent masters. These are thumbnails from the Windows Explorer (shlxthdlr) built-in extension [1][2], not thumbnails used on the StartCenter and Template manager backing window. Don't know if the GDI plus bitmap extraction can generate a PNG with alpha channel transparency. But if it can, this integration with os/DE shell would be cleaner--especially as Windows has now implemented its Dark 'default App mode' theme. =-ref-= [1] https://opengrok.libreoffice.org/xref/core/shell/source/win32/shlxthandler/ [2] https://opengrok.libreoffice.org/xref/core/shell/source/win32/shlxthandler/thumbviewer/thumbviewer.cxx?r=64985454#335
I suppose you could try modifying line 397 [1] to define first argument (alpha) to be 0. [1] https://opengrok.libreoffice.org/xref/core/shell/source/win32/shlxthandler/thumbviewer/thumbviewer.cxx?r=64985454#397
(In reply to Mike Kaganski from comment #8) > I suppose you could try modifying line 397 [1] to define first argument > (alpha) to be 0. > > [1] > https://opengrok.libreoffice.org/xref/core/shell/source/win32/shlxthandler/ > thumbviewer/thumbviewer.cxx?r=64985454#397 Otherwise, would replacing the legacy W2K era IExtractImage & IExtractImage2 we've been using to format the extracted preview be appropriate now? Does the Windows Vista era IThumbnailProvider interface [1] offer a cleaner way to extract document previews without needing the backing rectangle being filled white using the SolidBrush fillRectangle and black border? Suggests the IThumbnaiProvider would more broadly handle the container for the thumbnail--we'd now just have to give it the bitmap out of the archive (maybe include Flat ODF as for bug 53534). And so improving the os/DE integration on Windows? =-ref-= [1] https://docs.microsoft.com/en-us/windows/win32/shell/thumbnail-providers
(In reply to V Stuart Foote from comment #9) No objections at all - I'd be glad to review a patch with transition from IExtractImage to IThumbnailProvider. Or maybe not get rid of the former, but do it two-step, adding IThumbnailProvider in one commit, and removing IExtractImage in the second: it might happen that IExtractImage is still used *somewhere*, and splitting commits would enable to revert that one in case when both turn out to be useful. Thanks!