It does seem to be a common problem with Windows and full screen games so it may take a while for a fix to be found. Until then you can start the game with the "--windowed=1200x800" argument, using a suitable window size, to avoid this problem
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
To emphasize, this is a problem only seen on Windows, and ATM none of the developers are Windows users, so do not expect progress unless someone new contributes a work-around.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hi, I found a simple work around to solve the problem. I don't know if it's a correct solution but it seem to work on Windows and Linux. I put the modify file in attachment.
I believe that will not in a real fullscreen mode but I don't the see any difference.
I make a dependency from the FullScreenFrame to the GUI class to compute the size. I don't know the application enough to determine the right way to break this dependency. I let you choose how to do it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I believe that will not in a real fullscreen mode but I don't the see any difference.
You are right, it is not really in full screen mode. If we want to call it that, we can not leave out the "gd.setFullScreenWindow(this);" line:-). Thanks for the suggestion, but your solution is effectively to create a large fixed sized window. Windowed mode already allows that (and allows resizing).
Apologies for the delay in looking at this. I usually leave GUI issues to other
developers, but they are a bit hard to find ATM.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I was searching for a solution, but its complicated.
According to https://bugs.openjdk.java.net/browse/JDK-6770428 they dont want modal dialogs on a fullscreen window and made some commandline switches enabling it to work unusable.
So one of the things I tried were making all dialogs not modal, but it only prevents the window from minimizing permanently and the desktop is still temporarily blinking through.
It also causes other issues like goto mode getting activated behind dialogs and dialogs not getting focus making, for example, the dialog for shift-moving partial stacks of goods unusable.
I attach the tiny diff for other devs or brave people who still like to try it with those other glitches and maybe tell what else gets broken, until maybe a workaround emulating modality is found.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I found another way of preventing the game from going minimized permanently, but the desktop may sometimes show for a moment.
Downside is you can not Alt+Tab anymore in fullscreen.
Upside is the other issues do not appear.
I'm unsure if its good enough to be pushed to the official git cause of the Alt+Tab problem, therefore I attach it here. It would be nice if you can test it by:
downloading the .patch file
putting it in the folder where your local freecol git is
open a terminal there
using:
git am 0001-Mostly-hide-effect-of-Java-glitch-in-BR-2729.patch
compile it as usual
Last edit: wintertime 2014-12-16
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So one of the things I tried were making all dialogs not modal,
I do not recommend this approach. The choice of non/modal was carefully discussed on the developer list, and we tried hard to only have a minimum number of modal ones (although there were also a few cases which were too hard to change). FreeCol has some questions that are really awkward to defer --- we really do not want a critical dialog to go unanswered while the game proceeds, and then when it finally is answered the response effectively invalidates the changes that were made in the meantime. You have seen some of the confusion that can occur with the goto-mode failures. Believe me, it could get much worse.
I found another way...
Lets hope that works better! I will look at it, but can not comment on effectiveness. In the worst case, we may just have to accept that if the keepers of Java have declared full screen mode and modal dialogs to be mutually exclusive, we will have to stop pretending to support it.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I did think about it some more and the cleanest solution might be switching back from JDialogs to JInternalFrames, but I read in an old thread you dont like that as it gives other problems, and it would take a considerable amount of work anyway.
Then I remember reading a hint that exchanging the JFrame for a JWindow or JDialog might help, but when I tried there were missing methods I would have needed to replace for an unknown chance of making it work.
We could also try to make pretend-modal JDialogs where we tell Swing they are not modal, but then emulate them somehow. Maybe set the dialog to always on top, add/change a fullscreen Glass Pane catching all input and doesn't let it through to any other windows and use some listener again to prevent the dialog from getting deactivated. But that would be a huge hack going through the GUI and large amount of work, then could still give the same or even more problems.
If people can live with the solution with the Listener from yesterday, I would keep it at that for a while. Testing by some Windows users is welcome. ;)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've pushed the fix, since its almost a week, people seem to not find it here and it is an improvement.
The issue needs to stay open though. I'd suggest changing the default to --windowed and adding a --fullscreen option.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, waiting is good. Lets hope we get some people to tell how noticeable the glitch still is in fullscreen, before changing the default to the safer windowed mode.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
If you still have this problem, retry with latest git version. Somehow it does not minimize anymore in fullscreen, even when I disable the mitigation fix (maybe cause of the changes on window frame creation).
Sadly, the video and dialogs behind the fullscreen frame bugs are now there again, on Win 8.1.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
While trying to replicate BR#3018 and BR#3019 I again had the minimization problem with the FreeCol frame in fullscreen on Windows 8.1. The workaround is making it a splitsecond showing of the desktop again (sometimes when a JDialog is opened by the game), so its still helping.
Last edit: wintertime 2017-01-29
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hey there,
using latest nightly and there's an issue with fullscreen again. Activate full screen - splitsecond - fullscreen okay - deactivating full screen - game crash
This was raised in the Forum when 0.11.0 was released. Somehow it has not been logged as a Bug until now. See here https://sourceforge.net/p/freecol/discussion/141201/thread/83e554f8/
It does seem to be a common problem with Windows and full screen games so it may take a while for a fix to be found. Until then you can start the game with the "--windowed=1200x800" argument, using a suitable window size, to avoid this problem
Thanks for adding the pointer Simon.
To emphasize, this is a problem only seen on Windows, and ATM none of the developers are Windows users, so do not expect progress unless someone new contributes a work-around.
Hi, I found a simple work around to solve the problem. I don't know if it's a correct solution but it seem to work on Windows and Linux. I put the modify file in attachment.
I believe that will not in a real fullscreen mode but I don't the see any difference.
I make a dependency from the FullScreenFrame to the GUI class to compute the size. I don't know the application enough to determine the right way to break this dependency. I let you choose how to do it.
You are right, it is not really in full screen mode. If we want to call it that, we can not leave out the "gd.setFullScreenWindow(this);" line:-). Thanks for the suggestion, but your solution is effectively to create a large fixed sized window. Windowed mode already allows that (and allows resizing).
Apologies for the delay in looking at this. I usually leave GUI issues to other
developers, but they are a bit hard to find ATM.
I was searching for a solution, but its complicated.
According to https://bugs.openjdk.java.net/browse/JDK-6770428 they dont want modal dialogs on a fullscreen window and made some commandline switches enabling it to work unusable.
So one of the things I tried were making all dialogs not modal, but it only prevents the window from minimizing permanently and the desktop is still temporarily blinking through.
It also causes other issues like goto mode getting activated behind dialogs and dialogs not getting focus making, for example, the dialog for shift-moving partial stacks of goods unusable.
I attach the tiny diff for other devs or brave people who still like to try it with those other glitches and maybe tell what else gets broken, until maybe a workaround emulating modality is found.
I found another way of preventing the game from going minimized permanently, but the desktop may sometimes show for a moment.
Downside is you can not Alt+Tab anymore in fullscreen.
Upside is the other issues do not appear.
I'm unsure if its good enough to be pushed to the official git cause of the Alt+Tab problem, therefore I attach it here. It would be nice if you can test it by:
git am 0001-Mostly-hide-effect-of-Java-glitch-in-BR-2729.patch
Last edit: wintertime 2014-12-16
I do not recommend this approach. The choice of non/modal was carefully discussed on the developer list, and we tried hard to only have a minimum number of modal ones (although there were also a few cases which were too hard to change). FreeCol has some questions that are really awkward to defer --- we really do not want a critical dialog to go unanswered while the game proceeds, and then when it finally is answered the response effectively invalidates the changes that were made in the meantime. You have seen some of the confusion that can occur with the goto-mode failures. Believe me, it could get much worse.
Lets hope that works better! I will look at it, but can not comment on effectiveness. In the worst case, we may just have to accept that if the keepers of Java have declared full screen mode and modal dialogs to be mutually exclusive, we will have to stop pretending to support it.
I did think about it some more and the cleanest solution might be switching back from JDialogs to JInternalFrames, but I read in an old thread you dont like that as it gives other problems, and it would take a considerable amount of work anyway.
Then I remember reading a hint that exchanging the JFrame for a JWindow or JDialog might help, but when I tried there were missing methods I would have needed to replace for an unknown chance of making it work.
We could also try to make pretend-modal JDialogs where we tell Swing they are not modal, but then emulate them somehow. Maybe set the dialog to always on top, add/change a fullscreen Glass Pane catching all input and doesn't let it through to any other windows and use some listener again to prevent the dialog from getting deactivated. But that would be a huge hack going through the GUI and large amount of work, then could still give the same or even more problems.
If people can live with the solution with the Listener from yesterday, I would keep it at that for a while. Testing by some Windows users is welcome. ;)
AFAICT 0001-Mostly-hide-effect-of-Java-glitch-in-BR-2729.patch does not cause any problem on linux.
I've pushed the fix, since its almost a week, people seem to not find it here and it is an improvement.
The issue needs to stay open though. I'd suggest changing the default to --windowed and adding a --fullscreen option.
I will add --fullscreen soon, and change the default just prior to the next release, unless you advise otherwise.
Yeah, waiting is good. Lets hope we get some people to tell how noticeable the glitch still is in fullscreen, before changing the default to the safer windowed mode.
I also have this problem with 11.3
If you still have this problem, retry with latest git version. Somehow it does not minimize anymore in fullscreen, even when I disable the mitigation fix (maybe cause of the changes on window frame creation).
Sadly, the video and dialogs behind the fullscreen frame bugs are now there again, on Win 8.1.
While trying to replicate BR#3018 and BR#3019 I again had the minimization problem with the FreeCol frame in fullscreen on Windows 8.1. The workaround is making it a splitsecond showing of the desktop again (sometimes when a JDialog is opened by the game), so its still helping.
Last edit: wintertime 2017-01-29
Hey there,
using latest nightly and there's an issue with fullscreen again. Activate full screen - splitsecond - fullscreen okay - deactivating full screen - game crash
attached the log file
freecol: git-20200715 (Revision: 8baaf7a)
OS: Win 10 64bit, Version 1909, Build: 18363.1016
Java version: 1.8.0_211
There is a lot of Work-In-Progress here so I am not surprised there is trouble. However its working for me after git.d063826.
Time has passed. Can anyone reproduce this now?