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 39394 - Documents area of maximized main window encompasses more and more of screen after every restart under Metacity
Summary: Documents area of maximized main window encompasses more and more of screen a...
Status: VERIFIED DUPLICATE of bug 37280
Alias: None
Product: platform
Classification: Unclassified
Component: Window System (show other bugs)
Version: 3.x
Hardware: PC Linux
: P3 blocker (vote)
Assignee: mslama
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-01-29 23:31 UTC by Jesse Glick
Modified: 2008-12-22 19:54 UTC (History)
3 users (show)

See Also:
Issue Type: DEFECT
Exception Reporter:

Attachments
Log of progressively changed winsys settings (11.20 KB, text/plain)
2004-01-29 23:32 UTC, Jesse Glick 		Details
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2004-01-29 23:31:47 UTC 
I am not sure when this started happening, because
it does *not* happen to me in my normal user
directory, so I did not easily notice - but it
does in a fresh user directory. Broken for at
least a couple of weeks.

I am using dev-040129,
moduleconfig=stable-with-apisupport; JDK 1.4.2_04,
Linux 2.4.20, XFree86 4.3.0, with Metacity window
manager 2.6.3. 1024x768 screen.

If I just start a dev build w/ a fresh user dir,
shutdown, and restart, it seems that window
proportions are left as they were. (There appears
to be a small amount of drift from floating-point
rounding errors, which you should fix somehow, say
by keeping around the integer values from which
the float was originally computed.)

But if I maximize the window (as I almost always
want to do, since on a laptop screen it is
completely unusable otherwise), after every
restart the documents area gets bigger and bigger,
and the Explorer gets narrower and narrower. If I
have the Output Window open too, after every
restart it similarly gets shorter and shorter; the
documents area squeezes everything else out. After
a few restarts, you cannot even see one letter of
the label "Filesystems" any more. You have to keep
on making the Explorer wider and the Output Window
taller, every couple of restarts.

I reproduced this with a fresh user dir and
tracked the critical window system config files
after every shutdown. You can see that while
everything else remains steady, the horizontal
"weight" of the documents area keeps on going up,
and the hor. weight of the explorer mode keeps on
going down.

My guess is that the <joined-properties> of the
<main-window> are nonsense. 819x614 cannot be
right; that is more likely the *original* size
before I maximized it. Probably something is
repeatedly getting computed against this
inaccurate dimension.

No idea if this problem is
window-manager-specific, but I can try to find out.

BTW I often find this in my ~/.xsession-errors,
which is rather suspicious:

Window manager warning: Window 0x2e0003a ( ) sets
an MWM hint indicating it isn't resizable, but
sets min size 1 x 1 and max size 2147483647 x
2147483647; this doesn't make much sense.
Comment 1 Jesse Glick 2004-01-29 23:32:12 UTC 
Created attachment 13152 [details]
Log of progressively changed winsys settings
Comment 2 Jesse Glick 2004-01-29 23:33:18 UTC 
BTW my normal long-time user directory reports

        <joined-properties
             x="0"
             y="0"
             width="1026"
             height="786"
             ...

so maybe that is the difference.
Comment 3 Jesse Glick 2004-01-29 23:40:13 UTC 
Sure enough, if I run using mwm (ancient trivial window manager)
inside a VNC window, the problem does not occur. And
WindowManager.wswmgr reports:

        <joined-properties
             x="0"
             y="0"
             width="1022"
             height="768"
             ...

So perhaps Metacity is misreporting window size or Java is
misinterpreting what it reports. Can anything be done with this?
Comment 4 Jesse Glick 2004-01-29 23:43:33 UTC 
Workaround appears to be to manually edit WindowManager.wswmgr to
specify your screen size.

BTW forgot to mention: the IDE *is* correctly maximized after the restart.
Comment 5 David Simonek 2004-01-30 07:25:38 UTC 
Serialization area, passing to Marek.
Comment 6 _ tboudreau 2004-02-10 15:10:48 UTC 

*** This issue has been marked as a duplicate of 32780 ***
Comment 7 Jesse Glick 2004-02-15 19:57:27 UTC 
Huh? This was marked duplicate of a completely unrelated bug.

Issue #39238 and/or issue #39590 *might* be related, I do not really know.
Comment 8 _ tboudreau 2004-02-15 20:44:45 UTC 
Jesse, there was some kind of cumulative rounding error in window persistence (I 
remember predicting such a thing last summer...).  Milos checked in the fix on friday.  I 
transposed two digits in the issue number, it should have been 37280, not 32780.  Sorry.

*** This issue has been marked as a duplicate of 37280 ***
Comment 9 Jesse Glick 2004-02-15 20:56:01 UTC 
Tim did you read this whole issue before marking it as duplicate? It
might be (I will have to check in a dev build) but I suspect it isn't:
(1) the problem is WM-specific; (2) the drift is much faster than
could be attributed to rounding error; (3) the stored screen size is
completely wrong.
Comment 10 _ tboudreau 2004-02-15 21:14:06 UTC 
You are correct, I closed it too fast.  

I'm not sure what we can do for window managers misreporting things except file bugs 
against them... Blackbox used to have similar problems (generally lots of issues around 
whether window decorations should be part of window dimensions or not - everyone 
seems to go their own way on this).  

Possibly some weird stuff could be done like double checking values against some 
previous similar state, and noticing if they grow or shrink.  Unless the problem's very 
severe, I'm not sure it's worthwhile to inves time in working around window manager 
bugs - I can imagine a fix for one could make things worse on another.

Milos, if you don't want this, assign it back.
Comment 11 Jesse Glick 2004-02-15 21:34:59 UTC 
Yes, I'm also unsure whether it is worthwhile to try to work around
something like this. May just be a transient bug in the WM.
Unfortunately this WM is the default for Fedora Linux now. Hopefully
the bug lies in the combination of the WM and some outdated libraries,
etc., and will not affect thousands of people like it did me...
Comment 12 Milos Kleint 2004-02-16 08:08:17 UTC 
Re: my fix to the window system.
it was not about rounding errors.
the problem is that the Nb window system gives more room for document
area when user resizes the window. That is ok, however this mechanism
kicked in also during restart and the nb wind system handled the
automatic startup window positioning as user request.

For some reason one (JDK/Swing) cannot have a maximized window before
it's visible. On the same note one cannot set split position when the
component is not visible. So these two things were done on startup.
Later a listener for user window manipulation was added.

However swing posts his action on the event queue, which had two
effects. 1. the split was recalculated for the non-maximized value
2. the listener was already added and the maximizing of the window
triggered another recalculation of the split, making it bigger.


apparently - the bigger the difference between the maximized and
normal state of the window, the faster the document area grows.

I've tried with a main window of 100x200 and on my 1600x1200 it grew
FAST. :)

so I think it still can be related to my fix, however it needs to be
tested.
Comment 13 Jesse Glick 2004-02-16 23:01:14 UTC 
Yes Milos I think you're right. At least in a current dev build the
bug seems to be gone for me (though WindowManager.wswmgr still records
the unmaximized size of the main window). Will reopen if I see any
further problems.

*** This issue has been marked as a duplicate of 37280 ***
Comment 14 Milos Kleint 2004-02-17 07:00:31 UTC 
I think that the recording of non-maximized size is correct, otherwise
the original size would be lost and one could not easily restore the
original size.
Comment 15 Jesse Glick 2004-02-17 18:04:05 UTC 
Fine with me, as long as it works...
Comment 16 Marian Mirilovic 2004-02-19 09:04:09 UTC 
verified