-
-
Notifications
You must be signed in to change notification settings - Fork 268
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
JFrame is not maximized correctly when using custom window decorations #129
Comments
@grimlock81 thx for reporting. I've implemented a fix in master branch. Please give it a try. A side effect of following code, which applies maximized bounds, is that FlatLaf/flatlaf-core/src/main/java/com/formdev/flatlaf/ui/FlatTitlePane.java Lines 264 to 265 in e7ec398
|
@DevCharly Thanks I built a copy locally and confirms that has fixed the problem. However I have discovered a similar issue that happens if the extended state is called before the JFrame is visible. So in my test code swap the last two lines: frame.setVisible(true);
frame.setExtendedState(Frame.MAXIMIZED_BOTH); to frame.setExtendedState(Frame.MAXIMIZED_BOTH);
frame.setVisible(true); What happens in this case is that the windows covers the task bar and the Restore/Maximise button is showing the Maximise icon. Pressing this button does nothing visibly. Only after the window is set to the NORMAL state, either programmatically, double clicking on the title pane, or dragging the title pane downwards does this button behave as expected. |
I had similar code in Substance, and it was causing issues with maximizing frames across multiple screens that had different sizes and resolutions. |
@kirill-grouchnikov and did you find a solution? I've tested the maximizing code only on Windows 10 with two screens (primary 4K, secondary FullHD) at various scaling factors and with various Java versions (8 - 15). The problem was that Java 8 behaves differnt to Java 9-14 on scaled screens. And Java 15+ again is different to previous versions since some scaling issues were fixed in Java 15. There are a lot of comments in the maximizing code that describe the differences: FlatLaf/flatlaf-core/src/main/java/com/formdev/flatlaf/ui/FlatTitlePane.java Lines 446 to 510 in e7ec398
(feel free to copy code to Substance if useful) |
…ly maximizing window before showing window (issue #129)
@grimlock81 many thx. |
Thanks @DevCharly. I'll try this when I get to a two-monitor setup next time - with FlatLaf code, and then porting it to Substance. |
@DevCharly I got the latest changes, rebuilt my local copy, but doesn't seemed to have fixed the problem. |
Found another issue this one rather more serious. Let me first explain my monitor setup. I have 2 monitors:
I launch my test application on the Primary Monitor maximised. I then drag the frame to the Secondary Monitor and press the maximise button. What results is a little hard to describe but it seems to reposition the frame continuously flickering between the two monitors. From what I can discern it loops between setting the location to 0,0 on Secondary Monitor then 0,0 on Primary Monitor then back to the original position on the Secondary Monitor where I had dragged the frame to and then back to 0,0 Secondary Monitor ad infinitum. The size of the frame doesn't change, it will remain the same size. Other info:
Running FlatLaf 0.39-SNAPSHOT on Windows 10 using AdoptOpenJDK 11.0.8. |
@grimlock81 Is scaling used on one of the screens? (see Windows Settings) Looks like that some fixes from Java 15 were backported to AdoptOpenJDK 11.0.8. If you remove the '!' in following line, is the problem gone with AdoptOpenJDK 11.0.8?
|
Neither monitor using scaling. They are both set to "100% (Recommended)"
Yes it works with AdoptOpenJDK 11.0.7.
The problem remains after removing the '!' with AdoptOpenJDK 11.0.8 As another test I tried FlatLaf 0.37 and 0.38 with AdoptOpenJDK 11.0.8. Both had the same behaviour - while the flicking doesn't happen the 'maximised' frame is placed on the Primary Monitor with the dimensions of the Secondary Monitor.
Is it this one? https://bugs.java.com/bugdatabase/view_bug.do?bug_id=8176359 |
…d 13.0.4, which has fixes backported from Java 15 (issue #129)
Yes, and https://bugs.openjdk.java.net/browse/JDK-8176359 and https://bugs.openjdk.java.net/browse/JDK-8231564. The flicker should be fixed with latest commit in master branch. However noticed a new issue with Java 8 - 14 (without above fixes) if the primary screen has smaller resolution than the secondary screen. Then maximizing on the secondary (larger) screen gives the window the size of the primary (smaller) screen. |
…StateListener in case of behavior changes in Java (issue #129)
@DevCharly My work replaced my secondary monitor with a new one that is the same dimensions and resolution so I am unable to repeat the exact same tests I originally had. This is the behaviour I am experiencing now from my tests, using the current master branch:
For
I also have re-tested with the version before the latest commits 38d853b and 5a2c067 and found that the flickering doesn't happen when the resolutions are the same. The default recommended resolutions for both monitors are 1920x1080. When I change my secondary monitor to 1280x1024 and re-run the test, the flickering occurs again. I tried setting the secondary monitor with other resolutions and the flickering still happens, the only exception being if I make the two monitors have the same resolution. e.g. set both to 1280x1024 |
Closing because since FlatLaf 1.1 (native window decorations on Windows 10) this maximizing code is no longer used. |
I've found an issue when using custom window decorations on Windows 10 when programmatically maximizing the JFrame by calling
frame.setExtendedState(Frame.MAXIMIZED_BOTH);
The resulting JFrame's dimensions fits the whole screen including covering the Windows task bar. This is inconsistent with how Windows applications are displayed in Maximized - they don't cover the task bar. The behaviour of subsequent calls to
frame.setExtendedState(Frame.MAXIMIZED_BOTH);
depends on whether the Maximize button (next to the Close button) has been clicked at least once in the same session or not:This is my test code, I am running on AdoptOpenJDK 11.0.7
After looking through FlatTitlePane.java I can understand why the behaviour is correct after pressing the Maximize button, because
frame.setmaximizedBounds(Rectangle)
is called inside themaximize()
method and sets the right dimensions including accounting for the task bar. Does that mean that Windows is incorrectly setting the maximized bounds at the start? Should FlatLAF set the correct maximized bounds at the start to override Windows?The text was updated successfully, but these errors were encountered: