Little issue (bug?) with dwm + xdotool

I just discovered in the herbstluftwm thread, that xdotool can activate windows by names. A nice feature I missed in dwm, so I put some code in the config.h to bind such commands to key combinations.

Example

xdotool search -classname luakit windowactivate --

Now, when I'm on tag 1 and open luakit, which is supposed to be on tag 2, the above command doesn't activate luakit. It only works if I change to tag 2, go back to tag 1 again and reenter the command / press the key combination.

Does anybody have an idea why this doesn't work?

I redirect any error output generated by dwm into a file, there are no messages in there, so there are no hints. Is this a limitation in xdotool? Is it even a problem with xorg?

Re: Little issue (bug?) with dwm + xdotool

Maybe this is related to this:

Luakit uses libunique, so new instances get loaded in a new tab. When I open a link in e.g. urxvt (on tag 1) with luakit on tag 2, luakit gets the urgent flag (if that's how this is called). This can be seen with the color change in the tag bar on the upper left corner of dwm (horrible english, sorry!).

However, this becoming urgent does only work if luakit was focused after it was launched. It's like dwm doesn't know what's going on on tag 2, except that there's an application with tag 2. So basically it's the same thing like this issue here.

I hope you get what I want to say, sometimes I'm not that capable of explaining stuff in english... Although I feel quite confident with this language, thanks to e.g. this forum

Re: Little issue (bug?) with dwm + xdotool

I had many headaches because xdotool uses regural expression for search. (for example , you have "opera" opened and search in firefox wth "opera crashes gtk2" , if you are using --name)Check --sync option too.

Re: Little issue (bug?) with dwm + xdotool

Army wrote:

Maybe this is related to this:

Luakit uses libunique, so new instances get loaded in a new tab. When I open a link in e.g. urxvt (on tag 1) with luakit on tag 2, luakit gets the urgent flag (if that's how this is called). This can be seen with the color change in the tag bar on the upper left corner of dwm (horrible english, sorry!).

However, this becoming urgent does only work if luakit was focused after it was launched. It's like dwm doesn't know what's going on on tag 2, except that there's an application with tag 2. So basically it's the same thing like this issue here.

I don't think the two things are related.dwm marks a client as urgent when an urgent hint is sent by the client, and unmarks it when the urgent window gets the focus. By the same logic, if a client sends an urgent hint while it's focused, it's not marked as urgent by dwm. You can clearly see this by setting URxvt.urgentOnBell to true in your X resources, and try `sleep 1; printf \\a`, giving focus to another window while `sleep`.

Re: Little issue (bug?) with dwm + xdotool

Hi lolilolicon!

Sorry if i'm misinterpreting the whole thing(i've never used the urgency hooks in dwm either), but to me, it sounds like Army is saying that the urgency hooks only works if the "urgent" client have been _previously_ focused. You know like if you're on tag1 and your browser opens on tag2 because of the rules settings, and you've never been on tag2 yet...

Of course if it's focused, like in your example, then that's another thing...

However, this becoming urgent does only work if luakit was focused after it was launched. It's like dwm doesn't know what's going on on tag 2, except that there's an application with tag 2. So basically it's the same thing like this issue here.

Re: Little issue (bug?) with dwm + xdotool

Oh, I see, so it's if it's a new luakit window opened on tag 2, and you never focus it, there will be no urgency on the dwm tag bar if you open a new tab in it? But if you then focus the luakit window once by selecting tag 2, and then select tag 1 again, then opening a new tab in the luakit window will trigger urgency on the dwm bar? Am I getting it straight?

It's weird; again we need to take a look at the xprop output...

-- EDIT --

I should also ask, does it happen with other applications? I tried within tag 1 `xterm -class Firefox -name foobar`, sending the xterm window to tag 2 (as per a rule on Firefox), and `xdotool search --classname foobar windowactivate` works just fine.

Re: Little issue (bug?) with dwm + xdotool

Yes, that's atleast how I interpret what Army stated previously, but lets wait for his own confirmation, as maybe it's just me being dence...

This also, like Army stated, seems to be the same issue as with xdotool not being able to focus a previously-unfocused client, i.e. when running dwb& in a term on tag1, and then dwb opens on tag2 because of the tagging rules, then when running "xdotool search -classname dwb windowactivate" to get dwb focused, then it dosen't work, and it only works if switching to tag2 and then back to tag1 and then running the xdotool command again, or if running this command instead:

Re: Little issue (bug?) with dwm + xdotool

Hi lolilolicon!

I've just first now seen your edit...

I've tested what you've posted and you're of course correct, but I am somewhat confused now I must confess...

Firstly, after I had tested your xterm example, I installed firefox and made a new test dwm build with the Firefox classname defined to start at tag2, and then fired it up in another vt with running 'xinit ./dwm -- :1'...

In that test run, then I opened a term on tag 1 and then runned 'firefox&', which then correctly started in tag2, I could see from the dwm bar, and then I runned:

xdotool search --classname Firefox windowactivate

And that didn't work!

Then I noticed that in your xterm example you search for the window name in the --classname argument, but when I runned xprop on the xterm window, then it showed that the classname where actually both Firefox and foobar, which is why it still matched.

However, why it dosen't work when using Firefox as xdotool class search string, I really do not understand, and which is also why me and Army cannot get it to work either with dwb, luakit or firefox...

Do you have any thoughts upon this? (And if it's me being completelly ignorant, then I apologise in advance )

-- EDIT --

Funny enough, it always works when using xdotools --name argument(with the window name), instead of the classname, but obviously, that's not as nice as if classname worked...

Re: Little issue (bug?) with dwm + xdotool

Hi lolilolicon!

I'm sorry about that I completelly had forgotten your request for the xprop output!

Thanks for the explenation, I had read the xdotool manpage previously and also tried in one of the tests with --class instead of --classname, but I must admit that I didn't knew what the difference where between them before you explained it to me...

Also, in your xterm command-line, I had misunderstood the xterm manpage, and thought that the -name argument, where for defining the iconname(title), like -n does...

Anyway, I do not have this issue myself(as I don't use xdotool to raise windows, but just dwm's standard way), and I was just trying to see if I could help Army out with this, but it's over my head I must confess (As I can still not get it to work with dwb or luakit, which has respectively dwb and luakit as both classname and class property...)

Hmm, i've just tested jokerboy's fix_netactivewindow patch, and then tried to raise the dwb window with xdotool, and it still dosen't work, so that patch is probably not against the same issue as the dwm mailing-list post i quoted to previously...

I haven't really sat myself into this whole netactivewindow issue in dwm, and I just saw that same name when I quickly glanced through that dwm mailing-list post and then thought that it was related to jokerboy's netactivewindow patch also...

Re: Little issue (bug?) with dwm + xdotool

xdotool search --classname luakit :

8388609
8388613
8388640

xdotool selectwindow --> luakit :

8388640

I've just did a new test with a rebuilded dwm and with firefox, and that worked, since after you kindly learned me about the difference between class and classname, then I of course new to search for the classname of Navigator and not Firefox, or else I should have changed the search argument to --class instead...

So... We now see that the issue with xdotool in dwm, is that whenever the class and classname is identical, then dwm will not raise the client if it has previosuly never been focused.

I come to this conclusion, since your xterm example works, where the classname where foobar and class was Firefox, and with Firefox where the classname is Navigator and the class is Firefox, whereas, both dwb and luakit dosen't work, which both has identical class/classnames...

How to workaround this, and if even possible, I have no idea whatsoever...

-- EDIT --

.. And I should probably learn to test things out more propperly before posting any more brilliant conclusions of mine!

Anyway, my point was just to state that the above "conclusion" it utterly wrong, as i've just now tested it out be running "xterm -class Firefox -name Firefox" and then 'xdotool search --classname Firefox windowactivate' did raise the client from the unfocused tag just fine! (And where xprop confirms that both class and classname where defined as Firefox)

Re: Little issue (bug?) with dwm + xdotool

mhertz wrote:

xdotool search --classname luakit :

8388609
8388613
8388640

xdotool selectwindow --> luakit :

8388640

This is the problem. The xdotool search command above clearly finds three windows, and if you chain the commands, "%1" will be passed, which is NOT the main luakit window. To see what the other two windows are, you can use `xprop -id <window id>`.

So this is not a bug in dwm at all. The workaround would be to use a more precise search parameter in the xdotool command, or start luakit with a different WM_CLASS if possible, or maybe talk to the luakit developers about it.

-- EDIT --

Try the following before and after the luakit window is focused:

xdotool search --classname luakit

The order of the windows found should be different, which I believe is the reason it works after selecting tag 2. Anyway, I think the main mystery is unvailed, so go ahead and test all those different cases out.

Re: Little issue (bug?) with dwm + xdotool

Anyway, I've found a solution to the issue now, so that Army can use xdotool together with dwm and luakit, and which also works with dwb and other "problematic" apps...

From xdotool's manpage's 'search' section:

--onlyvisible
Show only visible windows in the results. This means ones with
map state IsViewable.

So, i've now just tested that both luakit and dwb works perfectly now with:

xdotool search --onlyvisible --classname luakit windowactivate

xdotool search --onlyvisible --classname dwb windowactivate

Thanks for all your help and feedback lolilolicon, it was much appreciated, mate!

CU, Martin.

Glad you've found the solution, Martin.I think why this works is because dwm does not unmap the window when its tags are not selected, but simply moves the window out of screen (see showhide in dwm.c), so luakit on tag 2 is mapped (IsViewable) even if tag 2 is not selected. This may not work in some other WMs that doesn't work this way. It's also possible that dwm in the future may choose to unmap, since it's considered more proper.Alternatively, does the following work?

Re: Little issue (bug?) with dwm + xdotool

I did some searching and read anselm once previously stating that he used moving windows off-screen for the tags, instead of unmapping them, as it was faster that way...

I've tested your propossed solution, and you're of course correct; both luakit and dwb works perfectly with that solution!

I thought that the --onlyvisible argument where a nice way of seperating the clients main window id out from the other child-ids, but with your solution, then it will additionally work also in propperly unmapping wm's like xmonad etc. and also in the feature, where dwm possibly would change it's implementation also, plus not to mention that it's a much smaller argument to write

Re: Little issue (bug?) with dwm + xdotool

Sorry sorry sorry, I totally missed this thread when you guys posted all this! I don't know why I didn't see this in the list of new posts. SO sorry!Thanks to all for your effort!!

mhertz wrote:

Sorry if i'm misinterpreting the whole thing(i've never used the urgency hooks in dwm either), but to me, it sounds like Army is saying that the urgency hooks only works if the "urgent" client have been _previously_ focused. You know like if you're on tag1 and your browser opens on tag2 because of the rules settings, and you've never been on tag2 yet...

Exactly! That's a bit weird in dwm, should be fixed in my opinion. Maybe I'll explain and discuss this issue on the mailing list.

lolilolicon wrote:

dwm marks a client as urgent when an urgent hint is sent by the client, and unmarks it when the urgent window gets the focus. By the same logic, if a client sends an urgent hint while it's focused, it's not marked as urgent by dwm. You can clearly see this by setting URxvt.urgentOnBell to true in your X resources, and try `sleep 1; printf \\a`, giving focus to another window while `sleep`.

That works fine for me as well. I think it doesn't work, if the window just recently got OPENED in an unselected tag. If I open a terminal, issue sleep 1;printf \\a, then the terminal window already got focused once. I guess that makes the difference. I'll test it.