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.
dev build 200208160100 1) Start Netbeans 2) Maximize window 3) Close Netbeans 4) Restart Netbeans 5) Opening window will be too small (see screenshot) I expect Netbeans to remembers it closing position/size upon shutdown.
Created attachment 7125 [details] Screenshot
There is no problem with Netbeans windows size after restart on Linux and jdk 1.4.1. This bug probably appears only on OS/2.
My guess is that this is JDK specific. Does anyone try to repro this under IBM's JDK 1.3.1?
It also happens at me with IBM JDK 1.3 and 1.3.1 for OS/2. I think it had woked before. (Version 3.3.x)
Is it MDI or SDI mode? Generaly we call MainWindow.getBounds() on exit and save obtained bounds and call MainWindow.setBounds() on startup. I can attach patch with logging what bounds are saved/loaded. I see you use NB dev build, OS/2, IBM JDK 1.3, 1.3.1. Am I right? Please can you check it with patch I prepare?
This is in MDI mode. Attach your patch and I will try it tonight.
I prepared patch with logging and example of my log output. I overwrote MainWindow.setBounds() and MainWindow.reshape() to monitor what bounds are set to main window. I also log what bounds are stored to config file during IDE exit when winsys configuration is saved. You can eventualy modify sources eg. add Thread.dumpStack() to reshape() if you will see some strange bounds assigned to MainWindow. (setBounds() delegates to reshape() -> after every call of setBounds() there is call of reshape())
Note: JDK 1.3.1 does not handle maximized state of JFrame (IDE main window). We just get/set bounds.
Created attachment 7303 [details] Patch for current dev build
Created attachment 7304 [details] Log example
Put patch to lib/patches folder.
Results of running patch on my end: MainWindow.reshape [x=0,y=0,w=0,h=0] MainWindow.setBounds [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=768] MainWindow.doShowWindow CALL OF setBounds [x=-4,y=26,w=1024,h=747] MainWindow.setBounds [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=747] ------------------------------------ WMD.appendMainWindow SAVING MAIN WINDOW BOUNDS [x=-4,y=26,w=1032,h=747] [starting Netbeans a second time] MainWindow.reshape [x=0,y=0,w=0,h=0] MainWindow.setBounds [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=768] MainWindow.doShowWindow CALL OF setBounds [x=-4,y=26,w=1024,h=747] MainWindow.setBounds [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=747] ------------------------------------ WMD.appendMainWindow SAVING MAIN WINDOW BOUNDS [x=-4,y=26,w=1024,h=747] [ end of log ] The problem seems to be with either saving the dimensions to disk or loading them up. As you can see, Netbeans seems to detect the maximized width at w=1032 (odd width btw!) but when it is next started it does not setBounds() to that size.
I sent email with new patch directly to your email gtzabari@netbeans.org. Did you receive it?
Did not get second patch yet, you might want to resend it or attach it to this issue.
Created attachment 7329 [details] Second patch
Output of second patch reads: MainWindow.reshape [x=0,y=0,w=0,h=0] ------------------------------------ WMD.handleMainWindow LOADING MAIN WINDOW BOUNDS [x=-4,y=26,w=1032,h=747] MainWindow.setBounds [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=768] MainWindow.doShowWindow CALL OF setBounds [x=-4,y=26,w=1024,h=747] MainWindow.setBounds [x=-4,y=26,w=1024,h=747] MainWindow.reshape [x=-4,y=26,w=1024,h=747] ------------------------------------ WMD.handleMainWindow LOADING MAIN WINDOW BOUNDS [x=-4,y=26,w=1032,h=747] ------------------------------------ WMD.appendMainWindow SAVING MAIN WINDOW BOUNDS [x=-4,y=26,w=1032,h=747] Looks to me like a bug in the loading routine. It detects the right width (1032) but setBounds to a different value.
Please send me the whole log output to marek.slama@sun.com. I also added Thread.dumpStack() to MainWindow.setBounds() to see where is exactly setBounds called from. I need also call stacks to see it.
I found reason for it: When trunk fixed issue #11837 he added code to fix case when main window size is greater than screen size. It happens also when main window is maximized: Size of main window becomes slightly wider than screen width. If I remove this code it would introduce some other problem - main window would become bigger than sceen size. So I suggest to leave it as it is.
I found reason for it: When Trung fixed issue #11837 he added code to fix case when main window size is greater than screen size. It happens also when main window is maximized: Size of main window becomes slightly wider than screen width. If I remove this code it would introduce some other problem - main window would become bigger than sceen size. So I suggest to leave it as it is.
Marek's suggestions tipped me off to the real problem causing this issue. It has nothing to do with saving/loading the window position. The problem is that when I hit the MAXIMIZED window button, Netbeans maximizes to fill the entire screen *plus* 4 pixels off to the left of the screen. In essence, the entire Netbeans window is shifted 4 pixels beyond the end of screen. Initially this looks to be a bug, but after further investigation I found *all* Java (and maybe some native) apps do this. The reason is quite simple: when maximized, the window borders are placed outside the screen borders. Marek mentioned you have an algorithm checking to see if the window is bigger than the screen size. You should modify that algorithm to check if the window *minus its insets* is bigger than the screen size. In the case of OS/2, the insets (borders) are placed outside the screen which is perfectly alright while the actual window content is 100% visible. My guess is that under OS/2, you have an inset of 2 pixels on the left and an inset of 2 pixels on the right of the screen which is why we're seeing an "off by 4" bug here.
Quoting Marek: ---------------------- It is not clear to me what is right solution. I do not know why maximized frame behaves this way. I do not like such behaviour when size of app window becomes greater than available screen size. I did not want to break something else by some change. It seems it would be good to test simple java app how it behaves and ask AWT/Swing people about details. But as I said I did not do anything from our last contact. -------------------------------- Could we have some followup on this issue from the UI team please? Either send me a testcase to run on my end, or modify your code so it takes insets into account. Thank you.
I will prepare test app.
Ok... this issue is two months old already and there's been no action on it. It's reaching annoyance level and it's very easy to fix. Is Marek still alive or should this issue be moved on to someone else?
AFAIK, Marek is on vacation. He should take care of this when he returns.
Hmm I am again checking it. If I want to use insets of main window I must somehow fix main window bounds during saving because during loading insets are not set yet. I prepared following patch. It fixes stored x,y and width (NOT height). When main window width is approx (in 1 pixel) equal to screen width + insets.left + insets.right it is set set to screen width. When x or y is equal to insets.left it is set to 0. (Not sure about y. Patch logs some output please check it and send me console output.) We will test it on Linux, Solaris, Windows. Actually on my Linux machine with KDE 2.1.1 only x and width is changed (x is set to -4 instead of to 0 and width to 1289 instead of to 1280, y is set to 0 and height to normal screen height minus bottom OS window manager toolbar) by window manager when main window is maximized.
Created attachment 8419 [details] Patch for devbuild
Hi Marek, The method you mentioned sounds like a big hack. I know you cannot read Window insets before it is visible, but that's quite normal. To my understanding, the "proper" way of handling this is: 1) Configure the window assuming insets = 0 2) Add ComponentListener for componentResized (not componentShown!) 3) Display window 4) When the window *actually* shows up, componentResized will be triggered for the first time. Within the event handler, you can *now* read the actual window insets and recalculate the actual position/size you want it to have. 5) Resize the window and remove the event handler as a listener (since we don't need it anymore) I've used that in two of my applications and it works quite well across all platforms. Furthermore, it quite clean. The reason we use componentResized instead of componentShown is that there seems to be a bug in Swing (at least in JDK 1.3) whereby componentShown isn't always called in the right order. (i.e. it is called before the component is really visible and you can't actually make use of the insets) I hope this helps.. PS: I ran Netbeans with your latest patch and (a) Netbeans's width is still 1 pixel too small on the width (b) The window borders show up inside the screen whereas (in OS/2) when you maximize, they are pushed "off-screen". My method (mentioned above) avoids these two issues. Gili
If I understand it correctly I should set bounds of main window after start so that it becomes positioned as if user maximized it. (Eg. in my case x=-4,y=0,w=1289,h=not modified.) The problem is that I do not know when to do it. It should be done only when main window was maximized when IDE was exited. Am I right? How do you detect maximized main window on JDK 1.3?? Am I missing something?
I see one additional problem. I have no way how to detect where is toolbar (OS window manager). It can be anywhere (bottom, top, left, right). How do you solve this? How do you know what bounds to set when you want to mimic maximized state after start? I think it is possible to solve it in JDK 1.4 where getExtendedState/setExtendedState is introduced but not with JDK 1.3. I just tested simple app on Linux with JDK 1.4 and programmatic maximization (frame.setExtendedState(Frame.MAXIMIZED_BOTH) does NOT work. It just maximizes frame verticaly NOT horizontaly. When I press maximize button frame is maximized but getExtendedState returns 4 instead of 6. (MAXIMIZED_BOTH = MAXIMIZED_VERT | MAXIMIZED_HORIZ where VERT is 4, HORIZ is 2. Back to your suggestion: >4) When the window *actually* shows up, componentResized will be >triggered for the first time. Within the event handler, you can >*now* >read the actual window insets and recalculate the actual >position/size you want it to have. How do I know GENERALY what I want to have??? To me it is not so easy as you claim. The problem is interaction between Swing and native window manager which is not fully controlable programmaticaly.
It also means that my fix will not work when OS WM toolbar will not be at bottom.
Ok, I see your problem now.. So I'm changing my proposal: - On shutdown, save the window position/size (regardless of if it is maximized or not) - On startup, restore the window position/size You shouldn't care where the OS toolbar is. The only problem that might occur is if the user moved his toolbar since the last time he started Netbeans but that's not a really big deal. BTW: Check out http://forum.java.sun.com/thread.jsp?forum=57&thread=116814 Comment #6 and #15 look very promising. Looks like you should be able to achieve what you want under both JDK 1.3 and JDK 1.4. If you cannot, just revert to the above new proposal.
*** Issue 29584 has been marked as a duplicate of this issue. ***
*** Issue 33079 has been marked as a duplicate of this issue. ***
Should it not be possible to use the old code for JDK 1.3 and frame.setExtendedState(Frame.MAXIMIZED_BOTH); for JDK1.4? It would be nice to have this regression fixed in IDE version 3.5. It looks really ugly the way it is.
Please see my comment from 2003-01-03 03:21. I tested frame.setExtendedState(Frame.MAXIMIZED_BOTH) but behaviour is strange as described. I just looked at JDK bug database and found http://developer.java.sun.com/developer/bugParade/bugs/4457313.html. It seems there is also bug in KDE I am currently using. (RH 7.1). Soon my desktop OS will be upgraded to RH 8.0. I will check again. Anyway we USE frame.setExtendedState(Frame.MAXIMIZED_BOTH) on JDK 1.4 and getExtendedState(). IF current OS WM behaves correctly it SHOULD work. I mean at least keeping main window maximized after IDE restart. I will attach small test app to test getExtendedState/setExtendedState. It is possible to maximize verticaly, horizontaly and in both directions, normalize and log state returned by getExtendedState. If this works correctly on your OS/WM Netbeans should work correctly too. Test app works ONLY on JDK 1.4!!
Created attachment 10554 [details] Test of Frame.getExtendedState / setExtendedState
See also http://developer.java.sun.com/developer/bugParade/bugs/4464714.html for Windows. Should be fixed in JDK 1.4.2.
Latest evaluation: I checked with JDK 1.4.2 FCS: It works fine on Windows 2000, Linux RH 8.0 with KDE 3.0.3 but NOT on Solaris 8 with CDE. (See http://developer.java.sun.com/developer/bugParade/bugs/4742412.html). In NB we call Frame.setExtendedState()/getExtendedState() (these methods are since JDK 1.4) so it depends how it works on given OS WM. (For example on RH 7.1 with KDE 2.1.1 it does NOT work due to bug in KDE.)
verified in [nb_dev](20030723)