pfw returns window ID not present in list returned by lsw.

[MusorGaming]

lsw returns:

0x01800020 0x015bb79a 0x01565393 0x0152d2de 0x01408113 0x015b8a07 0x015dc544 0x0153ec80 0x01600003

pfw returns:

0x00c08d50

which is not in the list.

Calling wattr xywh $(pfw) returns -1 -1 1 1 or some other gibberish.

Calling lsw | xargs -L1 wattr xywh and moving the window around confirmed that the real focused window is in the list returned by lsw:

0 0 2560 1600 278 706 1282 813 161 506 1282 533 1613 338 853 813 612 189 1896 1576 83 93 897 533 334 506 897 533 688 303 831 1033 0 1576 2560 24

[lwilletts]

Are you sure you have focused a window with wtf before using pfw?

[MusorGaming]

I do not call wtf. Do you have to call wtf explicitly for pfw to return correct values?

But I'm sure the window has focus (well, one of the windows must have focus) - so one of the IDs in lsw should match the ID returned by pfw no matter what.

That would only make sense.

[lwilletts]

Just clicking on a window will not give it window focus under the X protocol. Focusing a window with wtf is needed beforehand using pfw else it will return gibberish. I am presuming you're using wmutils on it's own without another window manager here.

[MusorGaming]

@wildefyr is there a way to get the ID of the active window to use in conjunction with wattr without calling wtf? I tried to use xdotool getactivewindow (converting the ID to hex) but the IDs still do not match to the ones from lsw for some reason.

[MusorGaming]

I do use a window manager however. I find the overall wmutils API/interface to be very well designed compared to other command line tools that interface with X window system. I wish I could keep using it.

[lwilletts]

Well, wmutils wasn't designed to be used with window managers, especially ones that use EWMH. You can get away with it for lightweight ones like swm and the like, but wmutils is about building your own experience.

[z3bra]

It is most likely that you are using a reparenting WM, which is not supported by wmutils. You might want to check out wmctrl which is better suited for controlling WM, rather than using external tools like wmutils

[MusorGaming]

@z3bratabs currently I'm using wmctrl for setting active window position:

wmctrl -r :ACTIVE: -e 0,$x,$y,$w,$h

and xdotool to retrieve active window position:

eval $(xdotool getwindowgeometry --shell $(xdotool getactivewindow))

(which sets up variables X, Y, WIDTH, HEIGHT)

The problem is that xdotool (and bunch of others I've tried) have inconsistent, flaky behavior.

If I set coordinates of the window to (0,0,1280,1536) and then ask the coordinates of the said window it will return (2,56,1280,1524) or something else depending on whether it's a terminal window or a web-browser. Then semi-randomly offset everything by 1 pixel on a whim according some weird rules about window decorations and whatnot.

When all what is necessary is to SET and GET absolute window coordinates CONSISTENTLY.

To add insult to injury, some of these tools would return outputs in some ugly format I'd have to parse the outputs from using sed and regexes, ugh.

I thought I'd get around these poorly designed tools by writing a simple daemon in C which listens for hotkeys and moves windows around just the way necessary.

Then I learned the joys of what is the X window system API - the XLib. Lord have mercy, that is the ugliest ass-backwards C API I have ever laid my eyes on... I'd rather have bunch of ugly hacked together shell scripts than interface XLib directly.

So yeah, I'd rather use wmutils if possible.

[z3bra]

MusorGaming wrote:

@z3bratabs currently I'm using wmctrl for setting active window position:

wmctrl -r :ACTIVE: -e 0,$x,$y,$w,$h

and xdotool to retrieve active window position:

eval $(xdotool getwindowgeometry --shell $(xdotool getactivewindow)) (which sets up variables X, Y, WIDTH, HEIGHT)

The problem is that xdotool (and bunch of others I've tried) have inconsistent, flaky behavior.

If I set coordinates of the window to (0,0,1280,1536) and then ask the coordinates of the said window it will return (2,56,1280,1524) or something else depending on whether it's a terminal window or a web-browser. Then semi-randomly offset everything by 1 pixel on a whim according some weird rules about window decorations and whatnot.

The joys of reparenting windows. You see one window, but focus another one, which has different properties. And if you send commands to the window you see, they're usually not passed to the controlling window. Lots of fun.

I thought I'd get around these poorly designed tools by writing a simple daemon in C which listens for hotkeys and moves windows around just the way necessary.

Then I learned the joys of what is the X window system API - the XLib. Lord have mercy, that is the ugliest ass-backwards C API I have ever had laid my eyes on... I'd rather have bunch of ugly hacked together shell scripts than interface XLib directly.

The Xlib and XCB API are not that hard to get along with, really. But I can understand they're not pretty easy to use at first. If you look at wmutils' source, you'll see that the code is actually simple.

So yeah, I'd rather use wmutils if possible.

Please do, that's why we wrote it for :) You realise your experience will be much better if you drop your reparenting WM though.