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
