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.
I installed 6.5 (running under Sun's JDK 1.6.0_02 on Windows XP) this morning and set about configuring it for working on various projects. In a new java application project I was setting up, I added a few libraries to the compile path. I changed the platform to JDK 1.4 (accepting the request to automatically change the source version) and worked on it a bit, moving files around, adding stuff to source control etc. I've no idea what might have caused the problem, but when I came to add some additional libraries to the runtime path, I found that the relevant buttons were not displayed in the project properties window. Instead, a couple of scrollbars had appeared and I had to drag some way across to be able to see them. Clicking around the other categories, I found that they all behaved the same way. Eventually, I discovered that somehow the values in ${user.home}\config\Preferences\org\netbeans\modules\projectuiapi.properties have been set to CustomizerPane.dialog.height=2000 CustomizerPane.dialog.width=2000 so it's not surprising it doesn't fit on my 1024x768 screen... Upon deleting projectuiapi.properties and restarting the IDE, the file was recreated with height=447 & width=561, which looks much better. Unfortunately, as I said, I've no idea what might have caused the values to change to 2000 in the first place. I may well have resized one or more of the windows/dialogs while editing the settings, but certainly nowhere near that size. So I'm afraid a reproduceable test case is unlikely, but I thought it worth raising the issue just in case somebody can think of something obvious.
Reassigning to projects.
Some further progress - I think I've tracked down the problem. On flicking through the various categories in the project properties window, everything was fine until I selected the Monitoring and Management category (which I believe is added by the JMX or JConsole plugin). As soon as I did, the window resized itself to be mostly off-screen, even though it doesn't need to be anything like that big to fit the included controls, and when I look at the projectuiapi.properties file again the values are back to 2000.
This is can be easily reproduced for me, too, on Ubuntu (8.04, 2.6.24-22), jdk1.6.0_10 and jdk1.5.0_16, regardless if using native or Metal LAF. To reproduce: * open proprerties on an Ant project, * click on anything... * but when clicking on "Monitoring and Management", the properties window is resized (very large, full screen). * resize the properties smaller, * then click on *any* option ("Source", "Libraries", "Spring Framework", "Build", etc) and the window will resize again (full screen). * Close the properties, and reopen the properties, and NOW you have the big, big scrollbars, and a practically unusable properties. (I have to scroll over about 2 or 3 times the width of my screen). Deleting the properties or editing the width/heigth in the following file does work to restore things: $ cat ~/.netbeans/6.5/config/Preferences/org/netbeans/modules/projectuiapi.properties #Fri Dec 12 01:25:54 PST 2008 CustomizerPane.dialog.height=2000 CustomizerPane.dialog.width=2000 You have to restart netbeans to make the settings take effect if deleting the file (just closing the project does not do it.) Workaround: Don't click on Monitoring and Management.
Have the same problem but for me its not related to "Monitoring and Management". It seems the window gets larger the moment I enter a long argument string under "Run" into the "VM Options". So if you have a project with a long VM Options string the steps to reproduce are as follows. Close NetBeans Delete the projectuiapi.properties file Start NetBeans Goto Project Properties => The window now has its normal size Click on Run => Window expands to the width required to accommodate the VM Options string Resize Window down Click on any other category => Window goes back to the large size
Encountered this too. I seem to get the problem when I access the Run properties. Deleting the file solves the problem, until I click on the Project Properties>Run category again.
BTW, Eclipse uses multi-line scrollable text fields for program arguments and VM options and not single line text boxes. This seems to me a better and more useable solution and there is plenty of unused vertical space available in the current Project Properties / Run dialog window.
Created attachment 75165 [details] Screenshot of wide project window
Created attachment 75166 [details] Another sample this time with a horizontal scrollbar
Well, for those arguments, even if they are not made into multi-line fields, those values should not resize the dialog. That is just not good. I just made it happen with the run arguments and any other textfield seems to do this. The text should just be set and that be it. I was trying to find the code actually performing this resize, but it is like a needle in a hay stack, but it has to happen after the OK button is pressed, so I'm going to try to debug into it to see if I can pinpoint the exact code that does it. There is at least an entry point nbsources\projectuiapi\src\org\netbeans\modules\project\uiapi\CustomizerDialog. Surely this is something just looping and checking those things some where in one location versus each view provider individually. Seems like the only thing which should dictate a grow in the size of the dialog is the users themselves actually widening the dialog.
Created attachment 75176 [details] Screenshot attached, as requested by wade
I got the same report of "Monitoring and Management" from Japanese community member.
OK. I've figured it out. It is related to a couple things (its worse for multiple monitor support...virtual desktop size). The affected class is org.netbeans.modules.project.uiapi.CustomizerPane: 1) It is known in the code that a max width and height is needed. It is taking the preferred size and trying to change it on getPreferredSize, but this isn't working as the preferred size is set when a given category is shown, and apparently the preferred size is not being used as the source author intended. i.e. getPreferredSize is apparently not being called, but instead the component is being resized internally some where from this information as soon as setPreferredSize is called versus what ever using it turning around and calling getPreferredSize again. Too, in getPreferredSize the maximums are used, so if the width or height is bigger than the screen size then the sizes are changed to fit, but in setCategory they are not reused (max width and height), so the wrong values are persisted. 2) On multiple monitor supporting systems what makes this worse is that getToolkit().getScreenSize() is used, so the size is always bigger than a specific view port or monitor within the virtual desktop size which the monitors/screens reside. To fix it on my system I've change this to use getGraphicsConfiguration().getBounds() as it is multi monitor aware. It changes per the monitor the NB window is on. 3) On setting the category, and technically setPreferredSize needs overridden to take care of this as well in case setCategory can be passed over, I'm using the maximum values now. I need to change this though to not use statics. A static value doesn't make sense for a window or dialog size because those things can be on dynamic monitors. 4) This issue raised another flag for me, so I'm going to look over all the NB code to see where the wrong code is used whether it be statics for the size or getScreenSize() being used instead of the multi monitor supporting GraphicsConfiguration. Anyways, I'll submit a patch some time later today or early tomorrow. I have some things to do right now. Then later I'll run a search over the entire repository to see how bad it is. Maybe this is the only place this is done. I don't usually have multi monitor issues in NB.
OK, so I had to rework it; what I had worked for a while, but then something went wrong. The plus is it made me look at getPreferredSize during debug and not make an assumption. getPreferredSize wasn't working because the path to be called to limit based on a maximum size wasn't being reached, and a different preferred size was being returned which was larger than the area and made the scroll bars appear. Fabrizio made a comment on the mailing list about the scroll bars and them being good for smaller screens. I'll try to rework it to fit better on those screens. Too, one thing I'm noticing is that with this logic that if the user resizes the dialog then clicking on a category will resize the dialog smaller than what they had resized it to. So, I'm trying to make that work better now as well. Might take a little longer on the patch; what I have now works well, but I need to think more on smaller screens, and some other way of acting if the resolution is less than say 800x600 on the given window on which NB is running. Too, the thing with resizing the dialog is a little annoying to me. I don't know. I guess I can put the patch up, and then we can talk about it and the way it acts. Maybe some others can try it out too to see how it works on their systems.
I'll work up a patch sometime in the next couple days. There are many different variables at play with the resizing. We have a pane, inside a panel, inside a dialog. Inside of all that we have project customizer panels. All the different pieces are contributing to the size, but we have mainly the pane to control sizing, though we do have access to the different pieces from the hierarchy and we have the main panel and other classes. Anyways, the version of this file which I'm working on added this resizing support, so I need to track down the issue that change was tracked and figure out why it was changed and see the design decisions that went into it. Obviously the way it is working now isn't right, but I want to understand the overall issue better. For instance, I understand that given a specific customizer resizing needs to happen, but if that customizer is larger than the screen then that doesn't do much good except for those small screens I wrote about earlier. So, what issues, besides only that resizing, was the previous fix trying to address etc.
I found issue 101501 which is where this issue arose. Seems to me a better solution is for the dialog to be resizable, and to be pretty much as large as it can be while still remaining a dialog. Too, probably it should not resize at all based on the preferred sizes of the customizer panels. This seems to be part of the issue. We know we don't want the window bigger than the monitor area, unless of course the user has a virtual display configured to work as one giant monitor across multiple ones (this is different than multiple monitors with each acting independent). Anyways, to me the better fix isn't to try to deal with maximum sizes, possible incorrect preferred sizes set by customizers, and the like, but to instead use the dialog itself to control that sizing. If the dialog is nearly as big as it can possibly be this should also work for issue 101501. Any comments or ideas?
Another facet of having the dialog control this and using the multi monitor support to get it to a reasonable large size for the users display is the user can then resize it further if needed, but the dialog can't make itself larger than the users actual screen size. If someone else is working on this and assigned to it the way to determine the max size of the actual current screen for multiple monitor support is: private static double maxRatio = 4.0 / 5.0; /** * Method to calculate the maximum dimension the customizers need to be per the screen the dialog * should reside. * @return the max dimension to use in checking and setting the preferred size */ private static final Dimension calcMaxDimension() { Dimension ret = new Dimension(); GraphicsConfiguration gc = WindowManager.getDefault().getMainWindow().getGraphicsConfiguration(); ret.width = (int) (gc.getBounds().width * maxRatio); ret.height = (int) (gc.getBounds().height * maxRatio); return ret; } Seems that needs to be setting the size of the dialog, it not be packed, and some of the other stuff the code is currently doing with regard to maximum preferred size shouldn't be happening. The max ratio can be changed to get a finer and finder sizing strategy.
*** Issue 153250 has been marked as a duplicate of this issue. ***
*** Issue 156232 has been marked as a duplicate of this issue. ***
*** Issue 155852 has been marked as a duplicate of this issue. ***
Marku, please take a look at this issue. Thanks.
I looked at this and I see 2 problems. Please correct me if I am wrong: 1.Properties dialog is resized over screen size as I see from attached screenshots. I am not able to reproduce this on Linux with GTK/Metal JDK 6u12. For me screen width (1600) is limit and dialog width does not get over this limit/ Is there was how to reproduce this on single monitor config? 2.Properties dialog resizes back to previous size even if user resizes it to new custom size. Probably it could be solved by listening on dialog size events so that I can distinguish between dialog size set automatically and set explicitly by user. But it could break automatic resizing (issue #101501). As I understand dialog is automatically resized up (size is increased) during runtime when any inner component - customizer returns bigger preferred size than to fit into current dialog size. I could try to add check to resizing to avoid size increase over current screen size. There is called pack() on dialog. It should take screen size limits into account I think. Anyway I need some way how to reproduce dialog size overflow so that I can test possible fix.
I have to add: I put long string to VM Options on Run category customizer. Even if customizer returns bigger preferred width (2216) after window pack window width fits into screen width (1600) so that dialog does not overflow out of screen.
Did you not get scrollbars in the dialog? If so, did you not find those to impact the usability of the dialog? That is a big usability no no; even on web pages which one would expect to be more friendly to that type scrolling than a desktop application. Too, the text fields are designed the way they are for a reason. That way they are navigable with the keyboard and mouse versus having to show *all* of their information as they can get quite large. If you did not, then I don't know what the difference is except for maybe the underlying libraries and the different X setups etc. Also, if you look at the source code you will see it is calling Toolkit.getScreenSize(). Read the Javadocs for that. Read the docs for GraphicsConfiguration. One is multiple monitor aware, and the other is not. The default screen on a multiple monitor Linux system is the virtual size; too, if it were the main monitor even that the size is getting returned, what if the main monitor is 1680x1050 and the other is 1440x900? Think about what happens when a static is used to hold the window size and the dialog is opened on the 1440x900 monitor versus the 1680x1050. Now, if this goes by the dialog size the user has given it, then that would be OK as they may want to scale it over their monitors. I'll add some screen shots for different things. The first one has all the information, and even shows what is returned on my system from Toolkit.getScreenSize(). Too, notice that on my largest monitor the dialog has scrollbars in it. GraphicsConfiguration can help with that, but still if the dialog is in control of things that will help with it all I think. The user can then set it up how they need. If those sizes are kept and the Window is not packed then the user doesn't have to resize it every time they run it. To get it to behave this way on Linux you can probably go into your xorg.conf file and make it xrandr aware, basically by not defining a bunch of stuff there, and give it a virtual size of something larger than your single monitor. My xorg.conf file monitor and screen sections: Section "Monitor" Identifier "Monitor0" EndSection Section "Monitor" Identifier "Monitor1" Option "RightOf" "Monitor0" EndSection Section "Device" Identifier "Card0" Driver "intel" VendorName "Intel Corporation" BoardName "Mobile 945GM/GMS, 943/940GML Express Integrated Graphics Controller" BusID "PCI:0:2:0" Option "monitor-LVDS" "Monitor0" Option "monitor-VGA" "Monitor1" EndSection Section "Screen" Identifier "Screen0" Device "Card0" Monitor "Monitor0" DefaultDepth 24 SubSection "Display" Viewport 0 0 Depth 24 Virtual 3120 1050 EndSubSection EndSection Now,the funny thing is that on my system it once worked the way you described on my largest monitor. But then, as soon as I opened it on my smaller one it was larger than the screen. Then, as the max is not dynamically calculated or the dialog keeping the size the user sets it too it could not be fixed by me as a user through the IDE by correcting the dialog size. The preferred sizes should have this impact once pack is taken off. If a given panel needs to have scrollbars then it seems the customizer designers should put those in manually and inside their customizer. That gives the user control. I'll attach screen shots next.
Also, I have made this happen on Linux and Windows.
Created attachment 75507 [details] Notice all the things in this screen. Project with the call and the output and the screen size and dialog size.
Created attachment 75508 [details] In this one I have stretched the dialog over both monitors. Together they are not larger than the max resolution/virtual resolution width.
I do not get scrollbars in dialog. I will try to experiment with dual monitor configuration. (I have one now but it is broken somehow as I cannot get mouse to smaller screen.)
Sometimes those scrollbars don't show up until you close the dialog then reopen it. Sometimes it takes clicking around on other panels to get it to happen. Also, if you have the dialog open and it spans your monitor, then maybe resize it smaller and then it OK. See if that can make you get the scroll bars. I have consistently made it get the scrollbars on 4 different computers running openSuSE 11.0, 11.1, Windows XP Home, and Windows XP Professional using different JDKs and everything I can think of.
Well, on Linux I have not tried with a system which doesn't have multi-monitor support setup. Windows is always multi-monitor capable whether you have more than one or not. Linux you generally have to set it up first.
I tried to put upper limit (75% of gc size) on inner customizer panel. This way current resizing still works but only up to certain upper limit depending on available screen size. This way customizer should alway fit into properties dialog ie. properties dialog can be alway resized (by pack) so that no scrollbars are necessary. I attach patch. Please can you test it? (Or I can commit patch to trunk so you can get patched build directly. Let me know what you prefer.) It does not fix problem with automatic resizing when changing category after user resizes dialog window. This must be handled separately. (Problem is that dialog and customizer are completely separated in different modules so this will introduce some API as dialog must track if it was resized by user and let customizer panel know not to call Window.pack() after user customized dialog size.) We will see if this will be necessary after this fix.
Created attachment 75588 [details] Patch to limit customizer maximum size
Some things on pack: 1) CustomizerPane has this code: if (customizerPanel != null) { Window window = SwingUtilities.getWindowAncestor(customizerPanel); if (window != null) { window.pack(); } } which can be removed. 2) CustomizerDialog is used to create the dialog. While it isn't a dialog itself, we could change DialogDisplayer to allow for a class or instance to be passed to it which extends Dialog. Then, we can make a sub class of JDialog which overrides pack so that super.pack is never called. Essentially a no-op. So instead of: Dialog dialog = DialogDisplayer.getDefault().createDialog( dialogDescriptor ); the logic could call: Dialog dialog = DialogDisplayer.getDefault().createDialog( dialogDescriptor, CustomizerDialog.CustomDialog.class ); or Dialog dialog = DialogDisplayer.getDefault().createDialog( dialogDescriptor, customDialogInstance ); and the DialogDisplayer uses that instance to do some things differently. That then keeps customizers from packing the entire dialog and messing things up. What do you think?
Tried out the patch. window.setLocationRelativeTo(null); needs to be window.setLocationRelativeTo(WindowManager.getDefault().getMainWindow()); otherwise the dialog will wind up on the main display. So, if I have the window moved to the other monitor, the dialog opens fine. Then if I click on a category it jumps to the other window. Also, there is something else going on that I'm trying to track down. When I first open it things are fine, but for some reason pack isn't working right any more. I get the scrollbars every time even though the customizer or the panel are not too large for the monitor. Basically the dialog isn't packing and then expanding to fit the preferred size. It worked fine for a little while until I moved it onto my other monitor. Now the dialog is a funny size even though the inner panels are the right size to fit the screen. I'll report more when I figure it out.
Just an FYI I meant to include before. In most cases, the operations that can take a null component will wind up using the default window which is an invisible frame on the screen. This is the parent of a dialog without a parent etc. It is always on the main display, and this is why the behavior is the way it is when null is used in different calls where a window/frame would be operated on.
Pack on window/dialog is done when category ie. customizer panel (right part of dialog) is changed. Pack makes sure window is resized (ie. size is increased) if necessary ie. when any customizer has bigger preferred size. When dialog is opened always first category is selected. Maximum preferred of all so far displayed customizers is kept so that dialog is resized onlywhen bigger customizer panel is displayed for the first time. (Otherwise resizing would be done more often.) Without pack dialog is not resized. To get the same functionality without calling pack we would have to paint all customizers offscreen to get necessary maximum size but it would be performance problem. I will fix setLocationRelativeTo.
I know what pack is doing with the categories. The reason I'm talking about removing pack is to allow the user to keep the size of the dialog. Essentially if the user resized the dialog themselves, and the IDE kept that, then it would not matter. The user would be in control. Too, other issues would be taken care of. Even if the dialog is too big if they had it on a different monitor then it would not matter. I was looking into: 1) Keep the size of the dialog the user sets. 2) On IDE restart, if the dialog size is bigger than the current monitor, then resize it to fit. Then it stays the size the user has set in most cases, and in all cases while the IDE is running. If a particular customizer needs to have scrollbars for some reason, say it is an RCP application for changing system settings such as the resolution and laying out an XWindows installation, then the particular module owner can give that panel those things, and if their users don't like it they can deal with it.
Meaning the individual module owners can deal with fixing those things for their particular users.
I thought about using client property for CustomizerPane. If this property would be set pack on dialog would not be set. Problem is that there are separate dialogs for every project type so it is at more places/modules. Do you think it makes sense to remember custom (user set) dialog size across IDE sessions?
Yes, I think it makes sense to keep that state across sessions. The only thing with that is that the first time the dialog is opened after the IDE starts it should probably check the monitor size for a max size. Same as now except for the entire dialog, so the entire monitor size is the max size versus 3/4ths or .75. During the IDE run, if the user has resized the window larger than the single monitor that is OK as that is what the user did. They may be spanning multiple monitors with that dialog. So it needs that extra check on startup as the user may have closed the IDE, changed monitors, think laptop where the user hooks up different monitors at different locations etc, and then restarted it. Now, there are edge cases where the user may have hibernated or simply changed resolution etc, but if it keeps the size it will remain if they resize it.
I just tested window.setLocationRelativeTo(WindowManager.getDefault().getMainWindow()); There is problem: If main window is not centered new dialog position is not centered either. Because first position of dialog is centered I do not want to move it to any side. Even if dialog is resized it should stay centered on current display. I use window.setBounds(org.openide.util.Utilities.findCenterBounds(window.getSize())); It should work fine on multidisplay environment. Please test. I am just going to commit fix. I will file separate issue to avoid resizing of dialog when user sets dialog size.
core-main #2cef8857d873 To stop automatic dialog resizing when user sets custom dialog size I filed issue #156689.
I'll try out the code. Thanks. I have added some comments to the new issue about dialog size and the user setting it. If anyone on this issues CC list is interested in being able to set the dialog size and it remain the size you set it to, you should check out issue 156689. I personally would prefer it remain the size we set it to as users.
Integrated into 'main-golden', will be available in build *200901140201* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/2cef8857d873 User: Marek Slama <mslama@netbeans.org> Log: #153877: Limit size of inner customizer panel to avoid too big inner area in dialog and scrollbars.
*** Issue 140484 has been marked as a duplicate of this issue. ***
too late for nomination - moving to 6.5 fixes 4
The status whiteboard "65fixes4-candidate" has been removed. At this time our proactive patches for the NetBeans 6.5.x IDE have concluded. If you own a Sun service plan contract for NetBeans, you may wish to contact Sun Service http://www.sun.com/contact/support.jsp to request a fix via the product defect escalation process. For more information on purchasing a Sun service plan contract for NetBeans, refer to the service plan item "Sun Software Service Plans (S3P) for Developers" in the Sun Service table found on our NetBeans Support Resources page http://www.netbeans.org/kb/support.html
*** Issue 163007 has been marked as a duplicate of this issue. ***
*** Issue 163543 has been marked as a duplicate of this issue. ***