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.
JDK supports multiple monitors since version 1.3. It didn't work then due to bugs in the JVM. In 1.4.0 things have been improved significantly. We should invest some efforts into making owners of multiple monitors happy. The issue was discussed on nbui. Things to remember/consider (pasted from my posting there) - the window manager does a much better job dealing with multiple monitors than we'll ever do. We should not try to replicate its functionality. (Sawfish for example puts some resistance when you drag the frame near the edge of a monitor before let it go over to the second one, instead of resistance we can have "attraction". This behavior is of course configurable). - but even if we don't try to replace the window manager, we still need to know there are multiple monitors. The prime example are dialog boxes. We usually put them on the center of the monitor. If you have two monitors which is combined to create one virtual monitor then.. Okay you know it doesn't look good. Thus dialogs should be centered on a monitor where the current input focus is. But what if the focused frame (editor frame) spans two monitors? For the beginning we can ignore this situation. Which user wants to have such window arrangement? If he wants to suffer, let's him go :-) - there are (at least) two multi-head modes: separate displays (:0.0 and :0.1) and one virtual big screen (Xinerama). The former is not usual (possible?) on Windows. X Window can handle both. Note in Xinerama mode the virtual screen needs not to be contiguous (the layout of the monitors are configurable), there can be holes in the virtual screen. We should also never assume that it's rectangular (one big monitor, one small monitor). Now o two separate displays: since JDK 1.3 (if the bugs were not there) we can _programatically_ place a Frame in any display we want. But these are separate displays (I am talking X Window, don't anything know about Mac). But I quite fear that if we go this route we'll need to partially (at least) re-implement functionalities of a window manager. I'd rather leave it as is. The user can use the second display for debugged app (explicit -display :0.1) or other purposes. o Xinerama, one big virtual screen: the rule of thumb here is "don't span dialog/window/frame/popup cross monitors" unless the user (somehow) explicitly wants it that way. Without the bugs in JVM it's relatively easy for NetBeans to achieve this. Otherwise we'll try our best to set a default position/size of a newly created frame, let the user drag/resize it and _remember_ the bounds of the frame and the monitor where the user placed it. Then all would be fine.
I'll have to add these methods in org.openide.util.Utilities public static GraphicsConfiguration getCurrentGraphicsConfiguration(); public static Rectangle getUsableScreenBounds(GraphicsConfiguration gconf); public static Rectangle getCenterBounds(Dimension componentSize); public static Rectangle getCenterBounds(GraphicsConfiguration gconf, Dimension componentSize); and deprecate Utilities.getScreenSize() A HOWTO document is being written and will be published.
I am not sure that Utilities is the right place to add those methods. Should not these be part of org.openide.windows package for example WindowManager class? Anyway, before adding these methods, it would be nice to know the sample usage and have demo tests. I am looking for the docs to learn more.
WindowManager is not the right place. What I need is a place to hang the static helper methods. org.openide.util.Utilities seems a good candidate. It already contains getScreenSize() [which I am going to deprecate :-)] and a whole lot of platform specific things. Perhaps WindowUtils or WindowUtilities is better named class, but I don't want to invent a new class just for this purpose. I am going to attach a diff for reviews
Created attachment 4829 [details] Diff against org.openide.util.Utilities which adds the new methods
Created attachment 4830 [details] The whole diff to solve this issues
Created attachment 4844 [details] I suggest to start with these (smaller) API changes. They work just on "current" monitor but up to now all usages of the API also care just about current monitor...
implemented in 3.4 dev 20020301
Yup, hard to verify without two monitors ;-) Marking as verified.
Resolved for 3.4.x or earlier, no new info since then -> closing.