Bug 332335 - Links fade to pitch black when mouse hoovering over them
Summary: Links fade to pitch black when mouse hoovering over them
Status: RESOLVED DOWNSTREAM
Alias: None
Product: plasma4
Classification: Unmaintained
Component: qml-components (show other bugs)
Version: unspecified
Platform: MacPorts macOS
: NOR minor
Target Milestone: ---
Assignee: Plasma Bugs List
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2014-03-19 20:37 UTC by Marko Käning
Modified: 2014-04-19 01:10 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:
Sentry Crash Report:


Attachments
Snapshot showing the "New project" toolbutton to go black when hovering the (here invisible) mouse over it (28.97 KB, image/png)
2014-04-07 21:37 UTC, Marko Käning
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Marko Käning 2014-03-19 20:37:49 UTC
The links to "Learn KDevelop!", "New Project", "Open Project", etc. fade from visible to a pitch black rectangle when I hoover with the mouse over them.

They reappear normal once the mouse leaves the bounding box of the pointed-to-item.

Reproducible: Always

Steps to Reproduce:
1. Go to Sessions page
2. Hoover with the mouse e.g. over "New Project"
3. See the text fading over into a black rectangle
Actual Results:  
To-be-chosen item unreadable as a result

Expected Results:  
Item should change background, but not foreground, presumably... :-)
Comment 1 Kevin Funk 2014-04-06 01:21:52 UTC
Can you add a screenshot?

We're simply using the Plasma component "ToolButton" here, so it's rather a bug over there. Reassigning.
Comment 2 Marko Käning 2014-04-07 21:37:48 UTC
Created attachment 85991 [details]
Snapshot showing the "New project" toolbutton to go black when hovering the (here invisible) mouse over it
Comment 3 Thomas Lübking 2014-04-17 07:57:35 UTC
@Ian
Not sure this is about QPainter::CompositionMode_DestinationIn
Does it remain black while hovered (ie. after any animation transition should be done)?
This could rather be "d->background->paintFrame(painter);" then and that might be the result of a garbled cached pixmap (created with native graphicssystem and shared among all processes)

Please don't ask me where the cache resides on OSX. On Linux it'd be /var/tmp/kdecache-`whoami`/plasma_theme_*

Try to
    export QT_GRAPHICSSYSTEM=raster
to get the raster graphicssytem globally (w/o passing a switch)
Comment 4 Ian Wadham 2014-04-18 22:43:23 UTC
(In reply to comment #3)
> Not sure this is about QPainter::CompositionMode_DestinationIn
> Does it remain black while hovered (ie. after any animation transition
> should be done)?
>
In the screenshot previously attached, each of the buttons on the right goes black for as long as you hover over it.  On the left is a group of two toggle-buttons. One of them is "on" and is black all the time.

> This could rather be "d->background->paintFrame(painter);" then and that
> might be the result of a garbled cached pixmap (created with native
> graphicssystem and shared among all processes)
> 
Yes! Clearing the cache, in combination with raster graphics fixes the problem and KDevelop shows nice highlighting. The cache in OS X is exactly where you said, Thomas, maybe courtesy of some links by MacPorts.
Comment 5 Ian Wadham 2014-04-18 22:57:45 UTC
This bug can be fixed by deleting cache files that contain the black highlighter (files /var/tmp/kdecache-`whoami`/plasma_*) and using Qt's raster graphics forever after that, either by using command-line switch -graphicssystem raster, or export QT_GRAPHICSSYSTEM=raster or installing Qt with the raster system configured, rather than native.  See http://qt-project.org/doc/qt-4.8/qapplication.html#setGraphicsSystem

NOTE: Raster should be the default in Qt 4.8+ and is standard in Qt5.
Comment 6 Thomas Lübking 2014-04-18 23:28:46 UTC
Technically, this would be a dupe of bug #333429 then and both either upstream (broken Qt/Quartz/driver) or downstream (Qt compiled defaulting to native graphicssystem, though it should of course work on that backend nevertheless) 

QPainter::setOpacity() equals SourceOver, not the DestinationIn processing, thus is no perfect substitute (becomes obvious problem when the destination is not opaque)
Comment 7 Ian Wadham 2014-04-19 01:10:39 UTC
I have already asked to have raster graphics become the default on MacPorts but will increase my efforts now.