Previously, awesome would just crash when execv() fails, because it already
destroyed all of its internal state, but then tries to do another main loop
iteration. Whoops.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For a minimized client, c:isvisible() is always false which is not what we want
here. So instead, unminimize the client before checking if it's visible.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a keyboard grab activate/deactives, the input focus jumps to the window
which does the grab. These FocusIn events sometimes managed to confuse awesome.
The symptom was that a newly mapped/started client didn't receive the input
focus:
- You press your key-combo to start a terminal. This activates a passive grab
and the input focus jumps to the root window
- The terminal opens and the "manage" rule does client.focus = c
- This doesn't set the focus yet, but instead causes
globalconf.focus.need_update = true and .client = new_terminal
- Before the focus is updated, the key combo is released and the focus jumps
back to the previously focused client
- The FocusIn with mode == Ungrab causes awesome to think that the previously
focused client got focused again and thus globalconf.client.focus gets re-set
to what it was before
- Finally the focus is refreshed and the previously focused client gets focused
The fix is simple: We don't need the FocusIn events which are generated when a
grab activates or deactivates, so we can just ignore them.
Thanks to Majic for reporting this to me.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a property is now set to a function, the function's return value will be
used for the value of the property. The function gets the new client as its only
argument.
There is no property which accepts a function as its value and thus this change
can't break anything (yeah, famous last words...).
This should fix half of FS#1011. Panels now don't get focused by awful.rules.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When something gives the input focus to the client which already has the input
focus, bad things can happen. Normally, you'd expect nothing to happen in this
case, but X11 is not that simple.
When updating the input focus and the focused client has the nofocus hint set,
we are actually taking away the focus from this client.
Hopefully this fixes FS#973.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, when we received a FocusIn event, we would update the input focus,
because client_focus_update set globalconf.focus.need_update to true.
However, this is wrong for clients following the globally active focus model,
because in this case its the client which controls which window has the input
focus. It could happen that we thus took away the focus from the client which
just gave itself the focus.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Without this, input handling is broken (draw_widget() registers each widget with
its position for input handling).
This also removes some unnecessary save()/restore() calls. Our caller (again
draw_widget()) already does that for us.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes tag.viewidx take a screen index rather than a screen object,
complying with its doc string. This fixes#963.
Signed-off-by: Felix Bier <flx.bier@googlemail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
Currently it takes `require('lgi.version')`, converts it blindly to
number and compares with another value.
I am using lgi v0.6.1 and that is not convertable to number value,
thus tonumber() returns nil and crashes Awesome.
The fix is to take major and minor numbers only ignoring the rest.
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
From 55eb706b698c3b0c59559eff342d6ee59ec9e3f3 Mon Sep 17 00:00:00 2001
From: Arvydas Sidorenko <asido4@gmail.com>
Date: Sun, 17 Jun 2012 15:11:01 +0200
Subject: [PATCH] Calling naughty.notify without specifing module
Lua 5.2 port bug, which shows up on notify-send
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
awful.wibox.tasklist was overwritting `tags` variable breaking all the
functionality which uses it.
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
Signed-off-by: Uli Schlachter <psychon@znc.in>
xcb_event_get_{request,error}_label() return NULL for non-core requests and
error codes. Obviously, that's not really helpful at all, so also print the
numeric information about what failed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For example, the rightmost pixel of a border-less graph wasn't draw and all
drawing was shifted one pixel to the left.
Signed-off-by: Uli Schlachter <psychon@znc.in>
behavior before: draw fg color everywhere and draw each value inverted as bg color.
if not enough values available "remove" the free area (draw a big rectangle with bg color over it).
behavior now: draw each value onto background as fg stroke.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In Lua 5.1 lua_open directly calls luaL_newstate, but was deprecated.
In Lua 5.2 lua_open was removed.
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
Lua 5.2 removed lua_[gs]etfenv and introduced
lua_[gs]etuservalue. Not sure though if it provides
the required functionality which awesome is using.
Thus, need some testing.
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
The original struct name is luaL_Reg, but Lua v5.1 had a
`typedef luaL_reg luaL_Reg`, which in v5.2 was removed
and as a result breaking the build in Awesome which uses luaL_reg
version exclusively.
Signed-off-by: Arvydas Sidorenko <asido4@gmail.com>
Uli Schlachter
Felix Bier
Ignas Anikevicius (gns_ank)
Arvydas Sidorenko
dodo