Those are most likely deprecation warnings, but the tests should be free
of warnings (from awesome) anyway.
The "Last main loop iteration took X seconds!" warning is filtered out.
This new paragraph might not be great and it certainly is less
informative than what the wiki said here (it suggested to use some
library for widgets and explained how to use it). However, this new
paragraph is definitely better than the todo that was here for far too
long.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The chaotic order is intended. Some completion algorithms tend to sort
their results by modification time or something similar.
The "huge" number of directories is also intended. With more items the
chance is higher to hit a bug if no sorting took place.
Since Zsh just completes non-empty directories, some files have to be
created, too.
Even if there is a directory in the current working directory with the
same name as a command, the directory must not be completed.
So, if we want to complete "true" and there is a directory "true" in the
current working directory, the completion list has to be just {"true"},
not {"true", "true/"}, or anything else!
In some circumstances, if not every syscall was somehow redefined, the
directory was not changed correctly. With luafilesystem.chdir it is
assured that we are in the wanted directory afterwards.
Since busted seems to spawn isolated child processes for every test
suite, the temporary PATH directories have to be created at the
beginning and destroyed at the end of a test suite.
We cannot possibly know what is in the PATH of a user. The completion
test cases however assume that there is nothing else in the PATH that
starts with `true` other than `true` itself.
These two methods create or respectively destroy a temporary PATH
directory especially for testing. We can put commands in there via
symlinks and verify the correct functionality of the complete commands.
The PATH environment variable is set and reset via GLib.
Several themes use `dpi(2)` which is quite thick, and it is better to
use the default of 0 here, instead of `beautiful.border_width`, which is
meant for borders on clients.
This function draws the wanted shape to a cairo image surface and then
uses it to set the shape of the passed-in object. After this commit,
this temporary image is finished afterwards, making it free most of its
memory immediately instead of only later when the garbage collector
collects the image surface.
Related-to: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
For setting the shape of the tooltip, this code creates an image surface
describing the wanted shape. After this commit, this image surface is
finished when it is no longer needed. This results in most of the
image's memory to be freed immediately instead of only later when the
garbage collector collects the image surface.
Related-to: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function creates a temporary image surface to set the shape of a
wibox. After this commit, the image is now finished after use. This
results in most of the image's memory to be freed immediately instead of
waiting for the garbage collected to collect it.
Related-to: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
This function queries the shape of a client and then does something with
it. This commit makes sure the image is finished afterwards, which means
that most of its memory is released immediately instead of waiting for
the garbage collector to collect it.
Related-to: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
When doing w.shape_bounding = foo on a wibox, the code would first read
shape_bounding from the underlying drawin. This would create a
(possibly) huge cairo image surface that just waits to be collected by
the garbage collector, resulting in increased memory usage.
Fix this by checking the force_forward table first. This tables contains
the names of shape properties. Thus, the evaluation of this statement
gets short-circuited and the property is on the drawin is not read.
Helps-with: https://github.com/awesomeWM/awesome/issues/1958
Signed-off-by: Uli Schlachter <psychon@znc.in>
I am not sure what exactly goes on in the below bug report, so this will
just paper over the problem. I still think that this patch is a good
idea even when it is not a proper fix, since keyboard layouts are
complicated and so this code should be robust and hard to break.
Fixes: https://github.com/awesomeWM/awesome/issues/1933
Signed-off-by: Uli Schlachter <psychon@znc.in>
Daniel Hahler
Uli Schlachter
Daniel Hahler
Emmanuel Lepage Vallée
Florian Gamböck
José Romildo Malaquias
Jagannathan Tiruvallur Eachambadi
Uli Schlachter
Crazy Lemon
Tomoya Tabuchi