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>
LGI's async support was trying to yield inside a protected call. Lua 5.1
cannot do that. Work around this by reverting to the behaviour before
commit 50cfa6c: Only call the callback in a protected context.
Fixes: https://github.com/awesomeWM/awesome/issues/1837
Signed-off-by: Uli Schlachter <psychon@znc.in>
Just re-arranging on every focus change would cause useless/needless
re-arranges (which have no effect except to waste CPU time). Thus, this
adds a special (undocumented) flag on layouts that makes sure that a
rearrange occurs when the focus changes.
Fixes: https://github.com/awesomeWM/awesome/issues/1799
Signed-off-by: Uli Schlachter <psychon@znc.in>
This marks the functions gears.surface.widget_to_svg() and
gears.surface.widget_to_surface() as deprecated in awesome 5. This means
that by the time that awesome 6 becomes a thing, we can finally remove
these...
Signed-off-by: Uli Schlachter <psychon@znc.in>
These are supposed to eventually replace the already-existing functions
in gears.surface which have a similar signature
Signed-off-by: Uli Schlachter <psychon@znc.in>
This implementes the FIXME added a few commits ago. A new
request::geometry handler turns client requests into normal
lua `c.maximized = true` property changes.
A relatively common problem with awesome is with mixing sticky clients
and the focus history. Once a sticky client ever had the focus, it will
always get the focus after a tag switch. This is because the focus
history is global and the sticky client is always the most recently
focused and currently visible client in the list.
Work around this by discriminating sticky clients: First try to find a
client to focus, but ignore sticky clients. When this does not find
anything, try again, but this time also consider sticky clients.
(Basically the same issue exists with clients that are on multiple tags,
but I guess that one can be ignored.)
Fixes: https://github.com/awesomeWM/awesome/issues/733
Signed-off-by: Uli Schlachter <psychon@znc.in>
Once upon a time, 4b9584fdb1 already fixed this problem: We have to
set the border width to zero before applying the new geometry to the
client, because changing the border width makes the client move
according to its gravity.
Then came e54387904b and made this code use awful.placement instead
of just fullscreening the client itself (without explaining why in the
commit message!). After this commit, the border width was just ignored
and left as-is. This was then fixed in 0bf8bb6a64 (no idea which
callback the commit message refers to, the old code was basically just
c.border_width=0, c:geometry(screen_geo)). However, now the border width
was again changed after the geometry and the bug that was fixed by
4b9584fdb1 was back.
This commit fixes this regression again by making sure that the border
width is set to zero before the geometry is set. This becomes slightly
more complicated, because now it is also awful.placement's job to
restore the old border width.
This is why this commit adds a new option to awful.placement so that it
sets the border width to zero after creating its memento of the old
border width.
Fixes: https://github.com/awesomeWM/awesome/issues/1607
Signed-off-by: Uli Schlachter <psychon@znc.in>
Change indexing so that a keyboard map with a single group still gets
displayed in awful's keyboardlayout widget.
Signed-off-by: Quentin Minster <quentin@minster.io>
There are some cases where a client's floating state "silently" changes.
For example, a fullscreen client will be considered floating. However,
even though c.floating changes its value in this case, we did not emit
the property::floating signal.
Fix this by explicitly tracking the "implicitly floating" state. When
some property that influences this "implicitly floating" state changes,
we update it and if a client which was not explicitly assigned a
floating state observes a change in this value, property::floating is
emitted.
This was tested by running a terminal and two xeyes in a tag with a
tiling layout where awful.ewmh was patched so that clients do not change
their geometry when fullscreening or maximizing. It was observable that
after this patch e.g. the titlebar and the tasklist update to show the
floating state of the client which became implicitly floating due to
being maximized.
Fixes: https://github.com/awesomeWM/awesome/issues/1662
Signed-off-by: Uli Schlachter <psychon@znc.in>
The previous commit made this code handle invalid directories correctly.
However, it was still possible that we come across invalid file names
for which :get_path() returns nil and then we assumed this was a file
name.
Fix this by silently ignoring such files.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Before this commit, the code always used GFile instances, then used
get_path() for a recursive call and turned the path into a GFile
instance again. This is not only inefficient, but also causes issues
with directories with invalid utf8, because the get_path function
returns nil in this case.
Fix this by keeping things as a GFile all the time.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Regression in v4.1. It causes the `rc.lua` (and the fallback) to
exit when the wallpaper is missing or something went wrong.
In <= 4.0, the wallpaper wasn't loaded, but Awesome didn't "crash".
There should be no asserts in the code called during the first
event loop iteration.
Adds a third parameter "timezone" to the textclock widget that is
optional. Defaults to local timezone if nil.
Signed-off-by: Matt Harrison <matt@harrison.us.com>
Possible use-case could be a do-not-disturb mode where notifications
should be suspended, but some notifications triggered directly by
a user interaction (e.g. change of keyboard layout, etc.) should
still be shown.
Fixes: https://github.com/awesomeWM/awesome/issues/1728
The longer name is a bit more self-explanatory. The plural is meant to
indicate that this recursively creates missing parent directories and
does not just try to create the single given target directory.
Since filesystem.mkdir() is part of the v4.1 release, a deprecation stub
is needed.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes get_cache_dir() try to ensure the cache directory that it
returns exists.
Should-fix: https://github.com/awesomeWM/awesome/issues/1663
Signed-off-by: Uli Schlachter <psychon@znc.in>
The changes should not actually make a difference. If creating the
directory fails, the error will now be different, but that should be
about it.
Signed-off-by: Uli Schlachter <psychon@znc.in>
I didn't actually test this, but at least this now looks like valid Lua
code to me, so this is definitely an improvement.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Most of the entries that are marked as "TODO: Get rid of these" were
handled. wibox.layout.align:get_children() never worked (it always
called a non-existent function), so we can easily fix this entry without
introducing a regression.
I opened https://github.com/awesomeWM/awesome/issues/1672 to track the
underlying problem behind the broken :get_children() function (which is
missing test coverage).
Signed-off-by: Uli Schlachter <psychon@znc.in>
The freedesktop specifications let desktop files be stored in
different directories indicated by the environment variables
XDG_DATA_HOME and XDG_DATA_DIRS.
Only use the default value for these variables if the variables are
not defined.
This is important for systmes like NixOS which does not follow the LFS
and installs files differently.
Swap the parameters the next time the API break / deprecation season is open.
This is indeed confusing, as reported on IRC. The screen is *not* optional,
`awful.tag.find_by_name(name)` wont work
Previously, when gears.geometry.rectangle.get_intersection() was called
with two non-intersecting rectangles, it would return a negative
width/height.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit changes the systray widget, wibox.drawable and the C code to
fix the following bug: When the systray widget is removed from a
drawable without being moved somewhere else, the systray stayed visible.
This was because the systray is not drawn by awesome, but only placed.
When the widget is no longer "drawn", it stays wherever it was placed
last.
This change works by detecting the situation when the systray is
removed. Then, the C code is specifically told to remove the systray
window from the drawable.
Note that this is only a partial fix. This change works correctly when
the widget is removed completely, because it is no longer placed by its
parent widget. However, for example, when you do
wibox.widget.systray().visible = false, the effect is just that the
systray widget gets size 0x0. This is not really visible, but as far as
this change is concerned, the widget is still part of the drawable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This adds new code so that we can count how often a specific widget is
visible inside of all widget hierarchies.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This was broken in 9cb60b8 in PR #1597 (from myself).
focus() is not defined on the screen instance as method
but on the screen module as function.
Signed-off-by: Christoph Mertz <chris@nimel.de>
Fix#1644
* Move table functions out of awful.util into new gears.table
* travis: Use v9999 prefix for full requests
Make sure no newly deprecated functions are used
* Move all `awful.util.table.*` calls to `gears.table.*` calls
Move table test functions from awful/util_spec to new gears/table_spec
Change awful.util.subsets call to gears.math.subsets in awful/key.lua
This adds a new widget that displays the icon of a client. This widget
tries to use the best fitting of the available icons.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The $XDG_DATA_HOME environment variable may not necessarily end in a
slash, so insert it when generating the list of all menu dirs to make
sure the directory can be found.
This extracts the code for finding the next screen
from focus_bydirection to a separate method on
the screen object.
The main reason was to use the finding code without
actually changing the screen focus but this should
incidentally make the code slightly easier to test
as well since both concerns can be tested in
isolation.
Signed-off-by: Christoph Mertz <chris@nimel.de>
Remove dependency to awful and remove get_cell_sizes function
Remove matrix and add superpose property
Update documentation, remove beautiful dep
Add insert, extend and remove columns and rows
Change x and y to horizontal and vertical
This changes a line of code that was added in the previous commit.
Previously, when menubar.cache_entries was set to false,
menubar.refresh() was called twice.
Signed-off-by: Uli Schlachter <psychon@znc.in>
The function seems useless and its documentation is wrong. It does not
return a wibox, but a widget. Also, the widget cannot really be used on
its own since it depends on the size of the wibox.
So menubar.get() and its wrapper through the metatable __call should
just be removed. Until then, the needed initialisation code is moved
around a bit and the function is deprecated.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Every client button type (e.g. minimize, maximize_inactive, maximize_active, close) has the option to show a different icon when the mouse hovers over it or a "button::press" signal is sent.
Signed-off-by: Lego Stax legostax@gmail.com
* wibar: Add beautiful variables
This was done a few weeks ago for the notifications. This was
requested on IRC a while ago to have different font for the wibars.
Now that shapes are supported, it also makes more sense for the
border.
style.disable_task_name and beautiful.tasklist_disable_task_name. Suppresses display of a given client's name, but preserves the setting of tasklist_plain_task_name
Creating a widget already sets a metatable (at least these days).
However, wibox.container.scroll overwrote this metatable with its own
metatable. This commit removes this overwrite.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This makes things fail loudly which otherwise fail without giving a hint
on what went wrong.
Reference: https://github.com/awesomeWM/awesome/issues/1570
Signed-off-by: Uli Schlachter <psychon@znc.in>
If the caller provides a file name, these function load the image, set
it as the wallpaper and make sure that the memory used for the image
data is freed immediately. However, this was also done when the caller
provided a cairo surface, thus breaking their surface.
Fix the code so that it does not finish surfaces that it did not create
itself.
Fixes: https://github.com/awesomeWM/awesome/issues/1570
Signed-off-by: Uli Schlachter <psychon@znc.in>
Fixes
> W: awful: function margin is deprecated, see wibox.layout.margin has been renamed to wibox.container.margin.
to
> W: wibox.layout.margin has been renamed to wibox.container.margin.
It should be called "align", but the name is already taken
It doesn't use awful.placement because it would break the dependency
graph.
Some cases previously required 2 wibox.layout.align layouts,
one for each axis. This is massively overkill to simply place
a widget at the center of a larger area.
* refactor(awful: hotkeys_popup): expose configuration options for a widget instance and use more object-oriented structure for the widget
closes#1352closes#1497
* doc(awful: hotkeys_popup): add @beautiful docstrings
* fix(awful: hotkeys_popup): add label_bg for misc labels; improve @beautiful docstrings
This was previously done in a callback, but wasn't really
clean and/or bug free. Borders could end up leaking on other
screens as proven by an integration test.
Fix#171
And stop listening to property::geometry, it's no longer needed.
This also remove messing up the border without saving it
somewhere. The concept is sound, but not the implementation.
Before this commit, do this:
c.maximize_hoizontal = true
c.maximize = true
c.maximize = false
assert(c.maximize_hoizontal)
Would not work because the states were not preserved individually.
This commit fixes that. Awesome wont be confused about it's own
state anymore.
This may seem pointless, but when it come to undoing these
maximizations, it was ambiguous.
Before 4.0, maximizing could only be done in 2 operations.
4.0 add an unified way, but kept doing 2 operations. The old
Lua EWMH code to serialize the 2 operations was dropped when
the codepath was simplified and replaced by a generic version
in awful.placement. However this version never implemented
combining multiple mementos into 1.
This commit unify the maximize C code, drop the ugly macro
template and actually fixes a couple more issues that were
caused because request::geometry was sent twice.
There is already a way to prevent them from moving them, but the
next few commits will remove it. There is no reasons to handle
this differently from fullscreen clients.
The functions awful.client.shape.update.bounding and .clip handle both
the client's shape and the shape set by Lua. However,
awful.client.shape.update.all only handles the shape set by Lua and
ignores the client's own shape. This can easily be noticed with xeyes.
When update.all ran last and you move around xeyes, the wallpaper behind
it is moved along, because it is not actually outside of the window.
Fix this by partly reverting 1a5f6b7ad2 and having update.all just
call the other two functions again.
Signed-off-by: Uli Schlachter <psychon@znc.in>
In theory it would be enough to only update the old and new screen of
the tag whose screen changed. However, we cannot easily get the old
screen, so just update all layoutboxes.
Fixes: https://github.com/awesomeWM/awesome/issues/1503
Signed-off-by: Uli Schlachter <psychon@znc.in>
As documented in
<https://keithp.com/~keithp/talks/xtc2001/paper/xft.html#sec-editing>,
the fallback value for Xft.dpi should be the vertical DPI reported by X.
On Xorg, this will generally be 96, unless the user has overridden the
value by either forcing Xorg to report the EDID-derived DPI, or by
setting the DPI themselves (via configuration, command line, or xrandr).
The 96 value is kept as ultimate fallback if anything goes wrong.
Commit c50d62749b added an empty table as a default theme. However,
when loading the actual theme fails, we will end up with theme having
value nil. This commit fixes this by reverting back to an empty table.
Fixes: https://github.com/awesomeWM/awesome/issues/1417
Signed-off-by: Uli Schlachter <psychon@znc.in>
This removes some @EXPANSIONS@ from Lua files and removes a hack that
was needed. All is better now! :-)
Signed-off-by: Uli Schlachter <psychon@znc.in>
Also save some boilerplate code.
This closes the gap between timer.start_new and timer.new. Now the
only difference is that one have a special callback format while
the other only has predefined properties.
When menubar.refresh() is called, it tries to update the menubar widget.
The call chain looks like this: menulist_update -> common.list_update ->
get_current_page. get_current_page then tries to query information about
the size of the menubar.
Since there is not much point in this, just skip the whole callback in
this case.
Side note: What is the point of menubar.get()? It seems quite useless to
me.
Signed-off-by: Uli Schlachter <psychon@znc.in>
This bridges between gears.shape and the shapes. So far, it does not try
to do any kind of anti-aliasing magic, so you get "steep edges".
Signed-off-by: Uli Schlachter <psychon@znc.in>
Up to now, a drawable always figured out the screen that it is on by
looking at its position. This causes memleak-like problems with wibars:
A wibar has a screen assigned, but its underlying drawable will end up
referring to another screen. Via this, we were managing to build a long
reference chain of screens and drawable that meant that none of the fake
screens that our test suite added could be garbage collected.
To fix this, add wibox.drawable._force_screen(s). After this function is
called, the normal screen detection based on the position is skipped and
instead the given screen is always used. This breaks the above reference
chain and things become garbage-collectable.
Also, this chains the drawable to the life time of the screen: When the
screen becomes invalid (.valid == false), the drawable will stop
redrawing.
Fixes: https://github.com/awesomeWM/awesome/issues/1237
Signed-off-by: Uli Schlachter <psychon@znc.in>
This commit doesn't add any useful documentation, but adds
previously hidden documentation variables. It can be the basis
of a better layout documentation.
Fix#1246
The function that is documented as awful.wibox.stretch is deprecated,
because it was removed (that's not a deprecation, is it?!?). For the
replacement, we used "@see stretch". However, LDoc was randomly
resolving this reference to awful.wibar.stretch (good) or
awful.wibox.stretch (bad; the see points to the element where it
appears).
Fix this by spelling out the "full name" of the function in the @see.
Related-to: https://github.com/awesomeWM/awesome/issues/834
Signed-off-by: Uli Schlachter <psychon@znc.in>
The only other swap function is awful.tag.swap and that one is
deprecated. Thus, it should not be linked to.
Signed-off-by: Uli Schlachter <psychon@znc.in>
People who use a plain "make install" to install awesome will likely
also use the same approach to update their installation. However, this
does not actually work, because in awesome 3.5 there are beautiful.lua
and naughty.lua. These modules have since been split up into multiple
files and we now have beauitful/init.lua and naughty/init.lua instead.
The result is that the newer awesome will use some code from an older
version of awesome.
This commit has a work-around for this: We add "empty" beautiful.lua and
naughty.lua files whose only purpose is to load the real file. These
"empty" files will then overwrite files from an older installation and
everything works.
Sadly, this bad hack will have to be kept around forever and in the
future we will only have more instances of it. I would like to just say
people to fix their system, but apparently this should be worked around
instead.
Fixes: https://github.com/awesomeWM/awesome/issues/244
Signed-off-by: Uli Schlachter <psychon@znc.in>
Previously, the API to set the data that should be displayed was
:set_data(t) where t is a table. This table has the labels to use as its
keys and the numbers as its values. With this API, it was not possible
to influence the order in which the "pie pieces" were drawn.
This commit adds and uses a new API called :set_data_list(t). Here, t is
a table with integer keys and tables as values, thus one can iterate
over this with ipairs() and the order is well-defined. The tables used
as values contain the label as their first entry and the number as their
second entry.
Fixes: https://github.com/awesomeWM/awesome/issues/1249
Signed-off-by: Uli Schlachter <psychon@znc.in>
Spawn callbacks were never invoked when no startup-notification-rules were
given. This commit fixes the code so that "startup done" callbacks are also
called when no rules were given.
Fixes: https://github.com/awesomeWM/awesome/issues/1218
Signed-off-by: Uli Schlachter <psychon@znc.in>
The usual "a or b"-trick to simulate C's ?:-operator does not work when
"false" is a valid value. Fix the code to handle this correctly and add
a short unit test which would have caught this problem.
Signed-off-by: Uli Schlachter <psychon@znc.in>
We already have a variant of this function for transforming an actual
matrix. This adds the corresponding static factory.
Signed-off-by: Uli Schlachter <psychon@znc.in>
Instead of doing Linux-specific magic with error codes and trying to
read the first byte of a file, just use Gio to check if a file exists
and is readable.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When adding callbacks as a `callback` entry in a property, the callback
is run by `awful.rules`, because it does `c.callback =
result_of_function`. This is obviously not intended. Also, this causes
the callbacks to run twice, because the code already handled this
`callback` property specially.
Fix this by just not merging callbacks with the normal rules at all.
Fixes: https://github.com/awesomeWM/awesome/issues/1159
Signed-off-by: Uli Schlachter <psychon@znc.in>
For some reason, the code here tried to handle widget::redraw_needed
signals even though it should apparently/obviously only produce a
current snapshot of the widget's look.
Fix this by just removing the redraw code.
While here, also factor out the widget context table into a local
variable and re-use it for the initial layout and for the later draw.
Signed-off-by: Uli Schlachter <psychon@znc.in>
When awesome calls any Lua code, it does so with a protected call. This
means that any kind of Lua error should (there are exceptions) just
result in an error message being printed and everything continuing as
usual. When LGI calls Lua code, it uses a normal call. This means that
in an asynchronous context, that is, when there is no more call
generated by awesome's C code on the call stack, we must be careful,
since any error results in Awesome's unprotected error handler to be
called which restarts the WM.
menubar.utils.parse_dir() asynchronously parses a directory containing
.desktop files. This means that it is no longer in a protected call
context. Let's assume that the code itself is fine. However, the
callback that the caller provided for handling the results can be quite
arbitrary. Make sure that it is run in a protected context.
Helps-with: https://github.com/awesomeWM/awesome/issues/1173
Signed-off-by: Uli Schlachter <psychon@znc.in>
necauqua
Uli Schlachter
Daniel Hahler
Emmanuel Lepage Vallee
Uli Schlachter
Zach Peltzer
Yauhen Kirylau
getzze
SpiritCroc
Kevin Zander
Nick Diego Yamane
Florian Gamböck
José Romildo Malaquias
Crazy Lemon
Tomoya Tabuchi
Jan Larres
mqus
morethanoneanimal
Daniel Hahler
Tim Roes
Luke Bonham
SammysHP
nahsi
Simon Désaulniers
Caleb Maclennan
Haochen Tong
BuildTools
Benoit de Chezelles
Quentin Minster
Thomas G
Matt
paul-axe
axujen
Jonathan
FireFish5000
Lego Stax
Patrick Uven
Luke Bonham
Christoph Mertz
0x041E
Samuel Hunter
Drauthius
morethanoneanimal
Jonathan McCrohan
Holger Schurig
Giuseppe Bilotta
Alexander Gehrke
rob
Michael Beaumont
Haochen Tong