Missing _NET_WM_STATE on all windows

[IDiamondcraft]

Output of awesome --version:

awesome v4.3 (Too long) • Compiled against Lua 5.3.6 (running with Lua 5.3) • D-Bus support: ✔ • execinfo support: ✔ • xcb-randr version: 1.6 • LGI version: 0.9.2

How to reproduce the issue:

Actually, I don't know how this happened as I just installed it.

Actual result:

Output of $ xprop _NET_WM_STATE:

_NET_WM_STATE:  not found.

Full output (run $ xprop only):

GDK_TIMESTAMP_PROP(GDK_TIMESTAMP_PROP) = 0x61
_NET_WM_DESKTOP(CARDINAL) = 1
_NET_FRAME_EXTENTS(CARDINAL) = 1, 1, 21, 1
WM_STATE(WM_STATE):
        window state: Normal
        icon window: 0x0
awful.client.property.single_instance_id(UTF8_STRING) = 
_NET_WM_BYPASS_COMPOSITOR(CARDINAL) = 2
WM_HINTS(WM_HINTS):
        Client accepts input or input focus: True
        Initial state is Normal State.
        bitmap id # to use for icon: 0xc0002f
        bitmap id # of mask for icon: 0xc00036
        window id # of group leader: 0xc00001
_GTK_THEME_VARIANT(UTF8_STRING) = 
WM_WINDOW_ROLE(STRING) = "browser"
XdndAware(ATOM) = BITMAP
_NET_WM_OPAQUE_REGION(CARDINAL) = 
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 12582957, 12582958
_NET_WM_USER_TIME(CARDINAL) = 3002582
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xc0002c
WM_CLIENT_LEADER(WINDOW): window id # 0xc00001
_NET_WM_PID(CARDINAL) = 531
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "idiamondcraft"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
        program specified minimum size: 450 by 120
        program specified maximum size: 16384 by 16384
        program specified base size: 450 by 120
        window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Navigator", "firefox"
WM_ICON_NAME(COMPOUND_TEXT) = "awesome window manager · GitHub — Mozilla Firefox"
_NET_WM_ICON_NAME(UTF8_STRING) = "awesome window manager · GitHub — Mozilla Firefox"
WM_NAME(COMPOUND_TEXT) = "awesome window manager · GitHub — Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "awesome window manager · GitHub — Mozilla Firefox"

Note: I purposely didn't copy icon.

Expected result:

xprop return _NET_WM_STATE

[sclu1034]

I don't see anything in the spec that the property has to always exist. I'd assume that a missing value would have the same effect as an empty list.

As for your example, which state should that client have? Based on the other properties, none of the possible states seem to apply.

[IDiamondcraft]

For your first paragraph, if my understanding is correct. It should show the property list (or key. I just call them variable) but the value will be blank like PROPERTY = unless they change it that when it empty, it won't show up.

As for your second question, it should have _NET_WM_STATE_FOCUSED.

[sclu1034]

For your first paragraph, if my understanding is correct. It should show the property list (or key. I just call them variable) but the value will be blank like PROPERTY = unless they change it that when it empty, it won't show up.

No, xprop would still show the values as is (i.e. not show anything when it isn't set), but an application that reads the value for the purpose of doing something with it could run the same logic for both "non-existent" and "empty list".

As for your second question, it should have _NET_WM_STATE_FOCUSED.

That's not a value defined by the spec. Custom, per-implementation values are allowed, but there is no obligation for Awesome to implement any or all of those custom extensions.

[IDiamondcraft]

Alright, so here is what happened. I am reading and searching more on Google and I have no luck finding something to explain me about how EWMH property work. So I just listen to the song to calm myself down and I play my lyric video in fullscreen with MPV. After that I exit fullscreen and try running xprop one last time before I give up and accept it and here is the result: Before fullscreen:

_NET_WM_STATE:  not found.

After exit fullscreen:

_NET_WM_STATE(ATOM) =

Going back to fullscreen:

_NET_WM_STATE(ATOM) = _NET_WM_STATE_FULLSCREEN

So after this I search "_NET_WM_STATE appear after fullscreen" and I found similar issue on leftwm.

Now that I know that _NET_WM_STATE is working as expect. I would like to know if this can be fix? also is it possible to add _NET_WM_STATE_FOCUSED when focus? Oh and BTW I am sorry that I didn't read ewmh.c before. I assume awesome use exactly the same ewmh value as this which have _NET_WM_STATE_FOCUSED.

Also if this sound all over the place. It's is because I'm happy that I see net state and I'm currently listen to the song.

[sclu1034]

same ewmh value as this

Ah, seems that I ended up on a previous version of that spec before. Since 1.5 it does indeed include a _NET_WM_STATE_FOCUSED.

also is it possible to add _NET_WM_STATE_FOCUSED when focus?

Should be possible, yes.

---

So after this I search "_NET_WM_STATE appear after fullscreen" and I found similar issue on https://github.com/leftwm/leftwm/issues/152.

I disagree with the interpretation in that other issue. Nothing in the spec sounds to me like the property must be set at all times, even if it's just an empty list. In contrast, root window properties like _NET_SUPPORTED do have an explicit "This property MUST be set by the Window Manager".

So the fact that MPV starts without that property and only gains it once there is actually a value in the list, looks fine to me.

Now that I know that _NET_WM_STATE is working as expect. I would like to know if this can be fix?

If it's working as expected, what is there to fix?

[IDiamondcraft]

Oh sorry, I forgot that _NET_WM_STATE is auto added when you add the value to it and at that time I'm still thinking about _NET_WM_STATE didn't get added. Also, I guess I'll try adding _NET_WM_STATE_FOCUS tomorrow but still looking forward for implementation of focus value. Thank you so much in advance as I feel so frustrated trying to find out what's going on by searching in Google...

[IDiamondcraft]

So uhh... I been scratching my head for around 3 days already and I still can't apply focus value to focused client until I realize that awesome already have focus detect and can be triggered via config file and in spec it say that window's decorations are drawn in active state not window are focused or not (my bad).

---

So now I tried to add correct way of adding focus value but I can't do that. I try searching and reading other windows manager code to get the idea to implement it but I still don't know how. Maybe you can either guide me or if you agree to add, then you can directly made commit. (Or if you really don't want to then I'll try other way or just leave it like this :) )