On 7/6/06, Dmitry Timoshkov dmitry@codeweavers.com wrote:
From http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html
"_NET_WM_STATE_FULLSCREEN indicates that the window should fill the entire screen and have no window decorations. Additionally the Window Manager is responsible for restoring the original geometry after a switch from fullscreen back to normal window."
As I understand the above quote it's the WM's responsibility on application's request to remove window decorations and resize a window to fill the screen, then restore its previous state when switching from a fullscreen state.
Yes, if it ever switches to a fullscreen state.
So, all the checks metacity does for window decorations and window size are contradicting the spec IMO.
No, the window would have to be in the fullscreen state in order for checks on window decorations or window size to even have the possibility of breaking the spec. Those checks in src/stack.c were basically meant as a workaround to help legacy applications who don't correctly put themselves into fullscreen mode still get into that mode. Yes, the checks appeared buggy (and we will fix them if I can find some time to verify), but it shouldn't adversely affect any well behaving application.
Also the fact that a window isn't resizeable means only that it's not supposed to be resizeable by a user, still allowing to resize it programmatically.
Feel free to point to anywhere in the ICCCM or EWMH that says so. Of course apps can be resized programmatically -- because the not-resizable hints can be modified programmatically. I disagree with allowing the app or other utilities to modify the size of an unresizable window unless the unresizable'ness is first modified.
My $0.02, Elijah