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>
Our tag concept doesn't really fit into ewmh. Thus, we were setting this
property to a way too small value anyway (just the size of the first screen in
case of multiple screens).
Since this property is optional in ewmh, let's just drop it.
Signed-off-by: Uli Schlachter <psychon@znc.in>
If $SHELL is set to "bash", previously awesome failed to restart itself, because
it could not find "bash". This commit makes awesome use execlp() instead of
execl() which means that $PATH is searched if the started command does not
contain a slash and this problem is fixed.
$SHELL is specified in POSIX and it doesn't seem to require an absolute path
name.
Signed-off-by: Uli Schlachter <psychon@znc.in>
At least debian uses "ldoc" for the binary name instead of "ldoc.lua" while
upstream seems to prefer the later...
Signed-off-by: Uli Schlachter <psychon@znc.in>
Thanks to Michael Stapelberg, there is now a xcb-only port of libXcursor which
does everything we need. This patch switches awesome over to that new library.
Since the only reason for using XOpenDisplay() instead of xcb_connect() was so
that we can use libXcursor, we can get back to that older state again. This
means that this effectively reverts the following commits:
531f8b415c "Added initial support for Xlib cursor themes"
77243cd09a "Add x11-xcb to the pkg-config checks"
779d43fc46 "Don't let Xlib own the event queue"
03759b4847 "Fix keyboard layouts"
Signed-off-by: Uli Schlachter <psychon@znc.in>
We no longer have to turn the client's content into an image buffer "by hand".
Instead, we can just use cairo for the job.
Even more exciting, we don't need to turn this into an image buffer at all. We
can just directly return a cairo xcb surface for the client window. Depending on
how lua will use this surface, this could make it possible to avoid having to
create the image buffer at all!
Signed-off-by: Uli Schlachter <psychon@znc.in>
The size saved in c->geometry also includes the titlebars. Thus, for getting the
window content, we have to subtract this from the size.
Before this, the call to xcb_image_get() was failing with a BadMatch error,
because we were asking for an area that is outside of the actual client's
window's geometry.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit adds and uses wibox.layout.base.fit_widget(). This function is a
wrapper for widget:fit() that caches the result and thus speeds things up.
This is necessary because some layouts call :fit() from their :fit() and :draw()
functions. Nesting such layouts means that at the widget at the tail of the
stack gets its :fit() function called quite often. If this function is not
blazingly fast, this results in noticeable slowness.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I noticed high CPU usage while using asunder. The reason was that asunder
re-sets its window name every 0.1 seconds (and awesome's drawing code is way too
slow).
A semi-fix for this is to ignore string property changes if the old and new
value for the property are equal.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We do some special magic so that we can have tracebacks on errors messages.
However, the code for parsing the rc.lua called it without this magic and thus
errors didn't have tracebacks.
This is bad, because if something goes wrong in e.g. wibox.widget.textbox, you
don't really have any clue where this error is coming from.
Fix this by adding our "print traceback on error"-magic here, too.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Well, whoops. There is no .bg property on wiboxes for quite a while already, it
is now a :set_bg member function.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, awesome didn't move windows when they sent a ConfigureRequest (and
it also shrunk them by the size of titlebars, before it forgot to add these).
This commit adds proper gravity support to ConfigureRequest handling.
This was tested with test-gravity from metacity (in src/wm-tester).
Signed-off-by: Uli Schlachter <psychon@znc.in>
This event should contain the position of the top-left corner of the client's
content area. Thus, we have to add the border width to the position.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This reverts commit bd8158495e.
The idea was to track the current list of pressed and depressed mouse buttons,
because we get button events for more than 5 buttons, but can only query the
state of the first 5 buttons.
However, there are cases where we see button presses, but won't see the
corresponding release event. This is quite bad.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since only the body text of a notification may contain markup,
by combining the two together and calling set_markup(), the
title would also get interpreted as if it had markup.
This could be seen with:
$ notify-send "Title & text" "<i>body text</i>"
The unescaped & would get interpreted as broken markup and so
naughty would fall back to escaping everything which would make
the "<i>" tags be shown rather than interpreted.
So, the title must always be escaped so that it is not interpreted
as markup.
Signed-off-by: Ross Lagerwall <rosslagerwall@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
The flex:fit() function was calling the fit() function of the widgets it
contained with too large values, trying to hand out more space than it had
available. This resulted in more space being requested than was available and
some weird layout issues resulted.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The old code had flaws:
* If the tag chnaged screen, the code was unstable.
* If awful.tag.del was used, then it displayed an error
* If tags were added later, the keyboard shortcut were unavailable
Since commit d8a93dafa3, tags have an "index" property which decides about
the order in which they are displayed in the taglist. If a tag doesn't have this
property set, the next call to awful.tag.gettags() will fix this and "invent" an
index for this new tag.
However, if multiple tags didn't have an "index" property, gettags() would
assign all of them the same index. The following call to table.sort() would then
do random magic to these tags (remember: table.sort() is not a stable sorting
algorithm, so it is allowed to randomly swap around entries which have the same
sorting key).
Fix this by making sure that the new "index" properties are different from each
other.
Signed-off-by: Uli Schlachter <psychon@znc.in>
heithe
Uli Schlachter
David Mohr
Björn Åström
Alexander Kondratev
kardan
Ross Lagerwall
Emmanuel Lepage Vallee
Jo De Boeck
Poggles