This commit makes awesome measure how long all the event handling takes. That
is, this measure the time between waking up from poll and going to sleep again.
If that time is above 0.1 seconds, we print a warning and increase the limit for
this warning to the last duration to avoid flooding messages.
This should help figuring out cases were people do stupid things in their
config, like synchronously contacting an IMAP server and getting the number of
unread mails.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit 20afb26080.
The commit caused endless loops with tracebacks like this (shortened):
lib/awful/ewmh.lua.in:122: in function <lib/awful/ewmh.lua.in:117>
[C]: in function 'geometry'
lib/awful/ewmh.lua.in:122: in function <lib/awful/ewmh.lua.in:117>
[C]: in function 'geometry'
lib/awful/ewmh.lua.in:122: in function <lib/awful/ewmh.lua.in:117>
[C]: in function 'geometry'
Turns out that my rant about "we can't query the pixmap's values" was wrong.
This commit makes awesome use a GetGeometry request to get the properties of the
(old) root window's back pixmap.
This also converts code to p_delete() instead of free() for consistency. Bad me
for doing multiple things in one commit...
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a client's geometry changes (and I consider the border width to be part of
the geometry here) and that client is one of fullscreen or
maximized_{horizontally,vertically}, make sure that the geometry as specified by
the state is still obeyed.
This also (accidentally) fixes things when a client gets moved to another
screen!
Signed-off-by: Uli Schlachter <psychon@znc.in>
Due to a copy&paste error, maximized_vertical and maximized_horizontal were
handled the same. Of course, vertical and horizontal aren't the same direction.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When we receive a _NET_ACTIVE_WINDOW request on the root window, we used to just
focus and raise the window. This didn't do much for clients which are on
non-selected tags.
Thus, this commit makes awesome emit request::activate on the client instead.
This is used in awful.ewmh to implement the old behavior again, but with
additionally marking the client as urgent if it isn't visible.
People who don't like this behavior can use client.disconnect_signal to disable
this behavior again. To make this really possible, awful.ewmh becomes a
"non-nil" module.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We detect other WMs when we fail to request SubstructureRedirect on the root
window. Previously, the code used an unchecked request and then tried to
cleverly detect if an error occurred. This isn't needed.
Instead, we now use a checked request and use xcb_request_check() to see if any
errors were generated. This also gets rid of a round-trip to the server (one is
still implicitly done by xcb_request_check()).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the drawable paint the wallpaper in the background
(i.e. pseudo transparency) only if there is not a composite manager running,
as reported by the value of awesome.composite_manager_running.
In other words: drawables can now make use of true transparency.
Signed-off-by: Björn Åström <bjoast@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
The default value for the second argument to :find() is 1, so nothing is changed
here. The third arguments disables pattern matching and instead gets us literal
interpretation of strings. This means that pattern characters like e.g. [, ] and
. don't get interpreted.
Signed-off-by: Massimiliano Brocchini <massimiliano.brocchini@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
When an area is split in two, for example horizontally, one of the windows
should have height math.floor(previous height / 2) and the other
math.ceil(previous height / 2), to be certain that no gaps are left between the
windows.
For instance, if the first window has height h and the second window has height
math.floor(h / 2), the height of the third window should be math.ceil(h / 2)
instead of the same as for the second window.
So to compute the size of window n + 1 it’s necessary to remember the size of
window n - 1 as well as that of window n.
Signed-off-by: Fabienne Ducroquet <fabiduc@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a :set_color() method so that the margin layout can color the margins,
drawing a bordered widget.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This gets rid of the unused first argument and adds a new second argument that
can influence individual items.
Signed-off-by: Uli Schlachter <psychon@znc.in>
A drawin's and a client's bounding and clip shape can now be queried and is
returned as a cairo surface. Also, a client window's shape (e.g. xeyes setting
its own shape) can be queried via c.shape_client_bounding and
c.shape_client_clip. All of these properties now emit signals when changed.
(This also silently fixes a bug in luaA_drawin_set_shape_bounding() which forgot
to include the drawin's border in its size calculation)
Signed-off-by: Uli Schlachter <psychon@znc.in>
The documentation says that screen, the last argument to viewmore(), is an
optional argument. However, the implementation only treated it as an optional
argument in one place.
Fix this by always setting the screen variable itself to a screen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Label of menu entries will be escaped automatically. Doing it manually
in menu:clients() will escape it it twice.
Patch removes the util.escape() call in menu:clients()
Signed-off-by: Enrico Scholz <enrico.scholz@informatik.tu-chemnitz.de>
Signed-off-by: Uli Schlachter <psychon@znc.in>
The activated property was added to tag objects between awesome 3.4 and 3.5.
This is used in the C code to keep tags alive even when nothing else refers to
it and includes a tag e.g. in some root window properties.
Thus, to get rid of a tag and to make the C code drop its reference to it, we
have to set activated to false in this function.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in property_update_wm_transient_for() looked at the transient_for
relation before the new transient got set. However, the code is supposed to
check if we get a loop after introducing this new transient_for.
Thus, if we arrive back at the client that we started from, we can be sure that
there is a cycle. Signal this by setting the loop counter high enough to abort
the loop and make the rest of this function do nothing.
No idea how I missed this case before nor why I cannot reproduce this on debian,
but can reproduce it on Arch just fine.
Reported-By: Kasimir Knallkopf at http://article.gmane.org/gmane.comp.window-managers.awesome/10415
Signed-off-by: Uli Schlachter <psychon@znc.in>
In case loading the theme failed and we don't have fg_normal or bg_normal, add
default values for these properties. All the other colors are only used if they
are defined, but these two always need to be defined.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When awesome restarts because a new screen was added or removed, clients can end
up being on a different screen than before the restart. However, the tags will
be carried across the restart. This means that a client could end up being
tagged with a tag from another screen. This results in weird behavior of tag
switches and confuses users.
To work around this, remove the client from any tags that are on a different
screen during startup. If the client ends up without any tags, it will then be
tagged with the currently selected tags.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The above-mentioned bug report says that a window cannot be moved via its
titlebar if you move the move quickly while clicking.
The reason for this was awesome's "event compression": We don't handle all
MotionNotify events, because they can come in big quantities. Instead, we only
want to handle the latest one and ignore all earlier ones (the mouse isn't in
that position anymore anyway).
The problem now appears if a MotionNotify is moved across a ButtonPress event
and the ButtonPress is what should cause the window to be moved. Awesome first
handles the ButtonPress event normally and starts grabbing mouse input. Then,
our event loop feeds us with an old MotionNotify event in which the button was
not pressed yet. The code for moving clients gets a motion event in which no
mouse button is pressed, concludes that the move is done and ungrabs the mouse
again, even though the button is still physically pressed.
Fix this by making sure that MotionNotify events are never moved across
ButtonPress or ButtonRelease events. We already did this for EnterNotify and
LeaveNotify events for similar reasons.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit c3bca6ac34.
This caused problems where clients would always spawn on the top-left screen and
couldn't be moved around. This was because lua placed them on the other screen,
but when the titlebar got added, their top-left corner was moved over again.
This kind of forces every client to have a window gravity of "static".
This fixes most of the problem of clients moving around across restarts due to
the titlebar. What is left is that they move due to the border width which
should be handled in another patch. Also, another patch should make this honor
the client's actual window gravity.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We did some black magic which broke and was replaced with more black magic. This
now broke using screen objects as table indexes:
$ echo 'local l, s = {}, screen[1] ; l[s] = 42 ; return l[s]' | awesome-client
double 42
$ echo 'local l, s = {}, screen[1] ; l[s] = 42 ; return l[screen[1]]' | awesome-client
<no output>
Fix this by using just a single lua userdata for representing a screen object.
It would be even better if screens were allocated with lua, but that doesn't
really provide any benefits right now and would be more complicated...
Signed-off-by: Uli Schlachter <psychon@znc.in>
Lots of code assumes that it can recursively follow a client's transient_for
field until it reached an end without a transient_for client. Instead of fixing
all those places to properly handle loops, this patch just makes us ignore
WM_TRANSIENT_FOR if the property causes a loop.
This means that it can be a little random which WM_TRANSIENT_FOR property is
ignored, because it will always be the one that happens to complete the cycle. I
don't think that this is bad, because there shouldn't be any loops in the first
place.
Lots-of-kudos-to: David Mohr <david@mcbf.net>
Signed-off-by: Uli Schlachter <psychon@znc.in>
I am looking forward to the bug reports requesting awful.client.floating.set(c,
true) to also automatically un-fullscreen the client...
Signed-off-by: Uli Schlachter <psychon@znc.in>
Setting mouse.screen moves the pointer to the top left corner of that screen.
However, the very next line would then move the pointer elsewhere again. Thus,
the first one wasn't needed at all.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For setting up the wallpaper, awesome needs a second connection to the X11
server (isn't SetCloseDownMode just great?).
However, it was possible to have a dead-lock with our main connection due to
this. Awesome does a GrabServer during startup so that nothing else can use the
X11 server while we set ourselves up. The server is ungrabbed right before the
lua config is read. However, nothing makes sure that this ungrab request really
is sent to the server instead of just waiting in xcb's output buffer.
The dead-lock would now happen if we try to establish a second connection to the
X11 server before the ungrab request was flushed on the main connection. The
server will wait for the ungrab on the first connection, awesome is waiting for
the second connection to be successfully established.
Fix this by making sure the UngrabServer request is flushed before parsing the
config file.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The last widget always took up the remaining
space even though fill_space(false)
had been called on the layout.
This got broken in commit 9d333113dd.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It is possible to configure RANDR so that no outputs are available. This means
awesome would be running with zero screens which leads to all kinds of
funnyness.
Work around this by falling back to other configuration mechanisms if we get no
screens from one of them. After all, screen_scan_x11() will always be able to
add a screen.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Björn Åström
Massimiliano Brocchini
Fabienne Ducroquet
Rocco Aliberti
Enrico Scholz
Jan Larres
heithe
David Mohr
Alexander Kondratev