Re: [i3] GLFW_FLOATING window
Hi Michael, I agree that there are better choices. On a side note, I noticed the other day that Google Hangout screen sharing opens a window to offer ending the screen share session with this very atom. That window definitely needs to float, though it's easy to argue that Chrome is at fault here and should use a more suitable atom. Either way, i3 doesn't claim to support this atom and that alone should cause applications to not rely on it and instead use a more suitable atom. Ingo Sent from TypeMail On Aug 25, 2015, 17:40, at 17:40, Michael Stapelberg mich...@i3wm.org wrote: http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html contains: _NET_WM_STATE_ABOVE indicates that the window should be on top of most windows (see the section called “Stacking order” for details). _NET_WM_STATE_BELOW indicates that the window should be below most windows (see the section called “Stacking order” for details). _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user preferences and should not be used by applications e.g. for drawing attention to their dialogs (the Urgency hint should be used in that case, see the section called “Urgency”). From that, I don’t think using _NET_WM_STATE_ABOVE to make a window floating is the correct way. Taking a step back, why does the window need to be floating at all? i3 deliberately only makes dialog windows floating, and if your window is not a dialog window, it not being floating is working as intended. On Tue, Aug 25, 2015 at 5:21 PM, Kevin J jkev...@umbc.edu wrote: Hi everyone, GLFW has a window creation flag to make a window FLOATING, it uses _NET_WM_STATE_ABOVE to do this in x11_window.c. I have tried adding to the if statement in manage.c and the corresponding xmacro to atoms.xmacro, but it still doesn't open as a floating window. After adding this, GLFW's check in x11_init.c works, it didn't before, so it seems to be registered within i3 correctly, but the xcb_reply_contains_atom(state_reply, A__NET_WM_STATE_ABOVE) check still fails. Any idea why this could be happening? Additionally, if I do get it working, would this be something worthy of submitting? or should GLFW be changed to use something other than the WM_STATE_ABOVE atom to make floating windows? ...although none of the tests used by i3 seem to be the right fit. Thanks, Kevin -- Best regards, Michael
Re: [i3] GLFW_FLOATING window
On Tue, Aug 25, 2015 at 5:53 PM, Kevin J jkev...@umbc.edu wrote: Michael: The reason I want the window to float is if I want a specific resolution for the window (I'm working on an OpenGL project). Especially if the window is Use for_window with floating enable: http://i3wm.org/docs/userguide.html#_arbitrary_commands_for_specific_windows_for_window set to be not user-resizeable, i3 will still resize it to fit it to a tile. Yes, and that’s intentional. You can resize your tiles to show as much of the window content as you need, and application authors should not have a say on how you think arranging your workspace is best. I had read that and thought that maybe that wouldn't be the correct atom to use, but none of the ones i3 uses to determine whether to make a window floating seem correct either (MODAL, DIALOG, UTILITY, TOOLBAR, and SPLASH) Ingo: Thanks, I will look into that once I get back from work. Also instead use a more suitable atom do you know of any that would work? Otherwise should this atom be added to i3's floating window detection? I don’t think it should be added to the floating window detection. In fact, I don’t think the window you are describing should be floating, unless users explicitly set it to floating. On Tue, Aug 25, 2015 at 11:44 AM, Ingo Bürk ad...@airblader.de wrote: Hi Michael, I agree that there are better choices. On a side note, I noticed the other day that Google Hangout screen sharing opens a window to offer ending the screen share session with this very atom. That window definitely needs to float, though it's easy to argue that Chrome is at fault here and should use a more suitable atom. Either way, i3 doesn't claim to support this atom and that alone should cause applications to not rely on it and instead use a more suitable atom. Ingo Sent from TypeMail On Aug 25, 2015, at 17:40, Michael Stapelberg mich...@i3wm.org wrote: http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html contains: _NET_WM_STATE_ABOVE indicates that the window should be on top of most windows (see the section called “Stacking order” for details). _NET_WM_STATE_BELOW indicates that the window should be below most windows (see the section called “Stacking order” for details). _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user preferences and should not be used by applications e.g. for drawing attention to their dialogs (the Urgency hint should be used in that case, see the section called “Urgency”). From that, I don’t think using _NET_WM_STATE_ABOVE to make a window floating is the correct way. Taking a step back, why does the window need to be floating at all? i3 deliberately only makes dialog windows floating, and if your window is not a dialog window, it not being floating is working as intended. On Tue, Aug 25, 2015 at 5:21 PM, Kevin J jkev...@umbc.edu wrote: Hi everyone, GLFW has a window creation flag to make a window FLOATING, it uses _NET_WM_STATE_ABOVE to do this in x11_window.c. I have tried adding to the if statement in manage.c and the corresponding xmacro to atoms.xmacro, but it still doesn't open as a floating window. After adding this, GLFW's check in x11_init.c works, it didn't before, so it seems to be registered within i3 correctly, but the xcb_reply_contains_atom(state_reply, A__NET_WM_STATE_ABOVE) check still fails. Any idea why this could be happening? Additionally, if I do get it working, would this be something worthy of submitting? or should GLFW be changed to use something other than the br WM_STATE_ABOVE atom to make floating windows? ...although none of the tests used by i3 seem to be the right fit. Thanks, Kevin -- Best regards, Michael
Re: [i3] GLFW_FLOATING window
Hi Kevin, Applications generally shouldn't dictate how the window manager has to manage windows. In fact the specs clearly state that the window manager is allowed to deny, allow or modify such requests and that the application needs to deal with that. Also note that if you provide proper information on the window (class or role etc.), any user can make sure that the window will float. As for supporting the atom in i3, I'm all for i3 supporting more of the standards, but we need to find the appropriate way to handle these atoms and fully understand the consequences. It doesn't seem immediately clear to me that such windows must be floated. I think Michael seems to see it similarly. Regards Ingo Sent from TypeMail On Aug 25, 2015, 17:53, at 17:53, Kevin J jkev...@umbc.edu wrote: Michael: The reason I want the window to float is if I want a specific resolution for the window (I'm working on an OpenGL project). Especially if the window is set to be not user-resizeable, i3 will still resize it to fit it to a tile. I had read that and thought that maybe that wouldn't be the correct atom to use, but none of the ones i3 uses to determine whether to make a window floating seem correct either (MODAL, DIALOG, UTILITY, TOOLBAR, and SPLASH) Ingo: Thanks, I will look into that once I get back from work. Also instead use a more suitable atom do you know of any that would work? Otherwise should this atom be added to i3's floating window detection? On Tue, Aug 25, 2015 at 11:44 AM, Ingo Bürk ad...@airblader.de wrote: Hi Michael, I agree that there are better choices. On a side note, I noticed the other day that Google Hangout screen sharing opens a window to offer ending the screen share session with this very atom. That window definitely needs to float, though it's easy to argue that Chrome is at fault here and should use a more suitable atom. Either way, i3 doesn't claim to support this atom and that alone should cause applications to not rely on it and instead use a more suitable atom. Ingo Sent from TypeMail http://www.typeapp.com/r On Aug 25, 2015, at 17:40, Michael Stapelberg mich...@i3wm.org wrote: http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html contains: _NET_WM_STATE_ABOVE indicates that the window should be on top of most windows (see the section called “Stacking order” for details). _NET_WM_STATE_BELOW indicates that the window should be below most windows (see the section called “Stacking order” for details). _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user preferences and should not be used by applications e.g. for drawing attention to their dialogs (the Urgency hint should be used in that case, see the section called “Urgency”). From that, I don’t think using _NET_WM_STATE_ABOVE to make a window floating is the correct way. Taking a step back, why does the window need to be floating at all? i3 deliberately only makes dialog windows floating, and if your window is not a dialog window, it not being floating is working as intended. On Tue, Aug 25, 2015 at 5:21 PM, Kevin J jkev...@umbc.edu wrote: Hi everyone, GLFW has a window creation flag to make a window FLOATING, it uses _NET_WM_STATE_ABOVE to do this in x11_window.c. I have tried adding to the if statement in manage.c and the corresponding xmacro to atoms.xmacro, but it still doesn't open as a floating window. After adding this, GLFW's check in x11_init.c works, it didn't before, so it seems to be registered within i3 correctly, but the xcb_reply_contains_atom(state_reply, A__NET_WM_STATE_ABOVE) check still fails. Any idea why this could be happening? Additionally, if I do get it working, would this be something worthy of submitting? or should GLFW be changed to use something other than the br WM_STATE_ABOVE atom to make floating windows? ...although none of the tests used by i3 seem to be the right fit. Thanks, Kevin
Re: [i3] GLFW_FLOATING window
Hi Kevin, On the bottom of manage.c you also need to increase the number of atoms that i3 lists as supported. Also make sure you added the new atom not at the very end of atoms.xmacro as not all of them are copied into the supported list and GLFW seems to actually check for support. If all of this is correct, it could only be that GLFW only sets the atom after the window is created. In this case you'd have to modify the handler. Regards Ingo Sent from TypeMail On Aug 25, 2015, 17:22, at 17:22, Kevin J jkev...@umbc.edu wrote: Hi everyone, GLFW has a window creation flag to make a window FLOATING, it uses _NET_WM_STATE_ABOVE to do this in x11_window.c https://github.com/glfw/glfw/blob/b69b4a9f2a66159f670c5802d8105db211bfec3d/src/x11_window.c#L350-L357 . I have tried adding to the if statement in manage.c https://github.com/i3/i3/blob/next/src/manage.c#L374-L384 and the corresponding xmacro to atoms.xmacro, but it still doesn't open as a floating window. After adding this, GLFW's check in x11_init.c https://github.com/glfw/glfw/blob/afe4aadade132f088a1d88145baed0b384c8d4e0/src/x11_init.c#L438-L439 works, it didn't before, so it seems to be registered within i3 correctly, but the xcb_reply_contains_atom(state_reply, A__NET_WM_STATE_ABOVE) check still fails. Any idea why this could be happening? Additionally, if I do get it working, would this be something worthy of submitting? or should GLFW be changed to use something other than the WM_STATE_ABOVE atom to make floating windows? ...although none of the tests used by i3 seem to be the right fit. Thanks, Kevin
Re: [i3] GLFW_FLOATING window
http://standards.freedesktop.org/wm-spec/1.3/ar01s05.html contains: _NET_WM_STATE_ABOVE indicates that the window should be on top of most windows (see the section called “Stacking order” for details). _NET_WM_STATE_BELOW indicates that the window should be below most windows (see the section called “Stacking order” for details). _NET_WM_STATE_ABOVE and _NET_WM_STATE_BELOW are mainly meant for user preferences and should not be used by applications e.g. for drawing attention to their dialogs (the Urgency hint should be used in that case, see the section called “Urgency”). From that, I don’t think using _NET_WM_STATE_ABOVE to make a window floating is the correct way. Taking a step back, why does the window need to be floating at all? i3 deliberately only makes dialog windows floating, and if your window is not a dialog window, it not being floating is working as intended. On Tue, Aug 25, 2015 at 5:21 PM, Kevin J jkev...@umbc.edu wrote: Hi everyone, GLFW has a window creation flag to make a window FLOATING, it uses _NET_WM_STATE_ABOVE to do this in x11_window.c. I have tried adding to the if statement in manage.c and the corresponding xmacro to atoms.xmacro, but it still doesn't open as a floating window. After adding this, GLFW's check in x11_init.c works, it didn't before, so it seems to be registered within i3 correctly, but the xcb_reply_contains_atom(state_reply, A__NET_WM_STATE_ABOVE) check still fails. Any idea why this could be happening? Additionally, if I do get it working, would this be something worthy of submitting? or should GLFW be changed to use something other than the WM_STATE_ABOVE atom to make floating windows? ...although none of the tests used by i3 seem to be the right fit. Thanks, Kevin -- Best regards, Michael
