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>
Usually users want a wallpaper on all their screens. With the current code, this
resulted in a loop of upload-wallpaper, {download-wallpaper, add-new-part,
upload-wallpaper}*.
Fix this by being more intelligent: Instead of setting the wallpaper
immediately, this now uses gears.timer.delayed_call() to set the wallpaper. All
following modifications which come in before the delayed call runs will still be
part of the current update. This should mean that during startup, there is just
a single upload of a wallpaper.
(The above is what happens if there is no wallpaper yet. If there is already
one, we use :create_similar() and thus should only upload the part of the
wallpaper that changed, but this doesn't really make a difference.)
As a side-effect, the new code no longer draws to the old wallpaper to modify
it, but always creates a copy of it. This means that:
Fixes https://github.com/awesomeWM/awesome/issues/288.
Closes https://github.com/awesomeWM/awesome/pull/530.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Thanks to the way that X11 works, geometries consider the size of the client
without the border width, but the position of the top-left corner of the border.
This commit adds a new function get_area() which returns the area that is
actually covered by a client. Then, all the code is changed to use this new
function (even the part of the code which did get this border thing correct).
Closes https://github.com/awesomeWM/awesome/pull/541.
Signed-off-by: Uli Schlachter <psychon@znc.in>
None of this code wants to resize clients. Thus, it makes sense to only set the
position of a client and ignore its size.
Also, this sneaks in a fix for no_offscreen which is documented to return the
client's new position, but didn't actually do so.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is an enhancement to make non-ASCII symbol keys usable for
implementation and configuration of Awesome.
The enhancement was proposed and had been developed under the
initiative of Daniel Hahler. Thanks to his sharing of his results with our
community, we gradually deepened our understanding on the issue. This
commit is the fruit his enthusiasm spawned.
Closes https://github.com/awesomeWM/awesome/pull/538.
This makes the timer emit signals for when it is started and stopped. This does
not add a signal for :again(), because that function just calls the other two
functions and thus already emits start and stop.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This changes the code in naughty so that it first decides on a width for the
notification and then uses the new function :get_height_for_width() to find a
suitable height.
This makes a difference in the following example where before this change the
text is cut off and afterwards it is shown completely:
naughty.notify({
text = string.rep("abcdefghijklmnopqrstuvwxyz\n", 4),
width = 75
})
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds :get_preferred_size() and :get_preferred_size_at_dpi() which return
the size (=width, height) that the textbox would need if unlimited space is
available.
This also adds :get_height_for_width() and :get_height_for_width_at_dpi() which
return the height that the textbox would need if the given width is available.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, we grabbed the keys on the frame window. That meant we only got key
events for things that nothing else grabbed directly on the key window.
After this, we grab directly on the client window itself and so we "fight" with
everything else which wants to grab keys. I don't actually know how the winner
is decided... First come, first serve, the rest gets an error?
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel Hahler
Daniel Hahler
Emmanuel Lepage Vallee
Uli Schlachter
actionless
Benjamin Petrenko
Kazunobu Kuriyama