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>
Daniel Hahler
Daniel Hahler
Nick Diego Yamane
Uli Schlachter
Emmanuel Lepage Vallée
Florian Gamböck
José Romildo Malaquias
Jagannathan Tiruvallur Eachambadi
Uli Schlachter