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 20882 - Make NetBeans work smoothly with multiple monitors (Xinerama mode)
Summary: Make NetBeans work smoothly with multiple monitors (Xinerama mode)
Alias: None
Product: platform
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC All
: P2 blocker (vote)
Assignee: _ ttran
Keywords: API, UI
Depends on:
Reported: 2002-02-26 09:34 UTC by _ ttran
Modified: 2008-12-23 13:48 UTC (History)
2 users (show)

See Also:
Exception Reporter:

Diff against org.openide.util.Utilities which adds the new methods (7.19 KB, patch)
2002-02-26 16:46 UTC, _ ttran
Details | Diff
The whole diff to solve this issues (49.33 KB, patch)
2002-02-26 17:45 UTC, _ ttran
Details | Diff
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... (7.63 KB, patch)
2002-02-27 15:13 UTC, Jaroslav Tulach
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description _ ttran 2002-02-26 09:34:15 UTC
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.
Comment 1 _ ttran 2002-02-26 10:58:28 UTC
I'll have to add these methods in org.openide.util.Utilities

public static GraphicsConfiguration getCurrentGraphicsConfiguration();
public static Rectangle getUsableScreenBounds(GraphicsConfiguration
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.
Comment 2 Jaroslav Tulach 2002-02-26 13:16:40 UTC
I am not sure that Utilities is the right place to add those methods.
Should not these be part of 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
Comment 3 _ ttran 2002-02-26 16:44:56 UTC
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
Comment 4 _ ttran 2002-02-26 16:46:26 UTC
Created attachment 4829 [details]
Diff against org.openide.util.Utilities which adds the new methods
Comment 5 _ ttran 2002-02-26 17:45:27 UTC
Created attachment 4830 [details]
The whole diff to solve this issues
Comment 6 Jaroslav Tulach 2002-02-27 15:13:11 UTC
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...
Comment 7 _ ttran 2002-03-01 12:58:57 UTC
implemented in 3.4 dev 20020301
Comment 8 Jan Zajicek 2002-03-21 17:06:34 UTC
Yup, hard to verify without two monitors ;-) Marking as verified.
Comment 9 Quality Engineering 2003-07-01 16:18:45 UTC
Resolved for 3.4.x or earlier, no new info since then -> closing.