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 >>>> >>> >>> >>>
