This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
(running the trunk build 200404291800 w/ jdk 1.5.0-b48 w/ -J-DuseGtk=true) When you close the files open in the editor, the area of the main window where they were shown is not repainted and you still see the editor there. This happens only if you close the last/all editor(s).
Works fine for me in b56.
trunk build 200406271800 jdk 1.5.0-b57 see the attached screenshot (I closed the editor windows and then clicked on main menu. You can see that the editor area repaints correctly only if you paint something new over it (e.g. the menu) or if you let the whole IDE window repaint (e.g. by minimizing and restoring))
Created attachment 16038 [details] Screenshot
*** Issue 42819 has been marked as a duplicate of this issue. ***
As noted in issue 42819, a duplicate of this one: This is very likely a validation problem in GTK's UI delegate for JSplitPane, but I have not yet tried to isolate it in a test app. I've seen some similar problems in various dialogs that use JSplitPane and change one component on the fly.
Single most annoying problem with GTK mode in current dev builds.
Also could simply be that GTK L&F does not honor setOpaque() - even for custom JComponent subclasses, where in other look and feels it will fill in the background color in ComponentUI if isOpaque is true.
*** Issue 41679 has been marked as a duplicate of this issue. ***
Passing to Martin.
I found the solution. It's really simple. But it has drawback - repainte/revalidate is called every time the EditorView.getEditorAreaComponent() is called which is from time to time. Component should be IMHO repainted/revalidated only when the last editor tab is closed. There is still too much classes in core/windows for me :). So this is just patch for impatient and for those who can help somehow. I will try "new Exception.printStackTrace()" to track those several callees. The temporary(?) patch follows.
Created attachment 18501 [details] half-patch
Anything that frequently calls revalidate() will just mean we trade a painting problem for a performance problem. But I feel your pain, navigating core-windows - it's a little bit like being a rat in a maze.
> it's a little bit like being a rat in a maze exactly :) Maybe, we could called it conditionally only for GTK L&F (as the problem occurs only there - JDK bug?). That's probably not a perfect solution as well. But we could do so anyway with leaving this bug open as this issue makes GTK version really annoying to use. And it shouldn't be a big performance problem as well. What's your opinion? PS: I will be investigating it as my secondary task since it seems it's a JDK bug and GTK is not officialy supported by IDE.
Yes, if you integrate it at all, make it conditional on GTK L&F really being used. I was suspecting the root of the problem had something to do with GTK doing some strange things regarding whether or not components are opaque - i.e., it thinks the split pane is opaque, so it doesn't force a repaint when a component is removed, but the split pane doesn't actually repaint itself either - or something like that. See very similar issue 43024 - I had to add custom painting code to fill in the background of PropertyPanel because it was not automatically filled. Possibly a similar problem with our mode containers? If we can boil this down to a simple test case, it should probably be filed as a JDK bug - what I think is happening is that if you have a custom JComponent or JPanel subclass, and you want it to be opaque (that is, its background should be painted automatically with the background color), GTK L&F will ignore isOpaque, but other L&Fs will honor it. I can believe the JDK team's argument that setOpaque was never meant as a property random code should call on random components, but that is certainly not true if you have a component subclass and you know what it should do. So I suspect that's where the problem is (painting of the mode container), but we'd need to verify it and create a simple test case before filing a JDK bug.
Ok, I will call repaint() method if isGtk and !editorAreaComponent.isValid(). See the patch a confirm, please. Then I will close this as fixed and create new issue (TASK probably) with description and link to this one. It seems there are many bugs in the current GTK implementaion so let's hope it will be fixed soon :) I will be playing with in my free time.
Created attachment 18521 [details] final workaround
If it works, go for it.
Checking in core/windows/src/org/netbeans/core/windows/view/EditorView.java; /cvs/core/windows/src/org/netbeans/core/windows/view/EditorView.java,v <-- EditorView.java new revision: 1.16; previous revision: 1.15 done
This issue was solved long time ago. Because nobody has reopened it neither added comments, we are verifying/closing it now. If you are still able to reproduce the problem, please reopen. Thanks in advance.