Extend xdotool with getwindowstacklen command.

[abensj]

When running xdotool search command without closing any pipe, it was not possible to anyhow determine if search command finished without any results, since it does not print any character. The only workaround was to use getmouselocation, but it is only a workaround.

Command returns output in similar fashion as getmouselocation, for example:
stack_length:123

This is a cleaner way to count of how many windows have been matched by search parameters. Even if used in bash scripts when pipe is closed and output lines counted.

[jordansissel]

Can you tell me more about this problem? If 'search' is the last command
(even with --sync), it will output results and exit.

What condition are you waiting on? Or what is solved by knowing how long
the window stack is?

(I mostly want to know more to see if I can help with an alternate
solution, but I don't anticipate rejecting your patch)
On Tuesday, August 30, 2016, abensj [email protected] wrote:

When running xdotool search command without closing any pipe, it was not
possible to anyhow determine if search command finished without any
results, since it does not print any character. The only workaround was to
use getmouselocation, but it is only a workaround.

Command returns output in similar fashion as getmouselocation, for example:
stack_length:123

This is a cleaner way to count of how many windows have been matched by
search parameters. Even if used in bash scripts when pipe is closed and

output lines counted.

You can view, comment on, or merge this pull request online at:

#144
Commit Summary

• Extend xdotool with getwindowstacklen command.

File Changes

• M Makefile
  https://github.com/jordansissel/xdotool/pull/144/files#diff-0 (2)
• A cmd_getwindowstacklen.c
  https://github.com/jordansissel/xdotool/pull/144/files#diff-1 (36)
• M xdotool.c
  https://github.com/jordansissel/xdotool/pull/144/files#diff-2 (1)
• M xdotool.h
  https://github.com/jordansissel/xdotool/pull/144/files#diff-3 (1)

Patch Links:

• https://github.com/jordansissel/xdotool/pull/144.patch
• https://github.com/jordansissel/xdotool/pull/144.diff

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#144, or mute the thread
https://github.com/notifications/unsubscribe-auth/AAIC6uIdmdJ0wudN3K4MsQL2yKBMiEtLks5qlC5qgaJpZM4JwhLv
.

[abensj]

I am running xdotool by using pipes to control process flow; pipes are never closed. There is like a REST server which proxies commands to xdotool's in pipe and reacts on xdotool's out and error pipe contents. Previously we patched so that when newline is anticipated within pipe or script, the command is run right away not only when pipe is closed, this was one of prerequisites for such a workflow.

xdotool does not print any output if no window is found further more the whole command till the newline is canceled, because when search does not find any window it breaks the chain (it is kind of logical when used just once in bash script or similar). But as a result in this case, the controlling script can not know if anything was found or not, or what happened, even if the command was finished.

I had found a workaround, that if getmouselocation is run as a next separate command, the output in stdout would be window_id + mouselocation or just mouselocation, from that it could be possible to distinguish if any window was found, but it seemed more like a dirty hack than a solution and it seemed pretty easy to implement a new command sine i had to reserach how it works anyways when extending --sync flag with timing, which kind of too bound with the same usecase.

If xdotool was run just once as a command in bash script, this would not be so important, because the returned output would be empty, thus could consider that window was not found. But if looping forever on output pipe, then there is no way to know, if something happened.

Another way could be to use --shell flag, but then again it seemed as a hack. In my case, it is not important what comes in stdout from xdotool, just the fact that from that output it is possible to determine if command was run and the status of results.

With this patch, basically, i run a regex on stdout's line and fetch the length of it. It would be even easier to use, if the output was just '0', but i thought that since other commands print nice output, then this one should do the same, to fit in.

I hope i kind of explained the usecase and the situation. Even though i had hoped it would be clear from previous comment.

[jordansissel]

@abensj by "running xdotool by using pipes" do you mean using xdotool scripts via stdin (like xdotool - and sending xdotool commands via stdin?) or do you mean running xdotool search --sync ... and waiting for the program to exit?

[jordansissel]

I'd love to be able to reproduce the problem you're having. I think I have ideas about what may be causing your issues, but I'm not sure yet.

[abensj]

Yes. Feeding in xdotool commands via stdin pipe. And controlling flow by analyzing stdout and stderr pipes.

[abensj]

I think there is no problem, it is just that there is no output if 0 windows are found. When using in scripts, it is just fine and as i understand that was the primary usecase xdotool was invented for. It is just that it has become quiet good tool even for other usecases.

[abensj]

Oh, yes. With "the old" --sync flag script can not be run via pipes, because then it blocks forever and the controlling process basically has no use for xdotool because it is blocked. This is the reason for other patch, that is used for timing the maximum duration for --sync to block the process.

That timing patch in my opinion is quiet useful, because then it is possible to control if window has really started. For example --sync wait till window is opened, and if it is known that window has to open up in X seconds, then it the process goes too long, then can report error. Otherwise the script would block forever and nothing is reported. Thus, the cleanest report for me seemed stack length.