To quote from ICCCM (§4.1.2): "The window manager will not change properties
written by the client."
We tried to do this anyway to update WM_HINTS so that the current urgency state
is reflected. Apparently, Chrome does a similar read-modify-set cycle and the
resulting race condition meant that the "accepts input" hint on Chromium's
window was permanently disabled.
This helps with https://github.com/awesomeWM/awesome/issues/670, but I still
think that Chrome shouldn't try to implement "please don't focus me when I do
the following" by temporarily claiming "please don't ever focus me".
Signed-off-by: Uli Schlachter <psychon@znc.in>
E.g. trying to press mouse button 1.5 via root.fake_input() doesn't make sense.
Previously the code silently truncated the number to an integer. Now it
complains about this instead.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only remaining calls are for a window's opacity and in the DBus type
handling. Everything else wants integers, not something with a comma.
Signed-off-by: Uli Schlachter <psychon@znc.in>
ICCCM specifies when the WM has to send a ConfigureNotify. Java does not care
and wants one all the time. Meh.
Fixes: #248
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allow layout "arrange" to be called less often and react on
the cause of the change itself rather than it's consequences
(usually, the "focus" signal).
Previously, the layout were re-arranged everytime the focus changed.
Now, with "raised" and "lowered", it require less "arrange".
"swapped" allow smarted layouts. Currently, swapped cause a full
re-arrange. It re-read the "index" list from scratch and create
a "new" layout. With "swapped", incremental layout changes are
possible.
Fixes https://github.com/awesomeWM/awesome/issues/616
When a client is unmanaged, we know emit mouse::leave on its titlebar before the
client object is invalidated, so that Lua can still work with it. Before, this
event was emitted only when we got a LeaveNotify from the X11 server.
Fixes: #620
Signed-off-by: Uli Schlachter <psychon@znc.in>
luaA_warn() prints a Lua backtrace and thus generates more useful output. warn()
should only be used in awesome-internal places (e.g. receiving an error from the
X11 server).
Closes https://github.com/awesomeWM/awesome/pull/608.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Some words about X11 event handling: Every X11 client can select input on any
window. For this, inside the X11 server each window has for each client a
bitmask for the kind of events that this client is interested in. When a mouse
button is pressed inside of a window, a corresponding event is generated for
that window and sent to all X11 clients which asked for
XCB_EVENT_MASK_BUTTON_PRESS. When no client is interested in this event, the
event is propagated to the parent window and the same procedure is done again
here. This continues up until the root window is reached.
Some words about the event masks that awesome uses: For clients, we ask for
button press events on the frame window that we reparent the client window into
so that we get any kind of press on the titlebar (and also events inside of the
client window if the client itself doesn't care for click events?). We are also
interested in button presses / releases on the root window. However, before this
commit, we didn't actually ask for button events on drawins (e.g. the wibox).
This worked fine, because no one asked for these events and the event propagated
to the root window where it was then sent to awesome.
However, newer Qt versions do something weird and the above broke. I don't
actually know what is going on. I know about the above propagation rules, but
looking at protocol traces of what Qt does, awesome should still get the button
events. During startup, Qt asks for button events on its own windows. After a
hotplug event, it asks the same again, but now also includes the root window.
So... how can Qt asking for button events on the root window cause awesome not
to get them? I have no idea.
(And yes, I guess that Qt asking for mouse events on the root window is a bug,
but I have no idea how exactly this happens nor about any other side effects of
it).
This commit makes us ask for button events on our drawins so that the server
will send them to us. This is the right thing to do anyway and it was reported
to have some positive effects.
Ref: https://github.com/awesomeWM/awesome/issues/415
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only exception is the window for _NET_SUPPORTING_WM_CHECK. That window
already had a _NET_WM_NAME property before and doesn't get a WM_NAME property in
this commit. I just decided for myself that it doesn't need one. :-)
Right after startup with the default config we now have the following situation:
$ xwininfo -root -tree
xwininfo: Window id: 0x2d7 (the root window) (has no name)
Root window id: 0x2d7 (the root window) (has no name)
Parent window id: 0x0 (none)
7 children:
0x200011 "Awesome drawin": ("awesome" "awesome") 1500x20+0+0 +0+0
0x200010 "Awesome drawin": ("awesome" "awesome") 1x1+0+0 +0+0
0x20000d "Awesome drawin": ("awesome" "awesome") 100x30+0+0 +0+0
0x20000a "Awesome no input window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200009 "Awesome systray window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200008 "awesome": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200007 "Awesome WM_Sn selection owner window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
One of those drawin is the awful.wibox. Another drawin is created by awful.menu.
I guess that the third one is created by awful.tooltip, but I'm not sure. Wow,
so many windows...
Closes https://github.com/awesomeWM/awesome/pull/556.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is an enhancement to make non-ASCII symbol keys usable for
implementation and configuration of Awesome.
The enhancement was proposed and had been developed under the
initiative of Daniel Hahler. Thanks to his sharing of his results with our
community, we gradually deepened our understanding on the issue. This
commit is the fruit his enthusiasm spawned.
Closes https://github.com/awesomeWM/awesome/pull/538.
Before this, we grabbed the keys on the frame window. That meant we only got key
events for things that nothing else grabbed directly on the key window.
After this, we grab directly on the client window itself and so we "fight" with
everything else which wants to grab keys. I don't actually know how the winner
is decided... First come, first serve, the rest gets an error?
Signed-off-by: Uli Schlachter <psychon@znc.in>
The bit that indicates that the base size is set is
XCB_ICCCM_SIZE_HINT_BASE_SIZE. However, instead this code checked
XCB_ICCCM_SIZE_HINT_P_SIZE which is set to indicate how the initial window
position is chosen. So we were checking the complete wrong bit. Whoops...
Fixes: https://github.com/awesomeWM/awesome/issues/456
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of comparing only the top-left corner of the screen to the provided
coordinate, this now compares the screen in a more intuitive way, e.g.
coordinates inside of the screen have a distance of zero.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Together with the previous changes, this also fixes the initial positions for
metacity's test-gravity.c.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Whenever client.focus == nil, we set the input focus to the root window to
express "nothing has the input focus". However, thanks to the way X11 input
works, this means that whatever is under the mouse cursor gets keyboard input
events. This can easily be reproduced with urxvt and some small addition to the
config to unfocus things.
This commit changes things. Instead of focusing the root window, we create a
special "no focus" window that gets focused if we want nothing to have the
focus.
Closes https://github.com/awesomeWM/awesome/pull/470.
Signed-off-by: Uli Schlachter <psychon@znc.in>
From http://standards.freedesktop.org/wm-spec/latest/ar01s05.html:
> _NET_WM_STATE_FULLSCREEN indicates that the window should fill the
> entire screen and have no window decorations. Additionally the Window
> Manager is responsible for restoring the original geometry after a
> switch from fullscreen back to normal window. For example, a
> presentation program would use this hint.
awesome prefers fullscreen internally already. With this patch, the
previous maximized state will be restored after leaving fullscreen mode.
Fixes https://github.com/awesomeWM/awesome/issues/245.
Closes https://github.com/awesomeWM/awesome/pull/418.
This adds luaA_getopt_integer, luaA_optinteger and luaA_checkinteger.
Lua 5.2 does not have support for this, but it would be available in Lua
5.3.
Closes https://github.com/awesomeWM/awesome/pull/320.
This will skip calling `client_resize_do` in case of honored size hints.
This could be also done in `client_resize_do`, but it appears to be
meant to force the resize.
Closes https://github.com/awesomeWM/awesome/pull/383.
While debugging #331, I have noticed that the call to `client_resize`
might have changed the screen (and emitted the signal) already, via
a call to `screen_client_moveto` with `doresize=False`.
Closes https://github.com/awesomeWM/awesome/pull/332.
Instead of `client.client`, the client object is now referred to as
`client.object` and the client class as `client.class`.
This moves the documentation of `client.focus` to the class.
Closes https://github.com/awesomeWM/awesome/pull/349.
Calling lua_tostring() on a number/integer, turns that stack slot into a string.
This patch changes the code to only call lua_tostring() if the function argument
really is a string.
This partly also caused https://github.com/awesomeWM/awesome/issues/238.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Emmanuel Lepage Vallée
Daniel Hahler
Kazunobu Kuriyama
Daniel Hahler
Julian Wollrath
Peter Junos