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:

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

Reply via email to