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.
The old code transformed the top-left and bottom-right corner of the rectangle
to device space and calculated a rectangle based on these two points. However,
if you rotate a rectangle by 45°, these two points will be directly above each
other and thus the old code would calculate a width of 0.
Fix this by transforming all four corners of the rectangle into device space and
calculating a rectangle based on this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fixes the following code:
local d = drawin({})
d.visible = true
The drawin now has a cairo surface assigned
d.visible = false
d.width = 1234
d.visible = true
The width change while the drawin was not visible would not get propagated to
the drawable because of the code that this patch removes. The expectation was
that drawin_map() would update the drawable later.
However, because the drawin was already visible, its drawable also already has
a surface assigned. Thus, drawin_map() wouldn't update the drawable either.
Fix this by just removing this optimizations.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Roy Crihfield
Kimball Thurston
Daniel Hahler
Kazunobu Kuriyama
▟ ▖▟ ▖
Heiko Becker
findkiko
Emmanuel Lepage Vallee