Having many arguments can easily get confusing and hard to understand. This
commit uses a table instead so that we have names that identify what each
callback does.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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>
_NET_WM_ICON contains a list of icons and until now, the first one was
picked without regard to it's size. This adds a global option to set
the preferred icon size. When getting the client icon, the best size
match is picked. The size can be set via
awesome.set_preferred_icon_size() and the default is 0, which will pick
the smallest non-zero size icon available.
Signed-off-by: Lukáš Hrázký <lukkash@email.cz>
This adds new functions to all widgets that allow to force a specific
width/height. These values override the result from :fit().
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>
This adds support for the callback that was added in the previous commit to this
function. We can just pass on the function that the caller gives us.
Fixes: https://github.com/awesomeWM/awesome/issues/185
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a new argument to awesome.spawn. This argument is a function that will
be called with the exit status once the spawned process terminates. For normal
exit, the function is called with "exit" and the exit code. If the process is
terminated by a signal, the function will be called with "signal" and the signal
number of the signal that caused termination.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This allows scrolling a widget if there is too few space available. There are
several different modes available for how the scrolling "looks like".
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.
Uli Schlachter
Daniel Hahler
actionless
Barlik
Lukáš Hrázký
ShadowKyogre
dyslesiq
▟ ▖▟ ▖
Frederik
Daniel Hahler
Emmanuel Lepage Vallee