Description: The overlaid icons in grid controls are no longer transparent, one can see the darker grey background of the icon overlaid over the top of the grid control (and displaced by a couple of pixels). Steps to Reproduce: 1) Create a database, add a table. 2) Create a form from table using the wizard and accepting the defaults (grid control). Save the form. 3) Open the form to enter data. 4) Notice how the cursor icon and the new record icon are not transparent against the background of the grid control. Actual Results: See above Expected Results: The icons should have a transparent background, or at least should be the same colour as the grid border background shade. Positioning of the icons should also not be displaced relative to the cells of the grid border (perhaps this is the root cause). Reproducible: Always User Profile Reset: No Additional Info: User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.12; rv:50.0) Gecko/20100101 Firefox/50.0
I thought that maybe the icon theme might be the cause, but testing with Galaxy and Breeze produces the same results.
Created attachment 130199 [details] Screenshot showing non transparent icons in grid control
The effect is zoom dependent, I am enclosing 2 further screenshots with different zoom factors in the form : 130% and 220% In the 130% zoom, the background colour of the icons is the same as the form. In the 220% zoom, the background colour of the icons is a shade of grey that does not match the grey of the grid control border cells.
Created attachment 130200 [details] 130% zoom
Created attachment 130201 [details] 220% zoom
Created attachment 130202 [details] screen capture video showing zoom effect changes This is a short quicktime MOV format video showing the effect of zooming down on the icons in the grid control
No issue here. You could play around with OpenGL (Options > View) but icon transparency works for me with or without GL. Version: 5.4.0.0.alpha0+ Build ID: b7c55b662810ee3bf82d134ff1ff9a96bfee4046 CPU Threads: 8; OS Version: Linux 4.8; UI Render: default (2nd try UI Render: GL); VCL: gtk2; TinderBox: Linux-rpm_deb-x86_64@70-TDF, Branch:master, Time: 2016-12-15_01:12:52 Locale: en-US (en_US.UTF-8); Calc: group Arch Linux, LXQt, KWin libpng-config --version >1.6.27 lspci -vnn | grep VGA >00:02.0 VGA compatible controller [0300]: Intel Corporation 4th Gen Core Processor Integrated Graphics Controller [8086:0416] (rev 06) (prog-if 00 [VGA controller]) >glxinfo | grep OpenGL OpenGL vendor string: Intel Open Source Technology Center OpenGL renderer string: Mesa DRI Intel(R) Haswell Mobile OpenGL core profile version string: 3.3 (Core Profile) Mesa 13.0.2 OpenGL core profile shading language version string: 3.30 OpenGL core profile context flags: (none) OpenGL core profile profile mask: core profile OpenGL core profile extensions: OpenGL version string: 3.0 Mesa 13.0.2 OpenGL shading language version string: 1.30 OpenGL context flags: (none) OpenGL extensions: OpenGL ES profile version string: OpenGL ES 3.1 Mesa 13.0.2 OpenGL ES profile shading language version string: OpenGL ES GLSL ES 3.10 OpenGL ES profile extensions:
(In reply to Heiko Tietze from comment #7) > No issue here. You could play around with OpenGL (Options > View) but icon > transparency works for me with or without GL. > My understanding was that there is no OpenGL support in the OSX versions, and so little point attempting to toggle it on/off - by default it is off.
Alex can you let us know which versions this is affected by, so we can narrow down the bibisect request.
(In reply to Yousuf Philips (jay) from comment #9) > Alex can you let us know which versions this is affected by, so we can > narrow down the bibisect request. Would love to, but juggling older versions of LO with Base is fraught with frustration on OSX because of the requirements to have different versions of Java installed (AppleJavaforOSX, Oracle JRE, Oracle JDK < 102, Oracle JDK > 102). This makes testing any given Base file over different versions of LO extremely awkward.
(In reply to Alex Thurgood from comment #10) > Would love to, but juggling older versions of LO with Base is fraught with > frustration on OSX because of the requirements to have different versions of > Java installed (AppleJavaforOSX, Oracle JRE, Oracle JDK < 102, Oracle JDK > > 102). This makes testing any given Base file over different versions of LO > extremely awkward. As you've set the regression keyword, we would need to know how far back this issue goes or was it inherited from OOo. So if you have OpenOffice, try testing that first so we know if its OOo inherited or not and then with LO, if you can test 4.4 and 5.1, i think that would be sufficient to know if it happened over the last few years.
Tested with LO3672 - no problem.
Tested against LO4162 - no problem
Problem first visible in LO4452 (BuildID a22f674fd25a3b6f45bdebf25400ed2adff0ff99)
FWIW, I also tested versions 4252, and 4341 - no problem there.
So, to narrow down the search, the problem was introduced between 4341 and 4452
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the information from Help - About LibreOffice. If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice. Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to 'inherited from OOo'; 4b. If the bug was not present in 3.3 - add 'regression' to keyword Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still reproducible in Version: 6.1.1.2 Build ID: 5d19a1bfa650b796764388cd8b33a5af1f5baa1b Threads CPU : 8; OS : Mac OS X 10.13.6; UI Render : par défaut; Locale : fr-FR (fr_FR.UTF-8); Calc: group threaded
Note that as soon as you drop the page magnification of the form below 100%, e.g. 90%, then the background colour of the icon adopts the background colour of the form page...
Worksfrome with Version: 6.4.0.0.alpha0+ Build ID: 75d35ef8df1936dd93d5919b688abcaddb58bee8 CPU threads: 4; OS: Mac OS X 10.14.5; UI render: default; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI-Language: en-US Calc: threaded