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. ***