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.

Bug 42640 - [GTK L&F] Closed editor window not repainted
Summary: [GTK L&F] Closed editor window not repainted
Status: CLOSED FIXED
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 4.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: Martin Krauskopf
URL:
Keywords: GTK
: 41679 42819 (view as bug list)
Depends on:
Blocks:
 
Reported: 2004-04-30 12:57 UTC by Antonin Nebuzelsky
Modified: 2008-12-23 00:37 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Attachments
Screenshot (114.19 KB, image/png)
2004-06-28 10:49 UTC, Antonin Nebuzelsky
Details
half-patch (676 bytes, patch)
2004-10-25 21:41 UTC, Martin Krauskopf
Details | Diff
final workaround (550 bytes, patch)
2004-10-26 15:25 UTC, Martin Krauskopf
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Antonin Nebuzelsky 2004-04-30 12:57:09 UTC
(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).
Comment 1 _ tboudreau 2004-06-26 23:03:16 UTC
Works fine for me in b56.
Comment 2 Antonin Nebuzelsky 2004-06-28 10:48:20 UTC
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))
Comment 3 Antonin Nebuzelsky 2004-06-28 10:49:01 UTC
Created attachment 16038 [details]
Screenshot
Comment 4 _ tboudreau 2004-07-21 14:23:49 UTC
*** Issue 42819 has been marked as a duplicate of this issue. ***
Comment 5 _ tboudreau 2004-07-21 14:25:09 UTC
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.
Comment 6 Jesse Glick 2004-07-21 18:50:45 UTC
Single most annoying problem with GTK mode in current dev builds.
Comment 7 _ tboudreau 2004-07-25 15:56:31 UTC
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.
Comment 8 _ tboudreau 2004-07-25 17:02:53 UTC
*** Issue 41679 has been marked as a duplicate of this issue. ***
Comment 9 David Simonek 2004-10-21 14:16:35 UTC
Passing to Martin.
Comment 10 Martin Krauskopf 2004-10-25 21:40:26 UTC
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.
Comment 11 Martin Krauskopf 2004-10-25 21:41:25 UTC
Created attachment 18501 [details]
half-patch
Comment 12 _ tboudreau 2004-10-26 10:07:18 UTC
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.
Comment 13 Martin Krauskopf 2004-10-26 10:22:33 UTC
> 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.
Comment 14 _ tboudreau 2004-10-26 10:40:55 UTC
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.
Comment 15 Martin Krauskopf 2004-10-26 15:25:06 UTC
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.
Comment 16 Martin Krauskopf 2004-10-26 15:25:46 UTC
Created attachment 18521 [details]
final workaround
Comment 17 _ tboudreau 2004-10-26 16:20:10 UTC
If it works, go for it.
Comment 18 Martin Krauskopf 2004-10-26 16:29:30 UTC
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
Comment 19 Marian Mirilovic 2005-12-20 15:47:57 UTC
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.