The bit that indicates that the base size is set is
XCB_ICCCM_SIZE_HINT_BASE_SIZE. However, instead this code checked
XCB_ICCCM_SIZE_HINT_P_SIZE which is set to indicate how the initial window
position is chosen. So we were checking the complete wrong bit. Whoops...
Fixes: https://github.com/awesomeWM/awesome/issues/456
Signed-off-by: Uli Schlachter <psychon@znc.in>
This ensures that systray icons cannot resize themselves. We assign them some
size and they have to deal with what they get!
Fixes: https://github.com/awesomeWM/awesome/issues/487
Signed-off-by: Uli Schlachter <psychon@znc.in>
We recently changed the C function screen_getbycoord() and this commit makes
awful.screen.getbycoord() use the same algorithm.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of comparing only the top-left corner of the screen to the provided
coordinate, this now compares the screen in a more intuitive way, e.g.
coordinates inside of the screen have a distance of zero.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Together with the previous changes, this also fixes the initial positions for
metacity's test-gravity.c.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit added some variables and this commit makes the surrounding
code use these new variables as well.
Signed-off-by: Uli Schlachter <psychon@znc.in>
My recent refactoring accidentally made the taglist only connect to the signal
for the first screen on which a taglist is created. This commit fixes the code
so that it connects for all screens.
Fixes https://github.com/awesomeWM/awesome/issues/500
Signed-off-by: Uli Schlachter <psychon@znc.in>
The mouse position is saved and restored when focusing another screen
If the target screen has no saved mouse position, the relative position
of the current screen is used
Signed-off-by: lesell_b <lesell_b@epitech.eu>
* This commit add a new module to avoid a (4 level) loop dependency
* It is now possible to call awful.spawn() with a table of properties
* awful.rules is used to execute the rules.
* Everything is public to allow alternative workflow modules such as
Tyrannical to use their own callback implementation.
If someone modifies a cairo surface and then sets the resulting object as the
image of an imagebox, the imagebox needs to redraw. Thus, since surfaces are
modifiable, we cannot assume that nothing changed when the same image is set
multiple times on an imagebox.
However, the dimensions of a surface cannot be changed and thus this does not
need to emit widget::layout_changed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Whenever client.focus == nil, we set the input focus to the root window to
express "nothing has the input focus". However, thanks to the way X11 input
works, this means that whatever is under the mouse cursor gets keyboard input
events. This can easily be reproduced with urxvt and some small addition to the
config to unfocus things.
This commit changes things. Instead of focusing the root window, we create a
special "no focus" window that gets focused if we want nothing to have the
focus.
Closes https://github.com/awesomeWM/awesome/pull/470.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This refactors the env vars for the build matrix:
- add LUANAME
- drop LUALIB
- add LUAINCLUDE for special luajit include dir.
- add LUAROCKS_ARGS for luarocks' `configure --lua-suffix=jit-2.0.0-beta9`.
Closes https://github.com/awesomeWM/awesome/pull/484.
I have no idea why this needs collectgarbage() to be called twice.
On the other hand, I can explain the change in tooltip.lua. Lua 5.2 introduced
"ephermeron tables". This means that in the following sitation, lua 5.2 can
collect the entry from the table, while 5.1 keeps the entry alive, because the
table has a strong reference to the value and that in turn has a strong
reference to the key:
t = setmetatable({}, { __mode = "k"})
do
local k = {}
t[k] = function() print(k) end
end
collectgarbage("collect")
print(next(t, nil))
To handle this incompatibility, this commit just removes the whole indirection
through the module-level variable "data".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Apparently some of the last commits speeds up create_wibox() a lot. This
highlights that this is a bad test: After creating thousands of wiboxes, awesome
needed 15 seconds to draw all of them and in the end some dbus timeout aborted
the test run.
However, it's irrelevant how quickly we can create wibox. The interesting number
is how quickly we can display a new wibox. Thus, this commits changes the code
so that it also measures the time that is needed to update the wibox. This way,
we don't accumulate a huge number of pending repaints and everything's fine.
Some results (but there is nothing to compare this with):
create&draw wibox: 0.0373947 sec/iter ( 28 iters, 1.59 sec for benchmark)
update textclock: 0.00198174 sec/iter (515 iters, 1.937 sec for benchmark)
relayout textclock: 0.000614439 sec/iter (1710 iters, 1.051 sec for benchmark)
redraw textclock: 0.00116882 sec/iter (865 iters, 2.962 sec for benchmark)
tag switch: 0.000705579 sec/iter (1498 iters, 3.703 sec for benchmark)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel Hahler
Uli Schlachter
lesell_b
Emmanuel Lepage Vallée
actionless
Kazunobu Kuriyama