Bug 91321 - Visibility of icons on retina display
Summary: Visibility of icons on retina display
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.4.0.3 release
Hardware: x86-64 (AMD64) macOS (All)
: medium minor
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: HiDPI
  Show dependency treegraph
 
Reported: 2015-05-16 08:19 UTC by Ben McGinnes
Modified: 2015-05-19 06:57 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Attachments
Screenshot: LO 4.4 icons on a retina display (338.29 KB, image/png)
2015-05-16 08:21 UTC, Ben McGinnes
Details
Screenshot: LO 4.3 icons on a retina display (365.71 KB, image/png)
2015-05-16 08:22 UTC, Ben McGinnes
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ben McGinnes 2015-05-16 08:19:17 UTC
While this may be related to bug #51733 in some respects, this is really a feature request for those of us who have both retina displays (or other high resolution monitors) and myopic vision (short-sighted).

In addition to the issues raised in the other bug regarding fuzzy icons, the new OS X icon set introduced in LO 4.4 is almost entirely monochromatic.  This reduces the ease by which each icon may be readily identified with a glance, particularly by comparison to the coloured icons available in version 4.3.7.

Screenshots with the differences between the two will be uploaded shortly.

Quick and easy work-around:  Use LibreOffice 4.3.x instead.  Currently this is the only work-around (see below).

Fiddly work-around which may break things in unknown ways:  locate the LO 4.3 icons within the .app directory structure and copy them over the corresponding icon filenames in the LO 4.4 .app directory structure.  Note: this has not yet been done since there are other bugs which require using LO 4.3, so there is no point (yet).

Preferred solution:  Being able to select the icon format as with other aspects of the LO appearance in the LO preferences panel.
Comment 1 Ben McGinnes 2015-05-16 08:21:17 UTC
Created attachment 115651 [details]
Screenshot: LO 4.4 icons on a retina display
Comment 2 Ben McGinnes 2015-05-16 08:22:37 UTC
Created attachment 115652 [details]
Screenshot: LO 4.3 icons on a retina display
Comment 3 Ben McGinnes 2015-05-16 13:00:13 UTC
You really need a secondary source to confirm a feature request?!

That's just weird.
Comment 4 Buovjaga 2015-05-16 15:23:12 UTC
Can you please try a master build, which should have the Breeze icon set on by default: http://dev-builds.libreoffice.org/daily/master/MacOSX-10.10@61/
If it's not default, Tools - Options - View - Icon size and style.

Are you unable to change the icon set in 4.4 to Tango btw.?
Comment 5 Adolfo Jayme Barrientos 2015-05-16 18:35:46 UTC
Also, you may want to switch to large icons in order to increase visibility. (Large icons are enabled by default for new user profiles.)
Comment 6 Ben McGinnes 2015-05-19 06:44:09 UTC
I've tried the master build for 18/5/2015 for 10.9 (not the one linked to which was built for 10.10/Yosemite) and it does indeed work for all aspects of changing the icons.  It also worked for bringing up the styles menu when pressing Command+T and displaying the sidebar menu, which had not been working here (and reported separately in bug #91319).  It did not, however, export PDFs with correct alignment, so that's still a thing and has been reported elsewhere.

The master version tried was this one:

Version: 5.0.0.0.alpha1+
Build ID: 2ca7795a6a723c701f295323fcc3f6c52ad37976
TinderBox: MacOSX-x86_64@49-TDF, Branch:master, Time: 2015-05-18_00:48:47
Locale: en-US (en.UTF-8)

Locally I use the standard with the en-GB language patch applied and my own locale settings are:

bash4-4.3$ locale
LANG="en_AU.UTF-8"
LC_COLLATE="en_AU.UTF-8"
LC_CTYPE="en_AU.UTF-8"
LC_MESSAGES="en_AU.UTF-8"
LC_MONETARY="en_AU.UTF-8"
LC_NUMERIC="en_AU.UTF-8"
LC_TIME="en_AU.UTF-8"
LC_ALL="en_AU.UTF-8"
bash4-4.3$ 

Interestingly I also checked a fresh installation of 4.4.3.2 which presented identical behaviour to the master build, but here's the thing: the fresh installation was downloaded from my ISP's mirror server, but the broken version(s) were downloaded directly from the libreoffice.org website.  If it had been the other way around I'd be less surprised and just put it down to some corruption in the data transfer through mirroring, but this way is a little odd.

What I find more bizarre, though, is the apparent "fix" with the confirmed bug in #91319, which has been isolated to changes made to menus, toolbars and the sidebar.  I've got zero explanations for that, unless installing the dev version has somehow affected the others, but again, that makes little sense.  Especially given the fact that OS X .apps are just self-contained directories with the relevant libraries and other components within.

I'd recommend closing this case, but keeping it in mind with future dev work in case anyone else sees the same behaviour.  For my part I will need to stick with 4.3.7 and above until the issue with styles being exported to PDF is fixed as that's a mandatory requirement for anything I have to send anywhere (e.g. gov't submissions), but otherwise I'll be happy to periodically check the master builds for updates and improvements (especially if a PDF export fix can be confirmed and backported to the 4.4 branch).

I'll put this back to UNCONFIRMED now and you guys can decide whether you want to close it or dig deeper into downloaded version weirdness.  I'll confess, though, I didn't check the shasums and deleted the copies that didn't work properly so it might be a bit of a dead-end.  Hence suggesting closing it and keeping an eye out for anyone reporting the same thing in future.

Thanks for your time.
Comment 7 Ben McGinnes 2015-05-19 06:52:02 UTC
Oh,BTW, I just double-checked, the PDF styles bug I was referring to is bug #88941 and is clearly very much confirmed.
Comment 8 Buovjaga 2015-05-19 06:57:28 UTC
Thank you for testing. I'll set to WORKSFORME.