Version: Version 1.0.99 (using KDE 4.0.98) Installed from: Fedora RPMs OS: Linux I am running the system with two screens using twinview (nvidia) with an fake xinerama (two seperated screens, not merged together as one). When I hovering over a file in dolphin on the right screen (secondary), the tooltip is always showed on the left screen (primary). This is quite confusing for the users, because if you are looking on the right screen, you expect that the tooltip is shown next to the item your had hovered. The position y value seems to be correct, however the x position is always at the right end of the screen. It looks like the tooltip doesn't care about the screen it is displayed and is always shown on the first (primary?) screen. Other tooltips in application are displayed correctly, so it seems only related to the file item tooltips of dolphin. I am attaching a screenshoot with both screen to show the problem.
Created attachment 26330 [details] Screenshoot of the problem The tooltip is shown on the left screen, when the users hovers over a file on the right screen.
Reassign Dolphin -> Kwin
Works for me with the same setup (Maybe I misread?). However I've noticed that the popup actually doesn't obey Xinerama hints at all and thus likes to appear with half the popup on one screen and the other half on the other. Maybe related?
I've added Fredrik to CC, as he wrote the main parts of the Dolphin tooltips.
Hm, I actually not sure. I am not using Xinerama, but Twinview from Nvidia. It works basically like Xinerama, but it's not a seperated X-Server instance. (this makes it possible to use 3d-effects from kwin on both screens, while xinerama doesn't seems to handle this). So maybe we have a different configuration? I am attaching my xorg.conf. Maybe this helps to ensure that we actually are running the same configuration. Maybe we also using a different xserver? I am on F9 running Xorg 1.5 already. Nvidia driver version is 173.14.09 on a 32bit system.
Created attachment 26332 [details] The xorg configuration where the problem occurs.
KWin does nothing about tooltips -> either Dolphin or libraries bug.
Created attachment 26417 [details] Make tooltips obey screen geometries Safe to commit?
@Lucas: Thanks a lot for the patch! Please don't commit yet, I'll have to do some tests first. I think the patch misses one corner case where the tooltip might be shown directly under the mouse cursor if the item is in the bottom right corner. The original code handled this in this part: if ((xDiff > 0) && (yDiff > 0)) { x = m_itemRect.left() - size.width(); y = m_itemRect.top() - size.height(); } ... Shouldn't it be enough just to replace const QRect desktop = QApplication::desktop()->availableGeometry(); by const QRect desktop = QApplication::desktop()->screenGeometry(m_itemRect.bottomRight()); ?
The QRect returned from screenGeometry() has an offset for screens that are not on the lefthand side. Just changing the one line causes the tooltip to sometimes be displayed half on one screen and half on another making it difficult to read. For the cursor thing I didn't even know it was possible. What should happen when the tooltip overlaps the mouse? Would moving the tooltip to the bottom-left corner of the highlighted item be enough?
> The QRect returned from screenGeometry() has an offset for screens that > are not on the lefthand side. Just changing the one line causes the > tooltip to sometimes be displayed half on one screen and half on > another making it difficult to read. Ah, I see. Thanks for clarification! > What should happen when the tooltip overlaps the mouse? > Would moving the tooltip to the bottom-left corner of > the highlighted item be enough? Yes, that would be enough. The old code moved the bottom/right edge of the tooltip to the top/left edge of the item in this case. But for sure it would be OK (or better?) just to move the tooltip to the bottem-left corner of the highlighted item too. To reproduce this case: Just move the dolphin window in a way that one item is near the bottom right edge of the desktop and highlight this item. When just assuring that the tooltip does not exceed the width and height of the desktop and subtracting the difference, the tooltip would appear behind the mouse and the item would get invisible.
Created attachment 26419 [details] Make tooltips obey screen geometries, r2 Looks like the screen offset bit wasn't needed. Anyway, now it does the top/left thing instead of just pushing the tooltip back onto the screen.
Lucas, I just tried your patch but it does not work for the usecase I explained (see attached screenshot - mouse is above "Temp"). I'm currently concentrating on some other things - I'm not sure whether you have the time and motivation further investigating into this issue ;-) If not this is no problem and I'd use your patch as base for a final fix. Please just give me some time...
Created attachment 26421 [details] wrong tooltip position
stupid me - mixed x and y in my version (I just typed your patch as it is so short) - everything OK, I'll submit the patch :-)
SVN commit 838041 by ppenz: Tooltips are shown on wrong position in combination with a dual screen setup. Thanks to Lucas Murray for the patch! BUG: 167205 M +4 -9 tooltipmanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=838041
SVN commit 838042 by ppenz: Backport of 838041: Tooltips are shown on wrong position in combination with a dual screen setup. Thanks to Lucas Murray for the patch! CCBUG: 167205 M +4 -9 tooltipmanager.cpp WebSVN link: http://websvn.kde.org/?view=rev&revision=838042
I just want to confirm that this fixes the issue on my system in the current trunk. Thanks for your work patching this issue pretty fast! :)