In various conditions, luaA_loadrc() left luaA_dofunction_on_error and an error
message on the Lua stack. Also, it used LUA_MULTRET without looking at the
return values. Fix all of this and reorder the code a bit to make it easier to
follow.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The Lua stack is a finite resource and everything that pushes something there
should also clean up. This is not a problem for functions that are called by
Lua, because their "stack frame" is freed when they return. However, in global
context, Lua does not and cannot automatically clean up for us. Thus, it makes
sense to print a warning in this case.
(Additionally, this cleans up the stack if something is left)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since commit b2aaefd095, we correctly handle window gravities when
the border width of a client changes. Since most windows out there have a
NorthWest gravity, this means that most windows do not have this problem.
However, e.g. mplayer uses gravity "Static" and this causes this issue (any
gravity other than NorthWest will do).
This affects the fullscreen handling in awful.ewmh. The code has to set the
border width before it changes a client's geometry so that the move when the
border width changes doesn't matter.
No new integration test for this since I didn't find anything usable with a
non-NorthWest gravity. A test would be easy to write, just test if `c.fullscreen
= true ; c.fullscreen = false` restores the previous window geometry.
Fixes: https://github.com/awesomeWM/awesome/issues/697
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
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>
Commit ff799a0f5d is incomplete. It changed the window on which we grab
keys, but only in some places. When the keyboard layout changes, we have to
re-grab these keys, but the code does so on the wrong window.
This patch fixes that oversight.
Fixes: https://github.com/awesomeWM/awesome/issues/639
Signed-off-by: Uli Schlachter <psychon@znc.in>
When there are multiple X11 screens (i.e. :0.0 and :0.1) for zaphod mode
style X setups, this triggers a refresh of focus when the instance
running on a particular root receives the mouse
Fixes https://github.com/awesomeWM/awesome/issues/599.
This property is especially useful for client objects which are unusable after
unmanage. "Unusuable" here means that pretty much everything you do with the
client object results in a lua error.
Syntax is c.valid.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The ID for startup notification is transmitted to the spawned process via the
DESKTOP_STARTUP_ID environment variable. Before this commit, we set this
variable in the main process. This meant that if we started something "without"
a startup id, then it might get the ID that was used by the last spawn and which
was still saved in our env. Fix this by setting the environment variable only
after fork().
Small anecdote: The above wasn't enough to make Daniel's test case succeed and
at first I couldn't figure out why.
Turns out that rxvt-unicode doesn't unset the DESKTOP_STARTUP_ID environment
variable (I think it should, according to some spec), even though it supports
startup notification. So awesome was already started with DESKTOP_STARTUP_ID set
and thus all spawned processes used this ID.
Fix this by explicitly unsetting DESKTOP_STARTUP_ID if we don't set any new
value (even though this breaks encapsulation; we shouldn't have to care about
this "implementation detail" of libstartup-notification).
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
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>
The previous commit added some variables and this commit makes the surrounding
code use these new variables as well.
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>
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>
There is a client window C. Around this window, awesome adds a frame window F.
When the pointer is inside of C and then moves inside of F, we get a LeaveNotify
with detail=Inferior, but from our point of view, the pointer is still inside of
C, because F is contained in C.
Similarly, if the pointer is in F and moves to C, we get an EnterNotify with
detail=Inferior that we should ignore. However, for an EnterNotify the pointer
can now be inside of a titlebar, so this case has to be handled now.
The above explains the enter/leave behavior for clients. Let's now think about
titlebars: When the pointer moves from C to F, it cannot be in any titlebar any
more, so we must generate a leave event on that titlebar. Similar when the
pointer moves from F to C, but in this case we also have to figure out which
titlebar now contains the pointer.
This patch makes the code handle these events with detail=Inferior correctly.
Closes https://github.com/awesomeWM/awesome/pull/461.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a global variable that tracks the drawable that is currently under the
mouse cursor. This new variable is then used so that we get consistent behavior
for enter/leave signals. Such signals are now also generated when a MotionNotify
event tells us that the pointer is now in a different titlebar.
Before this, it was possible that we did not generate a leave event on a
titlebar since the LeaveNotify contains the cursor position after the leave and
we did not manage to figure out which titlebar was left.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is not only useful for soft restarts, but also when TERMinating
awesome during development/testing.
The drawback appears to be that it would leak a property on the root
window in case it is really meant to be quit.
Closes https://github.com/awesomeWM/awesome/pull/374.
This saves the order of clients in a property called AWESOME_CLIENT_ORDER on the
root window during shutdown. During startup, after managing all existing
windows, we force the client list into the order described by this property
(overwriting any changes that Lua possibly did).
This code should safely handle cases where the property doesn't contain all
existing clients or contains a client which doesn't exist anymore.
Signed-off-by: Uli Schlachter <psychon@znc.in>
ReparentWindow puts the window at the top of the stacking order. Thus, we have
to reparent clients back to the root window in the stacking order.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This improves the behaviour with print()ing for debugging, when the
output is redirected to a file.
I was using `setbuf(…, 0)` initially, but it makes sense to buffer it
per line. This uses `setvbuf` instead of `setlinebuf`, which might not
be available everywhere.
Closes https://github.com/awesomeWM/awesome/pull/267
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>
The motivation behind this patch is my distro moving to a multiarch
layout. While binaries, libraries, etc. are are installed into
/usr/{host}/{bin,lib,...} architecture-independent data should still
go to /usr/share.
When minimizing a client, we temporarily ignore events for the client window (so
that we don't get the UnmapNotify event that we are causing for the unmap) and
for the root window (I don't actually know why, no "harmful" events should be
caused...).
However, we weren't ignoring events on the frame window itself. This commit
fixes that oversight.
The problem here is that the pointer could be inside the window that is being
minimized. When we then unmap said window, the pointer will now be inside of the
frame window and the X11 server will thus generate an EnterNotify. When we
handle this event later on, we emit mouse::enter on the client and e.g. the
default config then focuses this client, which undoes the minimization.
This fixes a regression introduced in commit 3aeac3870c and fixes#92.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reparents all clients back to their proper position during shutdown, so
that their top-left corner is now where their titlebar's top-left corner was.
Hopefully, this fixes floating clients moving around across a restart.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Let's just quote a mail I received from Rastislav Barlik:
I tried to make use of awful.mouse.finder but I found out that it's not working
as supporting functions rounded_corners were removed with commit
03e0ee53d2.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Because ICCCM pretty much mandates that minimized (aka "iconic") clients are
unmapped. In detail: To go back to normal state, the client should map its
window and for this to work, the window needs to be unmapped.
Thanks to Oleg Shparber for reporting some issue he had with a self-written Qt
program and for providing a simple and short test case.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously we would get a short black flicker when a client closes. This
happened because first the client's window would get hidden and only a short
moment later would awesome react to this and close its own window. In the mean
time, the X server filled the frame window with its background-pixel which was
black.
Just removing the background-pixel means we get the default value which is None.
This means that the content will be left untouched and the client's window will
be visible for a moment longer.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fun fact: ICCCM specifies that icon_pixmap must have depth 1. Xterm uses a
pixmap with depth 24. Yay... As such, I don't have any test for the depth == 1
case and will just assume that it does the right thing. If it doesn't, I bet no
one will notice anyway.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Conflicts:
property.c
I never saw a single program that set a border on its own windows. However,
awesome commonly sets borders on its clients and the position of a client is the
part outside of the border. So when processing a position request from a client,
we also have to include this border and fix things up correspondingly.
However, the same isn't needed for the client size, because the size does not
include the borders, but just the titlebar plus the "real" client content.
Thanks to Daniel Hahler for providing a simple test case based on urxvt for
debugging this!
Signed-off-by: Uli Schlachter <psychon@znc.in>
This patch allows 2 things to be done:
* Write unit test to validate layouts using fake clients and tags
* Query the current layout geometry from another tag
The advantages of the former are clear and simple. Those of the later include:
* Creating a screenshot of another layout
* Display the layout wireframe in the tag list (like KDE2-3, Gnome2)
* Having and 'ALT-tab' like visual popup for tags
* Move the "index" setting burden to individual functions
instead of gettags().
* Add some properties earlier so the signal hooks will be called
with valid data.
Uli Schlachter
Roy Crihfield
Kimball Thurston
Daniel Hahler
Kazunobu Kuriyama
▟ ▖▟ ▖
Heiko Becker
findkiko
Emmanuel Lepage Vallee