Bugzilla – Full Text Bug Listing
| Summary: | [hovering] Marker tooltip position wrong for dual monitor setup | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Eclipse Project] JDT | Reporter: | Simon Arsenault <simon_arsenault> | ||||
| Component: | Text | Assignee: | JDT-Text-Inbox <jdt-text-inbox> | ||||
| Status: | RESOLVED FIXED | QA Contact: | |||||
| Severity: | minor | ||||||
| Priority: | P3 | CC: | andylarder, bogofilter+eclipse.org, coding, eclipse, keinspam, martin.novak, martinae, n.a.edgar, sean_montgomery, steve | ||||
| Version: | 3.0 | Keywords: | helpwanted | ||||
| Target Milestone: | 3.2 RC1 | ||||||
| Hardware: | PC | ||||||
| OS: | Windows 2000 | ||||||
| Whiteboard: | |||||||
| Bug Depends on: | 50257, 72374, 135013 | ||||||
| Bug Blocks: | |||||||
| Attachments: |
|
||||||
|
Description
Simon Arsenault
Tom, you are using dual monitor setup. Can you confirm this behavior? Works for me with 200310150800 - eclipse on left or right monitor - editor at the left most position (except for perspective bar) -> error tooltip shows to the right Simon, can you give more details. Which build? What hardware (graphics driver). Note: Comment 2 is based on IBM desktop, Win2k cannot reproduce this (or bug 45093) on my W2K machine. I am using a Matrox G450 Dual Head with the same configuration (Taskbar positioned vertically at the left hand side of the left monitor), but also tried others. My video driver: Provider: Matrox Graphics Inc. Date: 28.9.2001 Version: 5.72.21.0 I'm running Windows 2000. I'm seeing this problem with 2.1.1 and also using 3.0 M3 (I'm using 2.1.1 now that I'm working the business rule tools). I have two graphics card. The NVIDIA Vanta for my primary monitor, and ATI RAGE 128 GL PCI card for my secondary monitor. The key thing about my setup is that my primary monitor is to my right, and my secondary monitor is to my left. So coordinate 0,0 is at the top left of my primary monitor (right side monitor). Therefore, all the coordinates on my secondary monitor will be negative (because its setup to be on the left side). I got Christophe to come and see the problem I report in bug 45093. He thinks it has to do with negative coordinate handling. Maybe the same applies here? (Note, my task bar is located to the left of my primary monitor which is my right monitor, not the left one). I see. Relevant code is in AbstractInformationControlManager::updateLocation, which does not account for negative offsets. *** Bug 60792 has been marked as a duplicate of this bug. *** *** Bug 41187 has been marked as a duplicate of this bug. *** can this get fixed for 3.0? It's makes developing code almost impossible on my secondary monitor because I cannot hover over the problem marker to see what the problem is. time permitting On my dual monitor system with the monitor 1 being the laptop screen and monitor 2 a real big monitor I run Eclipse M8 on monitor 2. The hovering tips above the keywords come up okay, but the tooltips over the file name tabs (where the file name and the close button for the file window is shown) appear on monitor 1. *** Bug 66587 has been marked as a duplicate of this bug. *** Removing target milestone, no further action for 3.0. *** Bug 64000 has been marked as a duplicate of this bug. *** *** Bug 95616 has been marked as a duplicate of this bug. *** *** Bug 96592 has been marked as a duplicate of this bug. *** *** Bug 82991 has been marked as a duplicate of this bug. *** *** Bug 97560 has been marked as a duplicate of this bug. *** There's been no changes to this bug (except marking other bugs as duplicates of this one, five, for a total of eight) since 2004-06-25 when it was noted that nothing would be done for 3.0. Now 3.1 is out and 3.2 is being worked on... what exactly *is* the target milestone for this bug? I realize that only two people have voted for this bug, but I don't think most people bother to vote. Nevertheless this bug really cuts down on the usefulness of using using multiple monitors - I regularly use two monitors, each with an Eclipse window (woot! screen real estate!) and this bug really makes it difficult to use. I suggest that more Eclipse developers/committers be outfitted with multiple monitors to make it easier to flush these multiscreen bugs out ;-) Currently it's not on our plan and hence no target milestone. A high quality patch will be thankfully accepted. Have the more or less same behaviour with a Win XP with a Matrox Millenium G550 HD Dual Monitor Setup. Right monitor is primary, left secondary. If I Have Eclipse on the left monitor, marker tooltips are shown to the right, so in most cases only a part of the text is readable, forcing me to switch often to the Problems view Eclipse 3.2M4 running on a dual monitor Mac running OS X 10.4.3 no longer shows this bug - the tooltip is positioned correctly (see bug 95616 for description of how the bug originally appeared on this hardware). Unfortunately the tooltip disappears a fraction of a second after it is displayed. No, it's not because I moved the mouse :-P Moving the mouse a little then stopping (leaving it over the same icon) will force the tooltip to reappear, only to disappear a fraction of a sec later. Repeat ad nauseum. The tooptip appears (and remains in sight) correctly on the main monitor (as usual). So it looks like the bug has been *almost* fixed by work performed on 3.2M4, at least on the Mac. I haven't tested it under Windows - can any Windows folks confirm/deny? It's soooo close to being fixed now... maybe some nice person will fix the disappearance issue, and this bug can be laid to rest. Doesn't seem to be fixed on Windows 20060105-0800. The setup: Primary monitor is labtop monitor, on the right Secondary monitor is attached monitor, on the left. Eclipse on the left: Tooltips on the right edge are put to the rigth monitor, should always be on the same monitor as the mouse pointer. Also very strange: Tooltips always appear over of the mouse pointer (normally always below the mouse pointer). If there's not enough space on top, the tooltip just flickers. 3.2M6 on OS X 10.4.5, dual-monitor setup described at https://bugs.eclipse.org/bugs/show_bug.cgi?id=95616#c0. The primary (right) monitor shows tooltips correctly, the left (secondary) displays the tooltip for just a moment, as mentioned in https://bugs.eclipse.org/bugs/show_bug.cgi?id=45095#c22. On closer inspection the tooltip on the left monitor is positioned correctly vertically, but not horizontally. Instead of the left edge of the tooltip being in column one of the text editor it's up against the left edge of the screen. I've been trying out a number of the bugs listed as duplicates of this one on 3.2M6 on OS X 10.4.5 and I'm noticing that the bugs are still there but that they don't all exhibit the same symptoms. For example, for a secondary on left, primary on right dual monitor setup: - Quick Diff popups show up to the left of the line numbers on the left monitor instead of to the right like on the right monitor, potentially getting clipped by the left edge of the left monitor if the editor was maximized. Note that folded-code popups are similar to the Quick Diff popups, in position and clipping. - Syntax error marker tooltips used to (pre 3.2M4) show up on the left of the icon, potentially getting clipped by the left edge of the left monitor if the editor was maximized. In 3.2M4 and higher they aren't clipped, but they disappear after appearing for only a fraction of a second. They also are positioned too far to the left, see comment 24. I wasn't able to duplicate bug 97560 as I don't have three monitors. It mentions a tooltip that shows up in the center of the wrong monitor, which doesn't sound like either of the other two cases above. Perhaps they shouldn't all be grouped into one bug? I'm afraid I haven't gone to the source code and checked - have the implementations of these JDT specific tooltips/popups been affected by the architecture changes mentioned in bug 72374? >I'm afraid I haven't gone to the source code and checked - have the
>implementations of these JDT specific tooltips/popups been affected by the
>architecture changes mentioned in bug 72374?
No.
*** Bug 134427 has been marked as a duplicate of this bug. *** Addendum to comment 25: Bug 134427 is visually different from the other bugs mentioned. It's the only one I've seen that is horizontally correct on the left monitor. So that's three distinct visual manifestations of 45095 on OS X. Looking at the 3.2M6 source: Tom is correct in comment 6, AbstractInformationControlManager.updateLocation doesn't account for negative offsets. That method is passed a rectangle representing the display area (the union of the display areas of all monitors) which is used correctly for the most part. The mistake is in the final predicate for each of the five anchor types, where the (potentially) updated location is checked to see if it is "useful". Currently the code checks to see if the location (the lower left coord) of the control is on the main screen, i.e. compared to zero: return (location.x >= 0 && location.y >= 0); instead of checking to see if it's in the display area: return location.x >= displayArea.x && location.y >= displayArea.y; Changing this predicate in the three places it appears in updateLocation should fix things. As it is now, if you have a popup or tooltip control show up on the secondary monitor in a dual monitor setup, updateLocation will always return false because of the predicate error above. That forces the calling method, AbstractInformationControlManager.computeInformationControlLocation(), to iterate through all of its fallback anchors, calling updateLocation on each, which fail in turn. Once it reaches the last fallback anchor it has no choice but to keep it. That's what gives rise to the multiple visual issues that bothered me so much: the last javadoc popup fallback anchor is above the correct position, the folded-code popup fallback anchor is to the left of the correct position, etc. Can somebody else take a look to confirm the three-line fix? I didn't get a chance to chase down the weird flashing behavior of the syntax error popups (which also affects TODO popups). I did see why the syntax error/TODO popups are never offscreen, though. Unlike the javadoc popup (a BrowserInformationControl) and the folded-coded popup (a SourceViewerInformationControl), the syntax error & TODO popups are DefaultInformationControls. When setVisible(true) is called on BrowserInformationControl and SourceViewerInformationControl they call Shell.setVisible(true) which, well, makes them visible. DefaultInformationControl, however, aggregates a PopupDialog, so when setVisible(true) is called on a DefaultInformationControl then PopupDialog.open() is invoked, which calls Window.constrainShellSize(), which moves the errant controls back into the visible screen area. See, the code from bug 72374 was involved here ;-) Created attachment 37700 [details]
Patch to allow valid negative coords for tooltips
updateLocation no longer returns false for valid negative locations.
(In reply to comment #29) > ... Currently the code checks to see if the location (the lower left > coord) of the control is on the main screen, i.e. compared to zero: > ... Sorry, it was late. Make that "upper left coord" for the location of the control. The patch in comment 30 is written accordingly. The patch is simple (only touches org.eclipse.jface.text.AbstractInformationControlManager) but works on everything I tried. The AbstractInformationControlManager could still be cleaned up a bit, though: 1) updateLocation: If the control location satifies the anchor criterion this method will in some cases reposition the control if it would extend off the right and/or bottom edge of the display area. If the control location would extend off the left/top edge of the display area, however, the method simply returns false. It's not clear why. 2) internalShowInformationControl: Resizes the control if it would extend off the right or bottom edge of the display area. Again, it's not clear why the correction isn't made if the left or top edges are involved. 3) internalShowInformationControl: Enforces a maximal size for the control if requested. Beyond that, plus the partial fixups mentioned in items 1) & 2) none of the other methods in the class handle the edge case of a control that's larger in width and/or height than the display area. 4) computeInformationControlLocation: If updateLocation returns false for all the anchors this method silently uses the last anchor in the fallback anchor array. It might make more sense to let the calling method (internalShowInformationControl) know that a valid location was not found. Number 4 isn't really a bug, but the other three items could allow a control to be poorly located under some uncommon circumstances. These items only apply to IInformationControl implementations like SourceViewerInformationControl or BrowserInformationControl that don't delegate to a PopupDialog like DefaultInformationControl. I've reviewed and released the patch with the following addition to the copyright notice: * Sean Montgomery, smontgomery@mediaspansoftware.com - https://bugs.eclipse.org/bugs/show_bug.cgi?id=45095 We won't address the other problems reported in comment 31 since - as stated correctly - they will go away once the SourceViewerInformationControl and the BrowserInformationControl use the PopupDialog (see bug 72374 and bug 135013). |