You are not logged in.

#1 2011-11-10 17:48:47

Army
Member
Registered: 2007-12-07
Posts: 1,784

Little issue (bug?) with dwm + xdotool

Hi

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?

Offline

#2 2011-11-10 20:33:49

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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

Hi Army!

I've just tested this a little, and strangelly, it only works if giving several xdotool commands after eachother, switching between windowraise and windowactivate...

Unfortunetly, giving those two commands several times in same xdotool command dosen't work, which is strange as xdotool chains commands with the previous output...

Maybe there's a better way, but atleast the following shell command-line works:

xdotool search -classname dwb windowraise;xdotool search -classname dwb windowactivate;xdotool search -classname dwb windowraise;xdotool search -classname dwb windowactivate

Sometimes, one windowraise and then two windowactivate would also work, but wasen't 100% reproducable always, but atleast the above command is...

Note, i've tested with dwb as I don't use luakit, but that's irrelevant...

Last edited by mhertz (2011-11-10 20:46:59)

Offline

#3 2011-11-10 20:51:52

Army
Member
Registered: 2007-12-07
Posts: 1,784

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 smile

Offline

#4 2011-11-10 21:03:14

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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

Yeah, I think you're right, it sounds like both issues comes from the same problem in dwm...

Btw, I never have problems understanding your posts, mate smile

CU, Martin.

Offline

#5 2011-11-11 20:13:53

tum
Member
Registered: 2010-05-18
Posts: 40

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.

Offline

#6 2011-11-12 00:28:26

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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

I did use --sync to test with also, but didn't change anything, and we used -classname to search for...

Allthough it's a little bit of a long command-line I posted previously, then it atleast works perfectly...

Offline

#7 2011-11-12 02:39:13

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,716

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

Back to your problem.  Can you post the output of `xprop` on luakit?


This silver ladybug at line 28...

Offline

#8 2011-11-12 13:05:00

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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.

Offline

#9 2011-11-12 13:46:15

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,716

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.

Last edited by lolilolicon (2011-11-12 14:34:01)


This silver ladybug at line 28...

Offline

#10 2011-11-12 14:09:40

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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:

xdotool search -classname dwb windowraise;xdotool search -classname dwb windowactivate;xdotool search -classname dwb windowraise;xdotool search -classname dwb windowactivate

CU, Martin.

Last edited by mhertz (2011-11-12 14:12:00)

Offline

#11 2011-11-12 17:56:19

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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 wink)

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

Last edited by mhertz (2011-11-12 19:00:32)

Offline

#12 2011-11-13 03:10:48

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,716

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

@mhertz Sorry about the late reply.

mhertz wrote:
xdotool search --classname Firefox windowactivate

And that didn't work!

That's what I thought you might have mistaken, and why I insisted requesting the xprop output.  Let me explain:

`xdotool search` accepts several options which may be a little confusing:

  • --class:  search the classhint class.  It's the second field of WM_CLASS in the xprop output.

  • --classname:  search the classhint name.  It's the first field of WM_CLASS in the xprop output.

  • --name:  search the window manager name, i.e. the title displayed in titlebar.  It's the WM_NAME in the xprop output.

And xdotool matches all of those via regexp.

But I think the problem might still not be resolved.


This silver ladybug at line 28...

Offline

#13 2011-11-13 14:41:11

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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 smile (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...)

CU, Martin.

dwb, luakit, firefox and 'xterm -class Firefox -name foobar' xprop output:

dwb:

_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 8388613
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x800004
WM_CLIENT_LEADER(WINDOW): window id # 0x800001
_NET_WM_PID(CARDINAL) = 2955
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 0 by 0
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "dwb", "dwb"
WM_ICON_NAME(STRING) = "iGoogle"
_NET_WM_ICON_NAME(UTF8_STRING) = "iGoogle"
WM_NAME(STRING) = "iGoogle"
_NET_WM_NAME(UTF8_STRING) = "iGoogle"


luakit:

_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 8388642
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x800021
WM_CLIENT_LEADER(WINDOW): window id # 0x800001
_NET_WM_PID(CARDINAL) = 3370
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 1 by 1
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "luakit", "luakit"
WM_ICON_NAME(STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
_NET_WM_ICON_NAME(UTF8_STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
WM_NAME(STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
_NET_WM_NAME(UTF8_STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."


firefox:

_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 10485881
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0xa00078
WM_CLIENT_LEADER(WINDOW): window id # 0xa00001
_NET_WM_PID(CARDINAL) = 3192
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 0 by 0
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "Navigator", "Firefox"
WM_ICON_NAME(STRING) = "Mozilla Firefox Start Page - Mozilla Firefox"
_NET_WM_ICON_NAME(UTF8_STRING) = "Mozilla Firefox Start Page - Mozilla Firefox"
WM_NAME(STRING) = "Mozilla Firefox Start Page - Mozilla Firefox"
_NET_WM_NAME(UTF8_STRING) = "Mozilla Firefox Start Page - Mozilla Firefox"


xterm -class Firefox -name foobar:

WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW
_NET_WM_PID(CARDINAL) = 7095
WM_CLIENT_LEADER(WINDOW): window id # 0xa0000d
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLASS(STRING) = "foobar", "Firefox"
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified size: 484 by 316
		program specified minimum size: 10 by 17
		program specified resize increment: 6 by 13
		program specified base size: 4 by 4
		window gravity: NorthWest
WM_CLIENT_MACHINE(STRING) = "arch"
WM_COMMAND(STRING) = { "xterm", "-class", "Firefox", "-name", "foobar" }
WM_ICON_NAME(STRING) = "foobar"
WM_NAME(STRING) = "foobar"

Last edited by mhertz (2011-11-13 14:57:52)

Offline

#14 2011-11-13 16:03:40

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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

OK, after digging some more, I found a post from the dwm mailing list, which I think talks about this issue in dwm and a patch:

http://lists.suckless.org/dev/1104/7554.html

Btw, I believe that this patch in it's recent state can be found on jokerboy's dwm repo... (netactivewindow patch...)

-- EDIT --

Here is the link to jokerboy's dwm repo's fix_netactivewindow patch:

http://hg.punctweb.ro/dwm/raw/c568b876c … indow.diff

-- EDIT2 --

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

Last edited by mhertz (2011-11-13 22:49:25)

Offline

#15 2011-11-14 00:02:40

JokerBoy
Member
From: România
Registered: 2009-09-24
Posts: 641
Website

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

Offline

#16 2011-11-14 00:16:54

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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

Doh! .. Sorry, I should've researched it better before posting nonsense like that!

Thanks for your reply, mate!

Offline

#17 2011-11-14 03:45:58

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,716

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

mhertz wrote:

-- SNIP --

luakit:

_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 8388642
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x800021
WM_CLIENT_LEADER(WINDOW): window id # 0x800001
_NET_WM_PID(CARDINAL) = 3370
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
                program specified minimum size: 1 by 1
                window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "luakit", "luakit"
WM_ICON_NAME(STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
_NET_WM_ICON_NAME(UTF8_STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
WM_NAME(STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
_NET_WM_NAME(UTF8_STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."

-- SNIP --

No problem from this output I can see that could have caused Army's command to
fail.  It's very much just the same as the Firefox xprop.

So, for better debugging, let's break the command line down.

xdotool search --classname luakit

Does the above output the correct window ID? Check with:

xdotool selectwindow

Last edited by lolilolicon (2011-11-14 03:47:01)


This silver ladybug at line 28...

Offline

#18 2011-11-15 00:52:08

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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! smile

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)

Last edited by mhertz (2011-11-15 01:24:11)

Offline

#19 2011-11-15 05:01:49

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,716

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

Interestingly, `xdotool search --class '^Firefox$'` gives me 9 results.  Fortunately, the main Firefox window is the first of them, so `xdotool search ... windowactivate` works.

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.

Last edited by lolilolicon (2011-11-15 05:22:31)


This silver ladybug at line 28...

Offline

#20 2011-11-15 16:48:39

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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

Ahh, I see! Thanks for solving the mystery then, mate!

Here's the results you've requested:

martin@arch ~/.test % xdotool search --classname luakit
8388609
8388613
8388640

martin@arch ~/.test % xdotool search --classname luakit // after having focused tag2...
8388640
8388609
8388613

martin@arch ~/.test % xprop -id 8388609
WM_CLASS(STRING) = "luakit", "Luakit"
WM_COMMAND(STRING) = { "luakit" }
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x800002
WM_CLIENT_LEADER(WINDOW): window id # 0x800001
_NET_WM_PID(CARDINAL) = 2553
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified size: 10 by 10
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING
WM_ICON_NAME(STRING) = "luakit"
_NET_WM_ICON_NAME(UTF8_STRING) = "luakit"
WM_NAME(STRING) = "luakit"
_NET_WM_NAME(UTF8_STRING) = "luakit"

martin@arch ~/.test % xprop -id 8388613
_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 8388615
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x800006
WM_CLIENT_LEADER(WINDOW): window id # 0x800001
_NET_WM_PID(CARDINAL) = 2553
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified size: 200 by 200
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "luakit", "Luakit"
WM_ICON_NAME(STRING) = "luakit"
_NET_WM_ICON_NAME(UTF8_STRING) = "luakit"
WM_NAME(STRING) = "luakit"
_NET_WM_NAME(UTF8_STRING) = "luakit"

martin@arch ~/.test % xprop -id 8388640
WM_STATE(WM_STATE):
		window state: Normal
		icon window: 0x0
WM_HINTS(WM_HINTS):
		Client accepts input or input focus: True
		Initial state is Normal State.
		bitmap id # to use for icon: 0x80003b
		bitmap id # of mask for icon: 0x80003e
		window id # of group leader: 0x800001
XdndAware(ATOM) = BITMAP
_MOTIF_DRAG_RECEIVER_INFO(_MOTIF_DRAG_RECEIVER_INFO) = 0x6c, 0x0, 0x5, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x10, 0x0, 0x0, 0x0
_NET_WM_ICON(CARDINAL) = 	Icon (48 x 48):

_NET_WM_SYNC_REQUEST_COUNTER(CARDINAL) = 8388642
_NET_WM_WINDOW_TYPE(ATOM) = _NET_WM_WINDOW_TYPE_NORMAL
_NET_WM_USER_TIME_WINDOW(WINDOW): window id # 0x800021
WM_CLIENT_LEADER(WINDOW): window id # 0x800001
_NET_WM_PID(CARDINAL) = 2553
WM_LOCALE_NAME(STRING) = "en_US.UTF-8"
WM_CLIENT_MACHINE(STRING) = "arch"
WM_NORMAL_HINTS(WM_SIZE_HINTS):
		program specified minimum size: 1 by 1
		window gravity: NorthWest
WM_PROTOCOLS(ATOM): protocols  WM_DELETE_WINDOW, WM_TAKE_FOCUS, _NET_WM_PING, _NET_WM_SYNC_REQUEST
WM_CLASS(STRING) = "luakit", "luakit"
WM_ICON_NAME(STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
_NET_WM_ICON_NAME(UTF8_STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
WM_NAME(STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."
_NET_WM_NAME(UTF8_STRING) = "luakit - browser framework - Overview - luakit.org - http://luakit.org/projects/..."

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! smile

CU, Martin.

Offline

#21 2011-11-16 03:53:52

lolilolicon
Member
Registered: 2009-03-05
Posts: 1,716

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

mhertz wrote:

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! smile

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?

xdotool search --classname luakit windowactivate %@

This silver ladybug at line 28...

Offline

#22 2011-11-16 23:49:39

mhertz
Member
From: Denmark
Registered: 2010-06-19
Posts: 664

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

Thanks again for the background info!

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 wink

Thanks again for all your help and support, mate!

CU, Martin.

Offline

#23 2012-01-05 17:44:24

Army
Member
Registered: 2007-12-07
Posts: 1,784

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.

Offline

Board footer

Powered by FluxBB