Apparently I still had an old naughty.lua laying around in build/lib and thus
this new code wasn't actually tested. It's a miracle that it works so well
besides this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The new notification action code tried to emit dbus signals even if awesome was
build without notification support. Fix this by adding the necessary "if".
(This also removes an unused return value which wasn't marked as "local" and
thus triggered my "complain if something messes with the global env"-script)
Signed-off-by: Uli Schlachter <psychon@znc.in>
The whole point of this pcall() is that we do not have unprotected Lua errors,
because those kill awesome. So instead of assert()ing, let's just print a
message.
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>
The desktop notification specification says that a notification can have
different actions. These actions allow the user to interact with the client
application and should be displayed by the notification server.
* Add function to emit a DBus signal
* Notifications : emit NotificationClosed signal when closing notification
* Notifications: use constant for notification closed reasons
* notifications: Implement notifications actions
This is just a basic implementation to display the actions send with the
notifications. The actions should be displayed differently
* Notifications: add support for default action
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>
Everything that needs the lua_State should create a local variable like this:
lua_State *L = globalconf_get_lua_State();
This ensures that the compiler warns if there are two variables with name "L" in
scope. The idea here is that it should become harder to accidentally use the
global lua state instead of the state of the current state.
While writing this commit, I found another place that gets its wrong: Reading
client.focus from a coroutine was broken, since it was returning the result on
the main thread instead of the current one.
Signed-off-by: Uli Schlachter <psychon@znc.in>
tag_client() said that it refers to the tag ontop of the lua stack. However, it
implicitly used globalconf.L as its stack. So if you tagged a client with a tag
from a coroutine, thinks would Go Wrong (tm). Fix this by adding an explicit
lua_State* argument.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This just pushed the drawin onto the stack L, but then tries to access it via
globalconf.L. This just calls for problems...
Signed-off-by: Uli Schlachter <psychon@znc.in>
A stack index without the corresponding lua_State pointer is useless, because it
could reference another coroutine than the main thread and thus just assuming
globalconf.L is wrong. Fix this by also passing around the corresponding
lua_State pointer.
This improves the result for the following test:
coroutine.resume(coroutine.create(function()
drawin({}).visible = true
end))
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
* 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 previous code assumed that pairs() iterates over the table in a specific
order which is not a safe assumption.
Signed-off-by: Uli Schlachter <psychon@znc.in>