FWD » Core Development » User Interface

Was testing Swing client for Hotel GUI. I have 2 monitors. I receive an NPE in p2j.ui.client.gui.driver.swing.SwingEmulatedWindow.getDisplayWorkArea().

   @Override
   public NativeRectangle getDisplayWorkArea()
   {
      synchronized(lock())
      {
         // get the default screen
         GraphicsEnvironment ge = GraphicsEnvironment.getLocalGraphicsEnvironment();
         GraphicsDevice[] devices = ge.getScreenDevices();

         GraphicsConfiguration targetConfig = null;
         Rectangle targetBounds = null;
         if (devices.length == 1)
         {
            targetConfig = devices[0].getDefaultConfiguration();
            targetBounds = targetConfig.getBounds();
         }
         else
         {
            int maxArea = 0;
            Rectangle windowBounds = window.getBounds();
            for (GraphicsDevice device : devices)
            {
               GraphicsConfiguration config = device.getDefaultConfiguration();
               Rectangle bounds = config.getBounds();

               Rectangle intersection = windowBounds.intersection(bounds);
               int area = intersection.width * intersection.height;
               if (area > maxArea)
               {
                  maxArea = area;
                  targetConfig = config;
                  targetBounds = bounds;
               }
            }
         }

         Insets i = window.getToolkit().getScreenInsets(targetConfig);
         // screen insets must be taken into account
         return new NativeRectangle(new NativePoint(targetBounds.x + i.left, targetBounds.y + i.top),
                                    new NativeDimension(targetBounds.width - i.left - i.right,
                                                        targetBounds.height - i.top - i.bottom));
      }
   }

The area is calculated as negative, so the targetConfig is never moved off null. The Rectangle intersection = windowBounds.intersection(bounds); returns with a negative coordinate, so the product is negative.

Roger, while the center point window idea will certainly work in most cases, there will be edge cases, where wrong device will be picked.

Consider a three monitors setup. A window spanning all the three monitors, the center point being in the middle monitor. Even if the center monitor is smaller and the window spans the least area there it would still be picked unexpectedly as the window's device.

I think the greatest window area approach makes the most sense as it always yields the expected result. What do you think?

When using our Swing client, a user would expect that the application will start on the current monitor (regardless of how large it is). This is how the GUI client works in OE.

The method where Roger identified the issues is used in multiple use cases. To illustrate one of the use cases is maximizing a window. If an unmaximized window spans multiple screens maximizing it should make the window take the whole area of a screen it should belong to. The algorithm chooses this screen based on the max area the window occupies on any of the available screens.

This might just be my opinion, but if I am maximizing a window, I'd want it to occupy the monitor which I set as primary.

Roger Borrello wrote:

This might just be my opinion, but if I am maximizing a window, I'd want it to occupy the monitor which I set as primary.

That would be very confusing and bad UX.

Hynek Cihlar wrote:

Roger Borrello wrote:

This might just be my opinion, but if I am maximizing a window, I'd want it to occupy the monitor which I set as primary.

That would be very confusing and bad UX.

Anyway, this is how modern desktops behave (including Windows).

Hynek Cihlar wrote:

Roger Borrello wrote:

This might just be my opinion, but if I am maximizing a window, I'd want it to occupy the monitor which I set as primary.

That would be very confusing and bad UX.

:-) I can be very confused... In reality, with my multi-monitor configuration, if I expanded an application on my secondary monitor, yes, I'd want it to maximize there. It is a compromise to determine where the center point of that window is, versus where the majority of the window is. I am just not smart enough to adjust the coordinates of multiple monitors to make the accurate determination.

Let's avoid the abend. We don't need to make deeper changes.

Roger Borrello wrote:

Greg Shah wrote:

Let's avoid the abend. We don't need to make deeper changes.

I put things back and to avoid the abend by falling back to the primary if the computation cannot determine a proper intersection. Upon testing, no matter the configuration (laptop display primary or external display primary, laptop configured to the left of external display or to the right), we always pop the window on the primary display. Not only that, if I move the initial logon screen from the primary to my secondary and then log into hotel. the main hotel window jumps back to the primary screen. Horrible UX, as Hynek noted.

This is how the native OE apps behave, too, btw. Top-level windows show up at a default location. This would be typically the primary screen or some 0,0 location. In Win32 apps do their window management themselves.

I committed the most minimalist update to prevent the NPE in revision 15675. But there is more to do in this area.

Please create a branch and check in the changes.

Hynek Cihlar wrote:

Please create a branch and check in the changes.

9571a is where I put the revision with the current window's center point as the decider, then replaced with the original version, but initializing the configs to the primary display so no NPE.

Rebased branch to trunk revision 15684 and is at revision 15687.

Rebased branch to trunk revision 15686 and is at revision 15689.

Hynek Cihlar wrote:

Code review 9571a.

The changes look good, just please remove the obsolete history entry "When multiple monitors are in use, the usable area is not being calculated...".

Committed in revision 15692 (and rebased)

Please regression test the changes, Hotel GUI and the customer applications in Swing GUI should be enough.

Testing is completed. We are avoiding the abend.

To go a little deeper, in the case where we are positioning the external monitor to the right of the internal monitor (regardless of which is primary), the UX is poor, because the window positioning is off the viewable screen area, and you have to fish for it with the hotkey to bring up the window controls ("Alt-Space" in my case). This was what I mentioned in #9571-13

Roger Borrello wrote:

To go a little deeper, in the case where we are positioning the external monitor to the right of the internal monitor (regardless of which is primary), the UX is poor, because the window positioning is off the viewable screen area, and you have to fish for it with the hotkey to bring up the window controls ("Alt-Space" in my case). This was what I mentioned in #9571-13

The question is whether OE behaves the same. According to some of my tests, it does.

Hynek Cihlar wrote:

Roger Borrello wrote:

To go a little deeper, in the case where we are positioning the external monitor to the right of the internal monitor (regardless of which is primary), the UX is poor, because the window positioning is off the viewable screen area, and you have to fish for it with the hotkey to bring up the window controls ("Alt-Space" in my case). This was what I mentioned in #9571-13

The question is whether OE behaves the same. According to some of my tests, it does.

That's good to know... the UX is as bad on OE :-)

This has been rebased to the latest trunk.

Code review 9571a, the changes are good.

Rebased branch to trunk revision 15698 and is pushed up to revision 15702.