awesome

Welcome to awesome bug tracking system.
Tasklist

FS#733 - wmctrl raise/focus window in max layout inncomplete

Attached to Project: awesome
Opened by will foran (will.foran) - Tuesday, 23 February 2010, 05:59 GMT
Task Type Bug Report
Category Core
Status Unconfirmed
Assigned To No-one
Operating System Linux
Severity Low
Priority Normal
Reported Version 3.4.3
Due in Version Undecided
Due Date Undecided
Percent Complete 0%
Votes 0
Private No

Details

when trying to focus a window with wmctrl while awesome is in the layout "awful.layout.suit.max" the window title on the bar is changed to selected (highlighted) but the client window is not visible. The old should-be-unfocused client remains.

To reproduce, open a few xterms in the max layout and run: wmctrl -R `wmctrl -l | cut -d ' ' -f 5- | dmenu` in one.
This works as expected in other layout modes.
This task depends upon

Comment by Uli Schlachter (psychon) - Friday, 26 February 2010, 17:08 GMT
Sorry, either I didn't test this correctly or it works as expected here. Any hints?
Comment by will foran (will.foran) - Monday, 01 March 2010, 18:17 GMT
I tried this on another computer with the same results. Both use archlinux with the current awesome package (awesome-3.4.3-2).

This might be a better explination.
I have uzbl and xterm both in tag 1 with max layout. Xterm is focused.
I do the following

[will@MSIXP ~]$ wmctrl -l
0x0120000d 0 MSIXP will@MSIXP:~
0x00e00003 0 MSIXP FS#733 : wmctrl raise/focus window in max layout inncomplete - Uzbl browser <14680067>
[will@MSIXP ~]$ wmctrl -a Uzbl

My screen still displays xterm. However, uzbl does have focus. Keystrokes are received by uzbl, not xterm.

This happens in max and max.fullscreen.
Changing focus and raising appears to work as expected in other modes, including magnifier.

I'll try awesome from git and see if the problem persists.

Comment by will foran (will.foran) - Monday, 01 March 2010, 18:35 GMT
I compiled from git and noticed the max layout icon has changed. wmctrl still doesn't raise the window in this mode.
Comment by Uli Schlachter (psychon) - Monday, 01 March 2010, 18:51 GMT
I just wondered why the window would be raised at all...

Does the same happen with the floating layout? All the other layouts cant generate overlapping windows...
Comment by will foran (will.foran) - Monday, 01 March 2010, 20:08 GMT
I may have misunderstood the function of wmctrl or the design of awesome, but the behavior with wmctrl when awesome is in magnifier mode is what I expected in max modes as well. When wmctrl is executed, the client is focused and place front and center ("raised"?).

from wmctrl's man page:
-a <WIN>
Switch to the desktop containing the window <WIN>, raise the window, and give it focus.
-R <WIN>
Move the window <WIN> to the current desktop, raise the window, and give it focus.

Looking this up inspired exploring more cases.

"wmctrl -R Uzbl" only changes the focus of the window (does not raise/display) if the window is on the same tag/workspace. If Uzbl is on tag 2 and wmctrl is run on tag 1, everything works as expected. Uzbl is brought to tag 1, focused, and all I see.

Similiarly, "wmctrl -a Uzbl" works as expected when Uzbl is not on the tag from which the command is run. I am moved to the tag Uzbl is on, Uzbl is focused, and all I see.

The client is not raised if it is on the same tag as where wmctrl is executed; the client is raised if coming from another tag. This seems to be true in the max and floating layouts.

As you pointed out, this is not an issue in titling layouts; clients don't overlap.
Comment by Uli Schlachter (psychon) - Wednesday, 03 March 2010, 09:47 GMT
xtrace on awesome while wmctrl -R does its job (no idea where that lua error comes from):

78.033 006:>:02fe: Event (generated) ClientMessage(33) format=0x20 window=0x00600025 type=0xf4("_NET_WM_DESKTOP") data=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;
78.034 006:>:02fe: Event (generated) ClientMessage(33) format=0x20 window=0x00600025 type=0xed("_NET_ACTIVE_WINDOW") data=0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00,0x00;
78.034 006:>:02fe: Event ConfigureRequest(23) parent=0x00000111 window=0x00600025 value-mask=stack-mode stack-mode=Above(0x00) sibling=None(0x00000000) x=0 y=156 width=324 height=342 border-width=1
W: awesome: luaA_dofunction:108: error while running function
stack traceback:
[C]: ?
./awesomerc.lua:332: in function <./awesomerc.lua:332>
error: ./awesomerc.lua:332: bad argument #-1 to '?' (string expected, got nil)
W: awesome: luaA_dofunction:108: error while running function
stack traceback:
[C]: ?
./awesomerc.lua:331: in function <./awesomerc.lua:331>
error: ./awesomerc.lua:331: bad argument #-1 to '?' (string expected, got nil)
78.041 006:<:02ff: 28: Request(18): ChangeProperty mode=Replace(0x00) window=0x00000111 property=0xed("_NET_ACTIVE_WINDOW") type=0x21("WINDOW") data=0x00000000;
78.041 006:<:0300: 28: Request(18): ChangeProperty mode=Replace(0x00) window=0x00000111 property=0xed("_NET_ACTIVE_WINDOW") type=0x21("WINDOW") data=0x00600025;
78.041 006:<:0301: 12: Request(42): SetInputFocus revert-to=Parent(0x02) focus=0x00600025 time=CurrentTime(0x00000000)
78.041 006:<:0302: 44: Request(25): SendEvent propagate=false(0x00) destination=0x00600025 event-mask=StructureNotify ConfigureNotify(22) event=0x00600025 window=0x00600025 above-sibling=None(0x00000000) x=0 y=156 width=324 height=342 border-width=1 override-redirect=false(0x00)
78.041 006:>:0302: Event PropertyNotify(28) window=0x00000111 atom=0xed("_NET_ACTIVE_WINDOW") time=0x004fd65b state=NewValue(0x00)
78.041 006:>:0302: Event PropertyNotify(28) window=0x00000111 atom=0xed("_NET_ACTIVE_WINDOW") time=0x004fd65b state=NewValue(0x00)
78.041 006:>:0302: Event FocusOut(10) detail=Nonlinear(0x03) event=0x0040000d mode=Normal(0x00)
78.041 006:>:0302: Event FocusIn(9) detail=Nonlinear(0x03) event=0x00600025 mode=Normal(0x00)
78.041 006:>:0302: Event (generated) ConfigureNotify(22) event=0x00600025 window=0x00600025 above-sibling=None(0x00000000) x=0 y=156 width=324 height=342 border-width=1 override-redirect=false(0x00)


So awesome gets a ConfigureRequest which wants to raise the window above all others.
event.c line 273 reacts like this:

/* Clients are not allowed to directly mess with stacking parameters. */
ev->value_mask &= ~(XCB_CONFIG_WINDOW_SIBLING | XCB_CONFIG_WINDOW_STACK_MODE);

That request is just ignored. :(

(The rest of the xtrace seems to be the focus change)
Comment by Kanru Chen (kanru) - Tuesday, 22 November 2011, 02:55 GMT
I add

client.add_signal("focus", function(c) c:raise() end)

to my rc.lua and it seems to work. Maybe we can add something similar to the max layout?

Loading...