This made it easier to figure out where a file causing an error was
coming from, but I could imagine that this could become too noisy, and
that there is/should probably be a more streamlined way to enable more
verbose logging / error output.
When loading persistent properties for a client, the loop value wasn't used,
but the original/requested property. This would only get triggered when
using more than one persistent client property (the default is one,
"floating").
That commit made awful.tag use timer.delayed_call() to call withcurrent() during
the manage signal. The idea was "if nothing else assigns any tags until the end,
apply some default ones".
However, the C core refuses to set the input focus to an unviewable client and
thus this means that setting the input focus during manage failed. So, instead
of using the delayed_call(), just call withcurrent() directly, like we did
before.
However, some part of that commit is still left: Awful.rules no longer
disconnects the withcurrent() callback from the "manage" signal. This was
originally added in commit 5e7ddd1efa, because it clients flickered otherwise if
they were moved to some unselected tag during "manage". This happened because
the C code unbanned the client when it got assigned the input focus and only
later did some other code move it to some unselected tag.
However, this flickering will no longer occur, because commit 3dbf89c990 added
lazy focus setting. Thanks to this, setting the focus no longer unbans a client
as a side-effect. Thus, if you focus a client and then remove it from all
selected tags, nothing will be visible on-screen.
To make a long story short: This commit reverts the part of commit 90fde1393f
which caused side effects. The part that wasn't necessary any more is left in.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This way this function runs after everything else did its job. The client will
only get assigned a tag after everything else had a chance to do so.
Thanks to this, awful.rules no longer has to disconnect the call to withcurrent.
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>
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>
Daniel Hahler
Roy Crihfield
Uli Schlachter
Alexis BRENON
Rastislav Barlik
Da Risk
findkiko