Previously, it would create a new object. The leaves the old
`replaces_id` logic mostly intact for now to keep the full backward
compatibility. I don't think anybody would have noticed the changed, by
time and time again we had proof that some silent users have some
amazing and advanced code hidden somewhere. It could be cleaned later
when breaking compatibility isn't an issue.
When the mouse is over or a keyboard driven menu is open, avoid
unexpected expiration to mess with the current notifications.
This commit also improve the `suspended` behavior to correctly
emit some signals.
The current API is non-compliant with the 1.0 spec and cannot represent
the v1.2 spec at all. The pair of name and callback fails to represent
the explicit ordering and cannot support the icons cleanly.
Plus to support the keyboard navigation use case, the notification
action need to be able to get some sort of focus state. Having an
object makes this easy.
In Lua 5.1, xpcall() has exactly two arguments: The function to call and
the error handler. Everywhere else, xpcall() passes extra arguments on
to the function to call. This includes LuaJIT, however since LuaJIT sets
_VERSION to "Lua 5.1", so far gears.protected_call used the workaround
for Lua 5.1 here.
This commit switches gears.protected_call to actually test for this
feature instead of just guessing based on _VERSION. Thus, this now also
uses the better code with LuaJIT.
Signed-off-by: Uli Schlachter <psychon@znc.in>
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
Commit ba75da7976 worked around a bug in LGI. However, it did so by
just dropping the code that set the foreground color. Instead, it should
have changed the code so that cr:set_source() is only called if the
background container has a foreground color configured instead of "just
always".
Fixes: https://github.com/awesomeWM/awesome/pull/2609#issuecomment-459580395
Signed-off-by: Uli Schlachter <psychon@znc.in>
When $SOURCE_DIRECTORY is set, we are most likely currently running the
examples test, i.e. generating images. These images end up in the
documentation.
To make the images reproducable, i.e. independent from the current time,
this commit makes the textclock honor $SOURCE_DATE_EPOCH if
$SOURCE_DIRECTORY is set.
See commit 9d7eaf02 for some more details.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The current `awful.widget.layoutlist` is a fork of the so far uncommitted `naughty.widget.actionlist`. It was created because some of the support code for the new `naughty` implementation needed "easier to merge" usage examples. The `layoutlist` was chosen because it was both a low hanging fruit and genuinely useful.
cairo_get_source() is not bound correctly, leading to use-after-free
bugs. Cairo catches this and crashes.
Work around this by preserving the current source in a different way.
Instead of using cairo_get_source() and later cairo_set_source(), this
commit wraps everything that changes the current source between
cairo_save() and cairo_restore(). Thus, cairo saves the current source
for us without us having to grab an explicit reference.
Works-around: https://github.com/pavouk/lgi/issues/210
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, the background container "just" used the shape and drew a
line around it. This means that half the line will be inside of the
shape and half of it will be outside. Thus, this hides the actual shape
that is used.
This commit changes that so that the line is added outside of the shape.
It does this via some tricks:
- In :before_draw_children(), :push_group() is used to redirect drawing
of the child widget to a temporary surface.
- In :after_draw_children(), the border is added to this group.
+ For this, another temporary surface is created. It will be used as a
mask.
+ The inside of the shape on this mask is cleared, everything else is
filled. Thus, the mask now contains everything "not content".
+ Everything inside the mask is filled with the background color.
- Also in :after_draw_children(), the group is drawn to the actual
target surface.
+ Again, this needs a mask.
+ This time, we draw the shape to the mask with twice the border width.
Thus, half of this line will be outside of the shape.
+ Then, the shape itself is also filled so that the mask contains the
shape and the border.
+ This mask is then used to copy the right parts of the temporary
surface were the child widget and border was drawn to the actual
target surface that will be visible on screen.
This approach has some upsides. Because we no longer have "half the
border" above content, colors with some transparency work fine for the
border. Also, this should avoid issues with anti-aliasing, because e.g.
the border is not just drawn with the border width, but also further out
to everything else so that the background cannot "bleed through".
Fixes: https://github.com/awesomeWM/awesome/issues/2516
Signed-off-by: Uli Schlachter <psychon@znc.in>
This module is half way between the tooltip and the raw wibox.
It supports the following features:
* Auto resize to its widget size
* Support parent objects and placement
Fix#1683
If the `layouts` are set during initialization, `t.layout` will
return `floating` if `t.layouts` is added before `t.layout`. By
using the raw layout, the fallback doesn't kicks in.
Commit ac8af66005 added beautiful.theme_path, which is used to save the
directory that contains the theme file that was loaded. Just two months
later, commit ca12473584 broke this code by adding a __newindex
metamethod. This caused the assignment to beautiful.theme_path to be
redirected to the theme. However, the theme is immediately replaced by
beautiful.init() after setting up the theme_path, so this assignment got
lost.
Fix this by using rawset() to bypass the metamethod.
Fixes: https://github.com/awesomeWM/awesome/issues/2573
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, it was added by `wibox.widget.base` if
`:setup()` is used. However it doesn't work for the `awful.popup`
because of the extra indirection.
This commit stops the monkey-patching and make sure the function
always exists. This doesn't prevent it from not working and in
the long run this should still be moved into the hierarchy.
However for now it makes the situation a lot more consistent and is a
quick band-aid without too much controversy.
Mitigate #2181
Given they are all small, it makes more sense to just merge them like
we did for the client API
For some reasons GTK doesn't want to be merged. To be investigated.
Given noone understand this code, this will prevent some semi likely
regressions from going unnoticed. The main risk is the shims not
producing the exact same results as the real implementation and
cause different code paths to be taken.
As of this commit, both the "real" and "shim" implementation were given
the same set of tests with print() at every step of next_to. The
resulting log was then checksummed to ensure both are identical.
It also add some properties such as `border_width`, `border_color`
and `preferred_alignments`.
It also fix a documentation bug where the `margin_topleft` was called
`margins_topleft`. To conform to the documentation, both are now valid
but one should be removed the next time the API changes.
Fixes#1978
By passing the geometry, important information used by
awful.placement.next_to were "lost". Given `next_to` supports both
widget position, the mouse and client/wibox relative positioning, it
has to know the object type.
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>
Update lib/awful/hotkeys_popup/widget.lua
Update lib/awful/hotkeys_popup/widget.lua
fix(awful: hotkeys_popup): caching issue if showing the same widget instance with and without AwesomeWM hotkeys
doc(awful: hotkeys_popup): extend docstring for args.show_awesome_keys
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>
In the earlier revision of the keygrabber PR, there was a `release_key`
and it was suggested to rename it `stop_key`. However its sibling
`release_event` wasn't, so it is now confusing.
The commit adds a mild deprecation codepath to avoid breaking configs
based on git-master. However it isn't a "long term" deprecation notice
and the code can probably be removed in 5.0 without further delay.
Previously, the layout list was global. However it wasn't covering all
possible use cases and make using `awful.widget.layoutlist` hard since
a layout could be excluded from the `awful.layout.layouts` but still
used for a tag (by setting it explicitly).
Until now there wasn't much documentation available about how to use
these properties. With the new work on `awful.spawn` that rely more and
more on `awful.rules` integration, it is worth fixing.
This commit add a new documentation section and a future commit will
aggregate them to generate an index.
When mangling notifications via naughty.config.notify_callback it is
advised (1) to return nil to reject a notification. The underlaying dbus
library tries to access a field of that notification table and fails.
(1) https://awesomewm.org/doc/api/libraries/naughty.html
The toggle/show/hide function were incompatible with the current
`rc.lua` is `titlebars_enabled` was removed from the rules because
they were never created. This has always been the case but the
introduction os `request::titlebars` in Awesome 4.0 allows to solve
this longstanding issue. However until now it didn't.
Fix#2419
If the history file (or its parents) can't be created, running a command
will fail entirely. Since saving command history is not an integral part
of running a command, it would be nicer if it carried on, just without
saving history. This is what shells usually do.
This patch removes assertions in the history saving function and
instead adds an early return, so if the history isn't saved the command
invocation simply carries on.
Signed-off-by: Alyssa Ross <hi@alyssa.is>
This commit adds a way to leverage the xproperty and startup_id APIs
to persist an execution token across restarts. It allows to use
`awful.rules` on clients that were executed by a previous Awesome
instance.
The main limitations of these methods is the lack of entropy used to
build the token. If the command is the same in multiple
`awful.spawn.once`, then it will not work as expected. To mitigate this
issue, the system try to concatenate the `awful.rules` table after the
command and hash the resulting string. Given rules are a table, it can
have loops and/or issues with keys ordering. The hash function sort and
limite recursion to prevent a stack overflow. Another issue is the
unreliability of startup notifications.
`pairs` order isn't defined and `{...}` will always be ordered.
There is no reason to have random behavior where it can be
predicted at no additional cost.
The awful.placement.no_offscreen function did not work properly when
composed with other placement functions; in particular, the default
configuration (awful.placement.no_overlap+awful.placement.no_offscreen)
was broken. The compose function sets args.pretend=true and puts the
result of the previous placement function into args.override_geometry
before calling the next placement function, but no_offscreen did not use
args.override_geometry, therefore the result of the previous placement
function was discarded.
All other placement functions use `geometry_common(c, args)` to get the
current client geometry; `area_common(c)` should be used only when
getting geometry of other clients.
This change also fixes the problem with margin handling (adding margins
should not affect the window size, only the window position should
change); the test output which was adjusted in commit 0275d3537d
is adjusted again to account for this change.
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
The awful.placement.no_overlap function was adding the window border
width to the client width and height (this is performed in
area_common(), which is called by geometry_common()), but did not
reverse this operation by calling remove_border() before returning the
final geometry; because of this, using no_overlap resulted in increasing
the window width and height by 2*border_width.
The bug was probably introduced in commit ebcc19844e (before
that commit no_overlap changed the window position directly instead of
relying on the new placement infrastructure), but was not noticed
because of other problems (e.g., in the default configuration the result
of no_overlap was overridden by the buggy no_offscreen).
Signed-off-by: Sergey Vlasov <sigprof@gmail.com>
The current taglist/tasklist allow filter function to remove elements
from the list. However they don't allow sorting or additional entries
to be listed.
This commit introduced such a concept. It will later be used by the
layoutlist where it becomes more relevant since layouts are used created
"objects".
This property is based on Motif WM hints and checks if the client
requests that it is not decorated with a titlebar.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When an icon is sent over dbus, we turn this into a cairo ImageSurface.
This is done by turning the actual icon data into a string and using
cairo.ImageSurface.create_for_data() to create a surface for this data.
However, this function only creates an ImageSurface that refers to this
data. It does not copy the data. Thus, when the Lua GC later frees the
string, we have a cairo surface that refers to already-freed data.
Fix this by duplicating the cairo surface, which makes cairo create a
copy of the data. Then, we finish the original surface. While doing
this, the string is kept alive in a local variable.
(Possibly) Fixes: https://github.com/awesomeWM/awesome/issues/2361
Signed-off-by: Uli Schlachter <psychon@znc.in>
When a tag is specified by name, awful.rules only searched for the tag
on the client's screen. This commit extends the search to all screens,
but only if no specific screen was specified for the new client by some
rule.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The typo was introduced in commit a1941efc9.
Its effect should be minimal: :item_enter() itself does not care about
the 'mouse' option, but it forwards to :exec(). Here, an action is
invoked either if it was not caused by the mouse, or if it was caused by
the mouse and either auto_expand is enabled (which is the default), or
the item-to-be-executed is actually the active item.
In other words, it is quite non-trivial to come up with a case where
this typo made a difference. But of course that's no reason to leave the
typo in.
Fixes: https://github.com/awesomeWM/awesome/issues/2347
Signed-off-by: Uli Schlachter <psychon@znc.in>
The old keygrabber API wasn't doing what the users want from a
keygrabber module. With tons of boilerplate code, everything could
be done, but it wasn't trivial.
This commit add a default grabber function that implements the
keybinding API already used by `awful.key` and `awful.prompt`.
It also add syntax candy left and right to make the module "feel"
like a native CAPI object.
Nothing is perfect and some parts, like adding root keybindings, are not
vevy pleasing. However it fulfill its goal when it comes to make
previously non-trivial use case very easy to implement and deploy.
This code was attached to mouse::enter in `rc.lua` instead of being part
of the unified request::activate architecture.
There is currently no way to detach this focus filter because it is
generally correct.
There is currently no centralized way to manage active keybindings so
the description data case be used to fill part of that role until an
official API is added.
Layouts work with the client's geometry in "space on screen that is
assigned to this client". This means that the geometry should include
decoration (titlebar and borders) and useless gaps.
Everything else (especially the C code) works with client's geometry in
"space that the client can draw on". This means that the titlebar,
borders and the useless gaps are not included into this size.
Thus, when applying size hints, the tile layout has to convert between
these two representations. Otherwise, size hints are applied incorrectly
and to a wrong geometry.
Fixes: https://github.com/awesomeWM/awesome/issues/1418
Signed-off-by: Uli Schlachter <psychon@znc.in>
I do not know how a GDataInputStream / GBufferedInputStream decides
about the size of its internal buffer when reading input by line, but in
issue #2288, an example where the output of date (about 30 bytes) was
read ten times per second caused ten megabytes of memory usage for this
internal buffer. Try to save some memory by explicitly shrinking the
buffer size when we are done reading from the stream.
Reference: https://github.com/awesomeWM/awesome/issues/2288
Signed-off-by: Uli Schlachter <psychon@znc.in>
In #2112 the way of loading category icons was changed to use
utils.lookup_icon. However this function does not look in the
categories paths where the categories icons are located, and
so the category icons are no longer being displayed.
This change makes errors messages show up in the replies, too.
Before (notice how the third command does not generate output):
$ awesome-client 'return 42' ; awesome-client 'sdfsdf' ; awesome-client 'error("foo")'
double 42
string "[string "sdfsdf"]:1: syntax error near <eof>"
After:
$ awesome-client 'return 42' ; awesome-client 'sdfsdf' ; awesome-client 'error("foo")'
double 42
string "[string "sdfsdf"]:1: syntax error near <eof>"
string "Error during execution: [string "error("foo")"]:1: foo"
Signed-off-by: Uli Schlachter <psychon@znc.in>
For "stuff around screen's 'removed' signal", it might make sense to
temporarily set a tags screen to nil. The idea is that it will only
later be assigned to a new screen, not immediately.
However, currently a tag with screen nil causes quite some problems in
the set_screen() function. This commit works around this with a generous
amount of "wrap this in if".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, there was a conflict between the spawn and
awful.rules rules.
Also, modules such as Tryannical monkey-patched this function to
add their own rules to the mix. This commit introduce a proper
API to add handlers.
The order is crutial for this to work, so a dependency system is
also added.
Fix#1482
* Add support for resizing notification icon with respect to aspect
Previously, if an icon was not exactly square, an icon size set in configuration
would cause the notification to pad the icon with empty space so dimensions are
equal.
Now behaviour is different: the bigger dimension of the icon is scaled to fit
the icon_size value, while smaller is scaled same amount to preserve aspect.
Also, ImageSurface is now not created as fixed size square, but it's dimensions
are computed in similar way.
* Round the computed dimensions of ImageSurface
Even one pixel off is still off.
This now does directly what previously awesome.load_image() did. Also,
this commit removes the only caller of awesome.load_image(), so that
function could (in theory) be removed now.
Fixes: https://github.com/awesomeWM/awesome/issues/1235
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code here has things like "if cache.bgb" which suggests that "bgb"
(great name, by the way) is supposed to be optional. However,
31b8623ff6 made this thing definitely not optional by making it
*the* widget that is displayed. That feels wrong.
Also, after the above commit, the ".primary" entry is no longer used,
which is at least surprising for something which is called "primary".
None of this is explicitly documented (I didn't find anything when
looking for "primary" in common.lua nor tasklist.lua; I know that there
are examples for using this, but still that doesn't say how this is
supposed to work), so I'm not quite sure how this was intended to work.
Instead, I am just proposing this commit as a better fix with the above
rational and see what feedback I get...
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit allow user defined delegates to be used as list elements.
This put an end to the endless attempt to cram more features into this
code.
A widget template (non-instantiated) is passed to the arguments and
is created by the common code. It also supports "roles" where some
user defined widgets can replace the old textbox or imagebox.
The old function didn't scale at all. As no replacements are going
to be merged anytime soon, start to make it meta-extensible.
This is the first step to be able to let the widget be extended
directly from rc.lua without adding yet more silly parameters.
It never scaled and has reached the point of no return a very long
time ago.
My first ever contribution to Awesome was to attempt to fix this,
but the solution was a bad hack. The radical module later solved
this by delegating the style, layout, theme, item layout and item
style to various "visitor" objects. While this is superior to this
commit, it was also a very large and complicated codebase. After
5 years, it is now obvious it will never be merged "whole".
Do it now since the future awful.popup and notification widget
also uses it.
The `load_ldoc.cmake` changes allow to include `.ldoc` blocks in
existing ldoc comments. Previously, it added some extra newlines
and an autogenerated comments saying the content below was imported.
The problem is that this prevented the system to be used for shared
function arguments.
This commit also renames the `wibar` argument table from `arg` to
`args` as the name has to be the same in the `wibox` and `wibar`
constructor for this to work.
The ratio, fixed and flex layout can now display a widget between
each layout elements.
The align layout was left out because it doesn't support spacing
As long as Awesome provides APIs that uses pixels are points, this
cannot be enabled by default.
For example, a wibar size defined in pixels may be too small to
render the text once a dense display is connected.
If g_date_time_format() fails, it returns a NULL pointer. This change
makes the textclock detect this and print a warning. This warning
contains 'g_date_time_format()' so that people can ask their favorite
search engine for the supported formats of this function. This warning
also contains the actual format string so that all the information is
available in one place and possible bug reports hopefully include the
format string.
Reference: https://github.com/awesomeWM/awesome/issues/2118
Signed-off-by: Uli Schlachter <psychon@znc.in>
The code in menubar.icon_theme naively implements the algorithm from the
base dir specification. This is a problem: On this system,
/usr/share/icons/{Adwaita,hicolor}/index.theme list 91, respectively 649
subdirectories. Since we check for three file extensions (png, svg,
xpm), this means that a failing icon lookup for the Adwaita theme checks
for (91+649)*3 = 2220 files (in practice it might be a bit better since
the directories have specific meanings, but still). That's insane.
Since we only use this code for looking up category icons anyway, just
deprecate this mess. Category icons are now looked up in the same way
that icons for individual applications are looked up.
Since menubar.init does not require("menubar.icon_theme"), this means
that menubar.icon_theme is no longer actually loaded. That's bad.
(Hopefully) Fixes: https://github.com/awesomeWM/awesome/issues/1496
Signed-off-by: Uli Schlachter <psychon@znc.in>
This is a slight API break, but should not cause many problems for
people. This makes parse_desktop_file() handle the type of keys
correctly, so that e.g. booleans are actually parsed as booleans. Also,
locale-sensitive entries are now looked up in a way that obeys the
current locale.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This replaces our own, hand-written parser of desktop files with the one
that GLib provides. No functional changes intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
If a tag is specified by name, but no such tags exist, awful.rules would
cause an error (attempt to index a nil value). Fix this and add a test
for this case.
Fixes: https://github.com/awesomeWM/awesome/issues/2087
Signed-off-by: Uli Schlachter <psychon@znc.in>
Since beautiful.xresources.get_dpi(s) allows nil as argument to query
some "global DPI", the functions to query the size of a textbox also
allowed to use nil as the screen, even though this was never documented
to work. Commit a137655791 broke this by assuming a valid screen
object.
This commit makes a nil argument work again, but will cause a
deprecation warning in awesome 5.
Signed-off-by: Uli Schlachter <psychon@znc.in>
For example, Xephyr reports its output with a size of 0x0. Since a
division by zero is in no one's interest, just ignore such outputs when
trying to compute the DPI value.
Thanks to @timroes for pointing this out:
c8fac753c4 (commitcomment-25072296)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Running test-menubar.lua just failed for me locally. The reason was that
the textbox was indexing a nil value when doing 's.dpi'.
This commit fixes the menubar so that its optional screen arguments are
really handled correctly. In fact, a default screen is now chosen way
earlier than before, so that no nil values are used as screens later on.
In other news: I guess test-menubar.lua is not run on any of our Travis
targets...
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit makes awesome automatically compute the DPI of a screen
based on its RandR outputs. If multiple outputs exist, the lowest DPI is
used.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Once upon a time, beautiful.xresources.get_dpi was added to query
Xft.dpi. That made sense since this queried an xresources property. Over
time, other, non-xresources-based ways to query DPI were added to this
function. Now, it makes no more sense to have this function here.
Also, recently it became possible to add new properties to C objects
from Lua code. Thus, we no longer need to have a get_dpi() function
somewhere, but can add s.dpi directly.
Thus, this commit adds s.dpi and makes everything use it. No functional
changes are intended.
Signed-off-by: Uli Schlachter <psychon@znc.in>
To apply the shape of a client, we have to create an image and draw the
shape we want to it. Since clients can be quite large, we have to make
sure that we do not keep this image alive unnecessarily long.
The code in awful.client.shape.get_transformed() however needs another
temporary surface in case the client has its own shape and another one
was set in Lua (side note: currently the code also creates this extra
temporary surface if the client does not have its own shape; that might
be worth fixing). This temporary surface is then used as the source of a
cairo context to draw it to the image that will be used as the client's
final source.
After we are done, the temporary surface is still kept alive since it is
the current source of the cairo context. The cairo context in turn is
only freed when Lua's garbage collector collects it, which may take
quite a while.
Improve this by setting a different source to the cairo context. Thus,
it now releases the temporary surface as soon as possible and it is only
allocated for a short time.
Fixes: https://github.com/awesomeWM/awesome/issues/2050
Signed-off-by: Uli Schlachter <psychon@znc.in>
This fixes a regression introduced in be29ee6768. This commit changed
naughty to reuse an already-existing wibox when replaces_id is used,
instead of creating a new wibox. However, some of the properties that
are set only when creating a wibox were ignored due to this.
Fixes: https://github.com/awesomeWM/awesome/issues/2040
Signed-off-by: Uli Schlachter <psychon@znc.in>
* 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 magnifier layout handles the currently focused client specially.
However, if the currently floating client is floating, it should not be
handled by the layout at all. A bug caused the magnifier layout to
handle a focused and floating client anyway if it was the only tiled
client.
Fix this by removing the '#cls > 0'-case. If #cls == 0, then no client
is available to be managed. Thus, cls[1] will be nil, which is fine
since, well, no client is available to be managed. This only made a
difference in the specific bug that I described above. Thus, drop this
case.
Fixes: https://github.com/awesomeWM/awesome/issues/2045
Signed-off-by: Uli Schlachter <psychon@znc.in>
* feat(awful: widget: calendar_popup: attach): implement 'on_hover' option
* feat(awful: widget: calendar_popup): smarter handling of click and hover at the same time
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>
When gap_single_client is set to 'false', no gap is used when only one
client is shown in a tag. Since the max layout only ever shows one
client at a time it makes sense to apply this setting for this layout
regardless of the actual number of clients in that tag.
Additionally, if the 'master_fill_policy' property is set to
'master_width_factor', then use a gap even if there is only one client
visible and 'gap_single_client' is false.
There were multiple things which stood out to me, as I was trying to setup a simple calendar popup for my textclock:
1.: The functions in https://awesomewm.org/doc/api/classes/awful.widget.calendar_popup.html#Functions were not named correctly (calendar vs calendar_popup) which (naturally) produced an error when used as awful.widget.calendar.month() .
2.: The example for calendar_popup.month() was obviously missing a line (where does the month_calendar come from?) . Resolved by copying the line from the attach-example
3.: The same examples also only refer to the function as calendar.month() which should be changed to awful.widget.calendar_popup.month()
This now runs parse_desktop_file in a protected context so that a single
broken desktop file does not break the whole menubar.
Also, the error message that is produced when a Lua error occurs now
also includes the file name of the .desktop file which we attempted to
parse. This should help quite a lot in debugging.
Related-to: https://github.com/awesomeWM/awesome/issues/1880
Signed-off-by: Uli Schlachter <psychon@znc.in>
1. before this patch the "Shift" key(s) to get to Shift-Tab would reset
ncomp already.
2. "Shift-Tab" will come in as "Tab" with mod.Shift typically.
3. cur_pos and ncomp have to get reset in case of going back to the
original entry.
This allows, for example, to imeplement the tag `master_fill_policy`
and simplify the client layouts by not having to hardcode empty
columns and rows in each layouts.
Without this, users would modify the beautiful table directly instead of
the theme. This made a difference for code using beautiful.get() to get
the theme.
Reference: https://github.com/awesomeWM/awesome/pull/1854
Signed-off-by: Uli Schlachter <psychon@znc.in>
When awful.tag.new() got a list of layouts shorter than the list of
names, it would previously create tags with nil as their layout. This
commit changes this so that the first layout is repeated if necessary.
Related-to: https://github.com/awesomeWM/awesome/issues/1853
Signed-off-by: Uli Schlachter <psychon@znc.in>
If an error occurs while a layout is being applied, arrange_lock could
get stuck at true, meaning that no more re-arranges will happen, thus
breaking the whole layout machinery.
Such errors could happen because the layout itself produces an error,
but also because a width is too large and c:geometry() throws an error.
Thus, this commit moves all of the actual "apply a layout"-code into a
protected context.
Fixes: https://github.com/awesomeWM/awesome/issues/1853
Signed-off-by: Uli Schlachter <psychon@znc.in>
Using `beautiful.get()` has the drawback of not supporting theme
variables set from `rc.lua`. It is also used less often than
direct theme access, making it a bit inconsistent with how other
modules behave.
The return value for this function is used as an index in a table and
Lua does not like nil as an index.
The function that actually looks for icons, find_icon_theme() already
falls back to "hicolor" if it does not find anything via the current
theme, so fix this issue by just falling back to "hicolor" here as well.
Fixes: https://github.com/awesomeWM/awesome/issues/1819
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, the lgi check used the normal Lua interpreter to check if
lgi is installed. However, nothing ensures/requires that awesome is
built against the same Lua version as the Lua interpreter. This means
that if lgi is only available for some Lua version, then the check could
succeed even though awesome would later fail to start. Also, the check
might have failed even though awesome would not have any problems
finding lgi.
This commit replaces lgi-check.sh by a small C program which does the
same thing. This ensures that the same Lua version is used as awesome
will be using.
There are some places that still use the Lua interpreter: Example tests
(run through the Lua interpreter directly) and unit tests (run through
busted). For unit tests, this should not make much of a difference and
example tests might later get similar treatment.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Emmanuel Lepage Vallee
Sorky
Uli Schlachter
Uli Schlachter
Sorky
warptozero
mergify[bot]
Kevin Zander
Aire-One
Daniel Hahler
Daniel Hahler
glenvt18
Yauhen Kirylau
Peter Nerlich
Michele Lazzeri
Sergey Vlasov
tototest99
Aire-One
gabriel klawitter
Alyssa Ross
Michael Perlov
Peter Kasza
Mak Kolybabi
Laszlo Toth
Sam Banks
Rastislav Barlik
Anatolii Aniskovych
Alphonse Mariya
Sagar Tewari
Jim Garrison
Reiner Herrmann
ma9e
Kirill Funtov
Alexander Melnyk
Otto Modinos
get
ikselven
Stefan Loewen
lePerdu
necauqua
getzze
SpiritCroc
Nick Diego Yamane
Florian Gamböck
José Romildo Malaquias
Crazy Lemon
Tomoya Tabuchi
Jan Larres
mqus
morethanoneanimal
Tim Roes
Luke Bonham
SammysHP