This adds functions for getting directories according to the XDG base dir
specification. This might be useful in general.
This also adds a function for getting the cache dir, because I like an explicit
function call more than something which "switches" based on a string argument.
Better error messages if you mis-type something. :-)
Finally, this adds a function for getting the directory containing the rc.lua
file. Sadly, awful.util.getdir("config") did not actually do that. See #218.
Fixes: https://github.com/awesomeWM/awesome/issues/218
Signed-off-by: Uli Schlachter <psychon@znc.in>
Without this fix `wibox.widget.textbox` ignores current theme font
setting and resets it to the initial one.
It becomes handy when the initial theme is tweaked during runtime, ie.
in `rc.lua`. Other AwesomeWM components like `awful` (taglist,
tasklist, menu) are aware and do respect the actual theme settings.
Closes https://github.com/awesomeWM/awesome/pull/89.
Lua will remove objects as values from a weak table before these objects are
finalized, but as values only in the next garbage collection cycle after the
object was finalized. Up to now, gears.object uses a table with weak keys so
that :disconnect_signal() works. This means that a signal can still call methods
which were already considered garbage by the garbage collector and thus can use
userdata from the C side which was already finalized. Crashes and other bugs
result.
This commit changes the code so that the function is also a value in the weak
table. Thus, the GC will remove the entry before the object is finalized.
Special magic is needed for Lua 5.1, because there only userdata has the
behavior that we want while we have a function. We do some magic with function
environments to make this work...
Closes https://github.com/awesomeWM/awesome/pull/567.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a cyclic dependency between the function used for the weak signal and
an object with a __gc metamethod. The problem occurs since the GC will first
finalize the object (call its __gc metamethod) and only in the next generation
will it actually collect the garbage and remove the functions from weak-tables
using it as a key.
And yes this needs special code for Lua 5.1 because there __gc doesn't work on
tables. :-(
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since weak signals specifically exist to do magic with the garbage collector, do
a couple of garbage collection cycles and verify that this does not disconnect
the callback function prematurely (the function is kept alive since it is a
local variable).
(I actually did a mistake that makes this enhanced test fail and fixed it before
committing)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Most of this information isn't interesting. If you are getting awesome from a
distro, then the time, hostname and username of the build are likely 'random
stuff' and if you are building awesome yourself, then the hostname and username
are obviously yours and the time can still be interfered based on the awesome's
binary ctime.
The GCC version shouldn't make any difference at all.
Closes https://github.com/awesomeWM/awesome/pull/566.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When emitting layout_changed, the widget is relayouted. If this doesn't actually
change anything, nothing will be redrawn. Thus, this also emits redraw_needed to
force redraws.
This fixes a race condition with some weird tray icons. A new tray icon is
created and the systray is updated. Then this new icon is destroyed immediately
again and at the same time another icon is created. Then, the systray isn't
updated since the number of icons (=the layout) did not actually change.
However, it needs to be updated and so we ended up with broken/missing icons.
Fixes: https://github.com/awesomeWM/awesome/issues/487
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only exception is the window for _NET_SUPPORTING_WM_CHECK. That window
already had a _NET_WM_NAME property before and doesn't get a WM_NAME property in
this commit. I just decided for myself that it doesn't need one. :-)
Right after startup with the default config we now have the following situation:
$ xwininfo -root -tree
xwininfo: Window id: 0x2d7 (the root window) (has no name)
Root window id: 0x2d7 (the root window) (has no name)
Parent window id: 0x0 (none)
7 children:
0x200011 "Awesome drawin": ("awesome" "awesome") 1500x20+0+0 +0+0
0x200010 "Awesome drawin": ("awesome" "awesome") 1x1+0+0 +0+0
0x20000d "Awesome drawin": ("awesome" "awesome") 100x30+0+0 +0+0
0x20000a "Awesome no input window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200009 "Awesome systray window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200008 "awesome": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
0x200007 "Awesome WM_Sn selection owner window": ("awesome" "awesome") 1x1+-1+-1 +-1+-1
One of those drawin is the awful.wibox. Another drawin is created by awful.menu.
I guess that the third one is created by awful.tooltip, but I'm not sure. Wow,
so many windows...
Closes https://github.com/awesomeWM/awesome/pull/556.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is a weak table whose entries might be removed by the garbage collector.
I'm not sure if this will every cause problems, but it's better to be prepared
for tables having "nil holes" (which would mean ipairs ignores some entries).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code already tried to handle this correctly, but at some point it used the
wrong variable as the screen number...
Signed-off-by: Uli Schlachter <psychon@znc.in>
Example:
awful.prompt.run({ prompt = "Run: ", hooks = {
{{ },"Return",function(command)
local result = awful.util.spawn(command)
mypromptbox[mouse.screen].widget:set_text(type(result) == "string" and result or "")
return true
end},
{{"Mod1" },"Return",function(command)
local result = awful.util.spawn(command,{sticky=true})
mypromptbox[mouse.screen].widget:set_text(type(result) == "string" and result or "")
return true
end},
{{"Shift" },"Return",function(command)
local result = awful.util.spawn(command,{ontop=true,floating=true})
mypromptbox[mouse.screen].widget:set_text(type(result) == "string" and result or "")
return true
end}
}
},...)
Imagine the following snippet is run:
keygrabber.run(function(mod, key, event)
gears.debug.dump{mod, key, event}
end)
The above starts a keygrabber and prints the events that are received.
Currently, when a key is pressed and held down, this prints a series of press
and release, because that's what the X11 server sends us.
This commit enables detectable autorepeat. This means that the X11 server only
sends us a series of press events for autorepeat and a single release when the
key really is released.
Testing this is a bit hard, because detectable autorepeat does not seem to work
with Xephyr. Instead, a "real" Xorg instance is needed.
We do not check the response to the PerClientFlags request, because it doesn't
really tell us anything useful. If the server does not support detectable
autorepeat, we could print a warning, but so what? As I just said, this does not
work in Xephyr and yet Xephyr announced to support this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In XCB, each request has a checked and an unchecked version. The checked version
can be used to check if the request caused any errors. Since the code here
doesn't do this check, it shouldn't use the checked versions of the requests.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When using `spawn` without startup notification support, the
`startup_id` property on the client should be nil.
This adds rxvt-unicode to the Travis build, because it supports startup
notifications, but xterm does not. We should replace xterm with it in
the existing tests then later.
The ID for startup notification is transmitted to the spawned process via the
DESKTOP_STARTUP_ID environment variable. Before this commit, we set this
variable in the main process. This meant that if we started something "without"
a startup id, then it might get the ID that was used by the last spawn and which
was still saved in our env. Fix this by setting the environment variable only
after fork().
Small anecdote: The above wasn't enough to make Daniel's test case succeed and
at first I couldn't figure out why.
Turns out that rxvt-unicode doesn't unset the DESKTOP_STARTUP_ID environment
variable (I think it should, according to some spec), even though it supports
startup notification. So awesome was already started with DESKTOP_STARTUP_ID set
and thus all spawned processes used this ID.
Fix this by explicitly unsetting DESKTOP_STARTUP_ID if we don't set any new
value (even though this breaks encapsulation; we shouldn't have to care about
this "implementation detail" of libstartup-notification).
Signed-off-by: Uli Schlachter <psychon@znc.in>
Uli Schlachter
Daniel Hahler
actionless
Barlik
ShadowKyogre
dyslesiq
▟ ▖▟ ▖
Frederik
Daniel Hahler
Emmanuel Lepage Vallee
Benjamin Petrenko