Expose the WM_NAME property

[ReaperMantis]

Is there any interest in exposing the WM_NAME property?

This is a great library for getting a hold of windows, their properties, and some basic quick controls. It gets me 90% of where I need to be out of the box.

I've got an application that I run that doesn't like to populate the "Title" property. It instead uses the WM_NAME. I've crudely mocked it up to be exposed in a local repository, but for Linux/X11 only. I'm not sure what it would look like on Wayland, Windows, or Mac.

Cheers!

[Kalmat]

Hi!

Don't know which version of PyWinCtl you are using but, except for versions v0.0.45 and v0.0.50 (*), it is already querying _NET_WM_NAME property to retrieve the window title. This includes new version v0.1, so no need to expose/retrieve it in a separate way, but just doing this:

import pywinctl as pwc
win = pwc.getActiveWindow()
print(win.title)

If you are in one of those versions, please upgrade to last version (v0.1) and check if it is OK in your case. If not, please let me know (**).

(*) I was using Xlib's get_wm_name() method in those versions, but it turned out to be returning empty titles in some cases, so I switched to get "_NET_WM_NAME" property to query the window title as you seem to require.
(**) PyWinCtl uses an internal replacement of the (I think abandoned nowadays) pyewmh module. This new package is intended to be a separate, public module as soon as another user and myself are able to finish and deeply test it. You can take a look to it here just in case it can be useful for you in any way. In case you already need this property (or others) to be exposed, I think this other module (ewmhlib) is the right place.

PS: Just for information, Wayland also works using "_NET_WM_NAME" property, but doesn't allow to retrieve the active window nor the list of open windows, so PyWinCtl will not work unless you instantiate Window class using a valid XID (X-Window id). In Windows and macOS, this all is much simpler.

[ReaperMantis]

Sorry, I didnt include any information on what I was using!

KDE Neon 5.27
X11
PyWinCTL v 0.1

I've tried:

import pywinctl as p win = p.getActiveWindow() print("Title:",win.title)

The output is:
Title: None

I check with the debugger and it's None type.

When I go through xlib using self._win.display.create_resource_object('window',self._hWnd).get_wm_name() it will get me the correct window title.

[airtonix]

@Kalmat Also experienced this.

print([
  item.title for item in pywinctl.getAllWindows()
])

# prints ['y', 'm', 'f', 'T', 'Y', 'B' ]

when i expected:

print([
  item._win.display.create_resource_object('window',item._hWnd).get_wm_name() for item in pywinctl.getAllWindows()
])

# prints ['', '', '[email protected] - Mozilla Thunderbird', 'Tracker Tool', '', 'Battle.net']

[ReaperMantis]

Maybe something strange is going on.

I checked ewmhlib.py, and _NET_WM_NAME is indeed there, and that is what's used with the getProperty(Window.NAME).

If I use pip to install pywinctl I get None for the title.
If I use the console attached to my IDE running code directly checked out from this repo, I get the correct title.
If I use pip to install from the code directly checked out from this repo, I get None for the title.

In all cases, if I use self._win.display.create_resource_object('window',self._hWnd).get_wm_name() in pywinctl_linux.py, I always get the correct title.

Maybe my venv has something different than what my system has...

Note: this is only happening for one application. Most other applications always return the title.

[ReaperMantis]

_NET_WM_NAME and WM_NAME appear to be different. It might be the solution to prefer _NET_WM_NAME and fall back on WM_NAME if the former does not return a result.

I added a LEGACY_NAME property to Window in the Prop file, and then in _ewmhlib.py look for Window.NAME, if not available, look for WM_NAME, otherwise None.

That seems like the most elegant solution to what I need, thank you for pointing me in the direction of _ewmhlib.py.

[Kalmat]

Hi! So happy you found a solution!! I will include that fix in my next version too! Just to be sure, can you please paste your code?

Did you manage to clarify what may be happening in your environent when installing PyWinCtl (or other modules) in a different way? (To be honest, I was affraid that I made a mistake when uploading the wheel to PyPi, but inspecting it after downloading, it seems ok!)

Thank you!