pfw returns window ID not present in list returned by lsw. about core HOT 9 CLOSED

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

from core.

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.

from core.

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.

from core.

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

from core.

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.

from core.

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.

from core.

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

from core.

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

from core.

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.

from core.