Community
Participate
Working Groups
Version: 3.2.0 Build id: I20060331-2000 When quickly hovering over code the Browser-Hover switches its content quite a lot. Sometimes you can see a white-background which most likely results from a call to Browser#setText(""). Compared to the hold StyledText hover, this white-background is bringing some flickering (at least for me its defnitly more visual than with the StyledText hover). Maybe this could be relaxed with setting the background of the Hover to the Tooltip color, or not setting the text to an empty String at all? Ben
I don't see this on WindowsXP. Do you have a test case?
We do set the background. I'll have to check whether we missed one place.
No I dont have a test-case other than simply hovering over Methods and Fields of a Class, like: public class Main { public static void main(String[] args) { Display display = new Display(); Shell shell = new Shell(display); shell.setLayout(new FillLayout()); shell.open(); while (!shell.isDisposed()) { if (!display.readAndDispatch()) { display.sleep(); } } } } Moving the cursor around I can see the busy-cursor very frequently. Actually I am not totally sure if the background shows in white sometimes, its really hard to spot. When I find a better test-scenario, I will let you know. Ben
What you probably notice is the flickering of the cursor due to bug 134390. I see that too.
Sometimes we see a white background (can also be seen when opening the Javadoc view the first time) and this even though we call Browser.setText(...) before the widget is visible and the text contains the color to be used. Moving to SWT - there's not much we can do.
Not sure there's much we can do if the operating system is filling with white.
I think calling setText makes the browser load the text asynchronious to the callee. Maybe delaying the call to setVisible by some milis makes things better? Ben
I hope you're not suggesting to do this for all clients. Also note that calling Browser.setBackground(Color) has not effect.
No, its would just be a temp. solution for the case of the Eclipse Hover, if no other solution was possible in the 3.2 stream. Ben
It's not just the hover. It's also in the Javadoc view.
(In reply to comment #7) > I think calling setText makes the browser load the text asynchronious to the > callee. Maybe delaying the call to setVisible by some milis makes things > better? I've implemented this for the Javadoc hovers (in org.eclipse.jface.internal.text.html.BrowserInformationControl 1.5). We now call setText(..) and then wait for 100ms or until the progressListener gets a "completed" event (whichever happens first). This avoids flickering (tested on WinXP (IE), Linux-GTK (Mozilla), Mac OS X 10.4 (Safari)).
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
