Re: [i3] GLFW_FLOATING window

[Michael Stapelberg]

On Tue, Aug 25, 2015 at 5:53 PM, Kevin J  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  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  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  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

[Ingo Bürk]

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

[Kevin J]

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

[Ingo Bürk]

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

[Ingo Bürk]

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

Re: [i3] GLFW_FLOATING window

[Michael Stapelberg]

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

[i3] GLFW_FLOATING window

[Kevin J]

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