Hello, Alexander. Thank you for testing!
> I noticed that a window doesn't move on > setExtendedState(Frame.MAXIMIZED_BOTH) if a window already have > the same size as provided to setMaximizedBounds(). Hmm.. didn’t notice that.. Looks like it’s because we are discarding zoom the size is not going to change. Looks like I should reimplement a fix with unrealizable windows. About #2 - thank you. I’ll update this. With best regards. Petr. 15 апр. 2014 г., в 6:01 после полудня, Alexander Zvegintsev <[email protected]> написал(а): > Hello Petr, > > > #1: > I noticed that a window doesn't move on > setExtendedState(Frame.MAXIMIZED_BOTH) if a window already have > the same size as provided to setMaximizedBounds(). > > Another case: > we successfully maximized a window, its window state is MAXIMIZED_BOTH, > we moved a window, its window state is NORMAL > we trying to maximize it once again, window state becomes MAXIMIZED_BOTH, but > window keeps its location. > > I think, that a user would expect that the window will be moved to its > MaximizedBounds location. > > #2: > > I suggest to place check against javaMaxSize above javaMinSize in AWTWindow.m. > > IIRC, on Windows, Linux and Mac OS X min size native hint is more powerful > than max size. So after applying native hints like > > frame.setMinimumSize(new Dimension(300, 300)); > frame.setMaximumSize(new Dimension(200, 200)); > > the size of a frame will be 300x300 (java currently supports maximum size on > OS X only, but you can check it with any native program). > > And calling > > frame.setMaximizedBounds(new Rectangle(300, 300, 500, 500)); > > will lead to a window with size 200x200, but I expect here 300x300 (anyway I > think that it is a ridiculous case). > > But just moving this checks isn't enough because of #1 (a window has size > same to specified in setMaximizedBounds() and doesn't move). > > > Thanks, > > Alexander. > On 04/15/2014 04:33 PM, Petr Pchelko wrote: >> Hello, AWT Team. >> >> Please review the fix for the issue: >> https://bugs.openjdk.java.net/browse/JDK-7124365 >> The fix is available at: >> http://cr.openjdk.java.net/~pchelko/9/7124365/webrev/ >> >> The implementation is pretty straightforward. >> In native -1 indicates that this bound is not set. Using Integer.MAX_VALUE >> as in Frame’s javadoc isn’t convenient in native code. >> We do not need to worry about bounds that do not fit the screen - Cocoa >> handles it for us. >> But we need to handle the maximum/minimum sizes manually, because these are >> applied before the willUseStandardFrame callback is called. >> The regression test for this exists, it’s being moved from SQE right now. >> I’ll modify it to support Mac as soon as it’s pushed. >> >> Thank you. >> With best regards. Petr. >
