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 <[email protected]> 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 <[email protected]> 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 <[email protected]> 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 >>> >> >> >>
