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>
This commit does two things: It gets rid of the reference to the layoutbox that
the default config created and it changes the widget dependency cache to not
keep widgets alive unnecessarily.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Again, instead of directly connecting to various signals for updating a
tasklist, this commit changes the code so that there is just a single, global
connections and based on this a weak table with all tasklist instances is used
do the updates.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Similar to what the previous commit does for layoutboxes, this changes the code
for the taglist so that there is only a single, global connection to the various
signals and these update all taglists via weak tables.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of connecting to the needed tag-update-signal again for every layoutbox,
this now just creates a single connection and updates all layoutboxes from here.
A new weak table is used to find the layoutboxes from these callbacks.
Additionally, layoutboxes are now per-screen unique. So even if you try to
create three layoutboxes for screen 1, the code will now always return the same
instance.
This kind-of fixes the leak test for layoutboxes. The problem is that the
default config also creates a layoutbox and adds it to a wibox. Since this is
now the same layoutbox, the test still fails. Just removing the layoutbox-part
from the default config makes this problem go away.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fixes the textclock-specific part of the test that the previous commit
added.
To fix this, gears.timer.weak_start_new() is used. This function creates a timer
that is automatically stopped when its callback function is garbage collected.
The callback function is saved as a member of the texbox widget that is the
"widget behind the textclock". Thus, the timer can only be stopped after the
widget is garbage-collected, but the timer does not keep the widget alive.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a client is not visible, this would adjust its stacking order
still.
This also addresses https://github.com/awesomeWM/awesome/issues/472,
because it raises unminimized clients after they got focused.
This function updates a hierarchy if the layout of some widgets changed. It does
nothing on the parts that did not change. This should be more efficient than
recomputing the whole hierarchy whenever something changes.
Once again, this has some positive results on the "benchmark test":
Before:
create wibox: 0.083016 sec/iter ( 13 iters, 1.161 sec for benchmark)
update textclock: 0.00391091 sec/iter (271 iters, 3.219 sec for benchmark)
relayout textclock: 0.00273234 sec/iter (397 iters, 1.087 sec for benchmark)
redraw textclock: 0.0010191 sec/iter (989 iters, 1.745 sec for benchmark)
After:
create wibox: 0.083146 sec/iter ( 13 iters, 1.163 sec for benchmark)
update textclock: 0.00170519 sec/iter (647 iters, 2.201 sec for benchmark)
relayout textclock: 0.000581637 sec/iter (1880 iters, 1.094 sec for benchmark)
redraw textclock: 0.0010167 sec/iter (997 iters, 1.773 sec for benchmark)
So again no difference for creating wiboxes (100.16% compared to before). This
time we also have no real difference for creating wiboxes (99.76%). Update (44%)
and relayout (21%) are improved a lot.
Closes https://github.com/awesomeWM/awesome/pull/463.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes the textbox' :draw() and :fit() callbacks use the DPI that is
specified in the given drawing context. With this, the textbox now scales
correctly if different screens have different DPI values.
Idea originally from Daniel.
Closes https://github.com/awesomeWM/awesome/pull/457.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This has some positive results on the "benchmark test". Each single number is
the best one out of three runs.
Before:
create wibox: 0.0826502 sec/iter ( 13 iters, 1.157 sec for benchmark)
update textclock: 0.0186952 sec/iter ( 57 iters, 2.473 sec for benchmark)
relayout textclock: 0.0158112 sec/iter ( 64 iters, 1.028 sec for benchmark)
redraw textclock: 0.0015197 sec/iter (662 iters, 1.861 sec for benchmark)
After:
create wibox: 0.0825672 sec/iter ( 13 iters, 1.154 sec for benchmark)
update textclock: 0.00378412 sec/iter (277 iters, 4.216 sec for benchmark)
relayout textclock: 0.00259056 sec/iter (420 iters, 1.09 sec for benchmark)
redraw textclock: 0.00105128 sec/iter (958 iters, 1.79 sec for benchmark)
We see no significant change in the creation of wiboxes (99.9% compared to
before). Update (20% of the previous run time), relayout (16%) and redraw (69%)
are all sped up by this change.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of going through LGI to call cairo, this now implements the various
matrix operations directly in Lua. The plan is to avoid the overhead that we hit
due to LGI.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This (ab)uses the integration tests to run a benchmark. This currently only
measures wibox drawing performance. To avoid wasting CPU-cycles, this does only
a quick run under travis while on "normal" runs the function under test is
executed in a loop to improve the precision of the measurement.
This benchmarks hopefully allow to optimize things in a clear fashion instead of
things like "it feels faster to me".
Results when run against the previous commit:
== Running test-benchmark.lua ==
create wibox: 0.0788958 sec/iter ( 13 iters, 1.103 sec for benchmark)
update textclock: 0.019493 sec/iter ( 56 iters, 2.507 sec for benchmark)
relayout textclock: 0.0160725 sec/iter ( 63 iters, 1.029 sec for benchmark)
redraw textclock: 0.0015601 sec/iter (647 iters, 1.875 sec for benchmark)
W: awesome: a_glib_poll:291: Last main loop iteration took 6.593912 seconds! Increasing limit for this warning to that value.
Results right before the new widget layouts were merged (commit 52154d0f15):
== Running test-benchmark.lua ==
create wibox: 0.0782874 sec/iter ( 13 iters, 1.095 sec for benchmark)
update textclock: 0.00736755 sec/iter (136 iters, 1.346 sec for benchmark)
W: awesome: luaA_dofunction:77: error while running function
[...]
error: /home/psychon/projects/awesome/build/lib/gears/object.lua:30: Trying to emit non-existent signal 'widget::layout_changed'
Closes https://github.com/awesomeWM/awesome/pull/451.
Signed-off-by: Uli Schlachter <psychon@znc.in>
- Remove `-rdynamic` from "CFLAGS" and count on CMake to pass it to
the compiler at the link phase (Issue #450).
- Move the definition of "CFLAGS" from `awesomeConfig.cmake` to
`CMakeLists.txt` and give it a name, `AWESOME_C_FLAGS`, so that the
relation between the target and the flags is made clearer and
manageable.
- Make `AWESOME_C_FLAGS` a cached variable so that the developers can
tweak the flags promptly in accordance with their necessities without
changing the prescribed value.
- Add a logic to cope with the case where CMake fails to set
`-rdynamic`.
Closes https://github.com/awesomeWM/awesome/pull/453.
There is a client window C. Around this window, awesome adds a frame window F.
When the pointer is inside of C and then moves inside of F, we get a LeaveNotify
with detail=Inferior, but from our point of view, the pointer is still inside of
C, because F is contained in C.
Similarly, if the pointer is in F and moves to C, we get an EnterNotify with
detail=Inferior that we should ignore. However, for an EnterNotify the pointer
can now be inside of a titlebar, so this case has to be handled now.
The above explains the enter/leave behavior for clients. Let's now think about
titlebars: When the pointer moves from C to F, it cannot be in any titlebar any
more, so we must generate a leave event on that titlebar. Similar when the
pointer moves from F to C, but in this case we also have to figure out which
titlebar now contains the pointer.
This patch makes the code handle these events with detail=Inferior correctly.
Closes https://github.com/awesomeWM/awesome/pull/461.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds a global variable that tracks the drawable that is currently under the
mouse cursor. This new variable is then used so that we get consistent behavior
for enter/leave signals. Such signals are now also generated when a MotionNotify
event tells us that the pointer is now in a different titlebar.
Before this, it was possible that we did not generate a leave event on a
titlebar since the LeaveNotify contains the cursor position after the leave and
we did not manage to figure out which titlebar was left.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this, dependencies between widgets where implicitly discovered by
recursive calls to base.fit_widget() and base.layout_widget(). However, it is
too easy to get this wrong (just call one of these functions from outside of a
widget's :fit() / :layout() function) and the resulting mess would be hard to
debug.
Thus, this commit changes the API so that callers have to identify themselves
and we can explicitly record the dependency between the widgets involved.
This also fixes a bug where no dependencies were tracked for widgets after
:set_visible(false). Whoops...
Sorry for breaking the API for adding this.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is used by `tooltip.place` then to tie the tooltip to the screen of
the mouse. Without this, a tooltip from the tasklist might get moved to
the screen above the tasklist, if it gets considered to be on that
screen given its coordinates.
Closes https://github.com/awesomeWM/awesome/pull/437.
When a complete repaint is scheduled, also do a relayout, because this is also
the case that we go through when the underlying cairo surface is resized. For
example, resizing a client with a titlebar would trigger this.
Also, going through this code path is necessary since this is the only place
where the dirty area is updated so that it includes "everything". Before this
change, nothing was actually redrawn, because the dirty area was empty.
Fixes: https://github.com/awesomeWM/awesome/issues/449
Signed-off-by: Uli Schlachter <psychon@znc.in>
Add a path to awesomeConfig.cmake for searching an iconv library and the
corresponding header file automatically if the build system is on Mac OS
X which needs to pass the header and library paths explicitly to the
compiler to build Awesome successfully.
Closes https://github.com/awesomeWM/awesome/pull/440.
Uli Schlachter
Daniel Hahler
Kazunobu Kuriyama
Daniel Hahler
▟ ▖▟ ▖
actionless
Alastair Robertson
Kazunobu Kuriyama