Bug 134065 - Start Center: No-thumbnail view now uses small icons for non-encrypted documents
Summary: Start Center: No-thumbnail view now uses small icons for non-encrypted documents
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Mike Kaganski
URL:
Whiteboard: target:7.4.0
Keywords: bibisectNotNeeded, regression
Depends on:
Blocks: Start-Center
  Show dependency treegraph
 
Reported: 2020-06-17 10:01 UTC by Mike Kaganski
Modified: 2023-05-22 22:56 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
Encrypted vs unencrypted icons in Start Center (32.12 KB, image/png)
2020-06-17 10:01 UTC, Mike Kaganski
Details
Encrypted vs unencrypted icons in Start Center - v.6.4 (30.58 KB, image/png)
2020-06-17 10:39 UTC, Mike Kaganski
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Mike Kaganski 2020-06-17 10:01:48 UTC
Created attachment 162105 [details]
Encrypted vs unencrypted icons in Start Center

Since https://git.libreoffice.org/core/+/997a504f33bbd43c02a96a2a593a03e58bd3b72c, Start Center shows small icons for non-encrypted documents that don't show thumbnails.

Steps:
1. In Expert Configuration, disable RecentDocsThumbnail setting.
2. Create and save an encrypted document, and an unencrypted document, to have them both in Start Center.
3. Compare their display.

The result in master is as in the attached screenshot.
Comment 1 Heiko Tietze 2020-06-17 10:05:28 UTC
Guess the large icon was chosen because no content can be shown due to encryption. The mentioned patch just changed the icon size for the (non-encrypted) overlay.
Comment 2 Mike Kaganski 2020-06-17 10:34:50 UTC
(In reply to Heiko Tietze from comment #1)
> Guess the large icon was chosen because no content can be shown due to
> encryption. The mentioned patch just changed the icon size for the
> (non-encrypted) overlay.

No. It changed not "the icon size for the (non-encrypted) overlay", but icon size returned from getDefaultThumbnail. And the latter is used not only to get the overlay, but also in RecentDocsViewItem::RecentDocsViewItem, for cases when an item does not have a thumbnail: that includes combinations of "no thumbnail in registrymodifications.xcu"; "file is not from file: protocol"; "RecentDocsThumbnail is false"; "file URL is unaccessible". And the screenshot clearly displays that "just changed the icon size for the (non-encrypted) overlay" is not correct ;-)
Comment 3 Mike Kaganski 2020-06-17 10:39:30 UTC
Created attachment 162112 [details]
Encrypted vs unencrypted icons in Start Center - v.6.4

For the reference - that is how it looks like in v.6.4. Compare the icon sizes.
Comment 4 Heiko Tietze 2020-06-17 11:04:46 UTC
Thumbnail icons are now 48 (and painted in 48) to make it crisp as requested in bug 130936. Sounds like a plan to draw larger images if the option is off / no thumb content is retrieved from documents. We have plenty of large MIME type images.
Comment 5 Mike Kaganski 2020-06-17 11:08:27 UTC
(In reply to Heiko Tietze from comment #4)
> Thumbnail icons are now 48 (and painted in 48) to make it crisp as requested
> in bug 130936. Sounds like a plan to draw larger images if the option is off
> / no thumb content is retrieved from documents. We have plenty of large MIME
> type images.

No - please just revert that change, and instead reimplement the solution for tdf#125756 (https://git.libreoffice.org/core/+/d43c6fa220524a09c0b24cbb5bc03c4456cd2515) to not use the pre-existing getDefaultThumbnail (that returns large thumbnails, and in the course, checks if the URL is encrypted), but introduce another similar function, that would return the smaller images without checking encryption (solving tdf#131850 at the same time).
Comment 6 Heiko Tietze 2021-12-17 08:56:47 UTC
Is this WFM'ed with your patch, Mike?
Comment 7 Mike Kaganski 2021-12-17 09:00:27 UTC
(In reply to Heiko Tietze from comment #6)

Did you test?
Comment 8 Mike Kaganski 2021-12-17 09:08:58 UTC
(In reply to Mike Kaganski from comment #5)

My code pointer:
1. Revert git.libreoffice.org/core/+/997a504f33bbd43c02a96a2a593a03e58bd3b72c in 'sfx2/inc/bitmaps.hlst' part;
2. Add "Size48" to vcl::ImageType;
3. Implement its handling in GetImageNameFromList_Impl (svtools/source/misc/imagemgr.cxx), to use the images that you referred to in 997a504f33bbd43c02a96a2a593a03e58bd3b72c;
4. Use SvFileInformationManager::GetFileImageId instead of getDefaultThumbnail in sfx2/source/control/recentdocsview.cxx (see your https://gerrit.libreoffice.org/c/core/+/76537/).
Comment 9 Rizal Muttaqin 2021-12-18 10:59:21 UTC
(In reply to Mike Kaganski from comment #5)
> No - please just revert that change, and instead reimplement the solution
> for tdf#125756
> (https://git.libreoffice.org/core/+/
> d43c6fa220524a09c0b24cbb5bc03c4456cd2515) to not use the pre-existing
> getDefaultThumbnail (that returns large thumbnails, and in the course,
> checks if the URL is encrypted), but introduce another similar function,
> that would return the smaller images without checking encryption (solving
> tdf#131850 at the same time).

Fully agree with the solution. The two functions (get thumbnail overlay and show large MIME type icons) should be separated so we can get two different icons to show.
Comment 10 Mike Kaganski 2022-03-15 15:33:40 UTC
https://gerrit.libreoffice.org/c/core/+/131610
Comment 11 Commit Notification 2022-03-15 20:19:48 UTC
Mike Kaganski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1dbed50a6ed73570ca2d8a1e37237205e2394c34

tdf#134065, tdf#147998: fix thumbnail generation code

It will be available in 7.4.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.
Comment 12 Mike Kaganski 2022-03-16 06:12:36 UTC
Before-vs-after the fix: attachment 178904 [details] and attachment 178905 [details].
Comment 13 Heiko Tietze 2022-03-16 06:51:32 UTC
(In reply to Mike Kaganski from comment #12)
> Before-vs-after the fix...

Beautiful!
Comment 14 Rizal Muttaqin 2022-03-16 10:06:38 UTC
(In reply to Mike Kaganski from comment #12)
> Before-vs-after the fix: attachment 178904 [details] and attachment 178905 [details]
> [details].

Superb and fascinating. Could not wait for newest daily master build