When less space is available than was asked, systray:draw() has to
compute the right base size so that all the icons fit into the available
space. This computation so far ignored the icon spacing, resulting in a
too large base size.
Fixes: https://github.com/awesomeWM/awesome/issues/2981
Signed-off-by: Uli Schlachter <psychon@znc.in>
This caused a behavior change it wasn't clear how to use the
permission API to change the focus mode.
The change will only take effect if the user override the API
level.
This also pulls in part of the permission framework to ensure
backward compatibility is kept.
`awful.autofocus` was always weird. It is a module part of `awful`,
but it was never part of `awful` `init.lua`. Rather, `rc.lua` was
the sole place it was used. It behave exactly like a request, but
predate them by years. As I cleanup the request:: API before the
permissions API gets formalized, this has to be fixed now.
It isn't deprecated in this commit because it makes too many tests
fail. Another pull request will solve that by adding the "API level"
concept to AwesomeWM so I can change the behavior without breaking
existing configs. With that, the behavior of `autofocus` will be
enabled by default with the permissions to disable it.
https://github.com/awesomeWM/awesome/issues/2596
Re-matched regex used elsewhere & updated test cases for "." in filename
Allowed for alternative extensions to be found even if specified
Reverted the change of behaviour but adjusted code for readability
Small readability change
Avoided delay searches that would never work
Untabify
Reverted possible [unlikely/undesired] behaviour changes
Untabify
This gets rid of the following output when running the unit tests:
2019-01-26 18:31:44 E: awesome: beautiful: error loading theme: got an empty table
2019-01-26 18:31:44 E: awesome: beautiful: error loading theme: got an empty table from: ./spec/beautiful/tests/Bad_1.lua
2019-01-26 18:31:44 E: awesome: beautiful: error loading theme: got a function from: ./spec/beautiful/tests/Bad_2.lua
2019-01-26 18:31:44 E: awesome: beautiful: error loading theme: got a number from: ./spec/beautiful/tests/Bad_3.lua
2019-01-26 18:31:44 E: awesome: beautiful: error loading theme: got a nil from: ./spec/beautiful/tests/Bad_4.lua
2019-01-26 18:31:44 E: awesome: Error during a protected call: ./spec/beautiful/tests/Bad_5.lua:2: attempt to index local 'var' (a nil value)
stack traceback:
./spec/beautiful/tests/Bad_5.lua:2: in main chunk
[C]: in function 'dofile'
[C]: in function 'xpcall'
lib/gears/protected_call.lua:36: in function <lib/gears/protected_call.lua:35>
(...tail calls...)
lib/beautiful/init.lua:224: in function 'init'
spec/beautiful/init_spec.lua:56: in function <spec/beautiful/init_spec.lua:25>
[C]: in function 'xpcall'
/usr/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/share/lua/5.2/busted/init.lua:40: in function 'executor'
...
/usr/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/share/lua/5.2/busted/block.lua:155: in function 'execute'
/usr/share/lua/5.2/busted/init.lua:7: in function 'executor'
/usr/share/lua/5.2/busted/core.lua:312: in function </usr/share/lua/5.2/busted/core.lua:312>
[C]: in function 'xpcall'
/usr/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/share/lua/5.2/busted/execute.lua:58: in function 'execute'
/usr/share/lua/5.2/busted/runner.lua:174: in function </usr/share/lua/5.2/busted/runner.lua:11>
/usr/bin/busted:3: in main chunk
[C]: in ?
2019-01-26 18:31:44 E: awesome: beautiful: error loading theme: got a nil from: ./spec/beautiful/tests/Bad_5.lua
2019-01-26 18:31:44 E: awesome: Error during a protected call: cannot open ./spec/beautiful/tests/NO_FILE: No such file or directory
stack traceback:
[C]: in function 'dofile'
[C]: in function 'xpcall'
lib/gears/protected_call.lua:36: in function <lib/gears/protected_call.lua:35>
(...tail calls...)
lib/beautiful/init.lua:224: in function 'init'
spec/beautiful/init_spec.lua:57: in function <spec/beautiful/init_spec.lua:25>
[C]: in function 'xpcall'
/usr/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/share/lua/5.2/busted/init.lua:40: in function 'executor'
/usr/share/lua/5.2/busted/core.lua:312: in function </usr/share/lua/5.2/busted/core.lua:312>
...
/usr/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/share/lua/5.2/busted/block.lua:155: in function 'execute'
/usr/share/lua/5.2/busted/init.lua:7: in function 'executor'
/usr/share/lua/5.2/busted/core.lua:312: in function </usr/share/lua/5.2/busted/core.lua:312>
[C]: in function 'xpcall'
/usr/share/lua/5.2/busted/core.lua:178: in function 'safe'
/usr/share/lua/5.2/busted/core.lua:312: in function 'execute'
/usr/share/lua/5.2/busted/execute.lua:58: in function 'execute'
/usr/share/lua/5.2/busted/runner.lua:174: in function </usr/share/lua/5.2/busted/runner.lua:11>
/usr/bin/busted:3: in main chunk
[C]: in ?
2019-01-26 18:31:44 E: awesome: beautiful: error loading theme: got a nil from: ./spec/beautiful/tests/NO_FILE
Signed-off-by: Uli Schlachter <psychon@znc.in>
This removes unused public functions from menubar.utils. This is not an
API break, because these functions were only added in commit
8d34201ec3, which is after v4.2. These new functions became
unused in commit e88f1e8735, not long after they were added.
Signed-off-by: Uli Schlachter <psychon@znc.in>
It is not possible to distribute 100px to three widgets equally. The
current version of wibox.layout.flex tries to do that anyway, by giving
each widget 33px and leaving one pixel outside of any widget. Thus, if
the widgets e.g. have a common background, this leads to a one pixel gap
in the background.
This patch changes the flex layout so that the extra pixel is assigned
to some widget instead. It does so by basically keeping a sum of
space_per_item for the widgets that was assigned so far. This sum is
rounded and when this leads to rounding, the corresponding child widget
gets an extra pixel.
More precisely, this tracks a pos as before. Widgets get their position
still assigned based on rounding pos. However, this now also remembers
this rounded position for the next iteration of the loop. This allows to
assign the size of widgets based on the difference between the current
and last rounded position.
(Possibly) fixes: https://github.com/awesomeWM/awesome/issues/2461
Signed-off-by: Uli Schlachter <psychon@znc.in>
When calling join with e.g. arguments (nil, {"a"}), then everything past
the nil was ignored, because the code internally used ipairs() to
iterate over the arguments and this stops at the first nil it
encounters.
Fix this by using select() to iterate over the arguments.
This also adds a unit test for this problem.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Adds unit tests for menubar.utils.lookup_icon_uncached.
Tests that icons and themes are found in the icon base directories, and
icons are resolved with the correct priority.
Creates directories and symlinks in spec/menubar/{home,usr} as test
data.
* Unescape strings when parsing desktop entries
* Fix unused value warning in menubar/utils.lua
* Move menubar.utils.unescape() tests
* Clean up menubar.utils.unescape() function
* Fix warning for using "_" in a non-local context
* Do not ignore trailing whitespace in menubar.utils.parse_list()
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.