Removed again from trunk and re-opened. A quick test on KDE showed that it worked really badly there. Mouse-grabbing not working, so fullscreen could be scrolled instead and it doesn't even solve the old problem with KDE and the Desktop is still messed up when switching back from fullscreen.
Btw this also got discussed in the mailinglist and was not fixed before because it was already knows from the SDL guys that those problems do exist. I think it's a paramter there - which was the solution proposed on the mailinglist but not yet implemented because we do not have device-specific parameters so far which are needed for this.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
In Supertuxkart grabbing mouse was not needed. I even prefer that mouse is not grabbed because I can use secondary desktop when I have two monitors connected. It's useful i.e. for recording videos, modifying scene in Blender etc.
But you are right, we should look more globally. Maybe we should add functions for enable/disable mouse grabbing.
Problem with KDE desktop after switching back from fullscreen is a totally different issue. This is probably related to vidmode/xrandr functions. You can check if this problem occurs in current STK git. Now we switch resolution in different way, using xrandr. But this is probably not good enough to merge it upstream.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
It can be closed for now because it indeed could cause issues. I was sending fullscreen request and a while after irrlicht was reading window size. It was sometimes reporting size in windowed mode. Now I'm sending the fullscreen request event, and then I'm waiting until I receive information that window manager already changed the window to fullscreen. If you want, just look into Supertuxkart code how it works.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Removed again from trunk and re-opened. A quick test on KDE showed that it worked really badly there. Mouse-grabbing not working, so fullscreen could be scrolled instead and it doesn't even solve the old problem with KDE and the Desktop is still messed up when switching back from fullscreen.
Btw this also got discussed in the mailinglist and was not fixed before because it was already knows from the SDL guys that those problems do exist. I think it's a paramter there - which was the solution proposed on the mailinglist but not yet implemented because we do not have device-specific parameters so far which are needed for this.
In Supertuxkart grabbing mouse was not needed. I even prefer that mouse is not grabbed because I can use secondary desktop when I have two monitors connected. It's useful i.e. for recording videos, modifying scene in Blender etc.
But you are right, we should look more globally. Maybe we should add functions for enable/disable mouse grabbing.
Problem with KDE desktop after switching back from fullscreen is a totally different issue. This is probably related to vidmode/xrandr functions. You can check if this problem occurs in current STK git. Now we switch resolution in different way, using xrandr. But this is probably not good enough to merge it upstream.
I see that we have HasNetWM var in Irrlicht code, so we should clean-up current code - part with "if (netWM)" and existing "initAtoms" method.
It can be closed for now because it indeed could cause issues. I was sending fullscreen request and a while after irrlicht was reading window size. It was sometimes reporting size in windowed mode. Now I'm sending the fullscreen request event, and then I'm waiting until I receive information that window manager already changed the window to fullscreen. If you want, just look into Supertuxkart code how it works.