Previously, it would use the "real" args passed to the constructor.
It was a bad decision since:
* It doesn't allow the tag/tasklist to add properties internally
* It forces the widget to be created with a constructor rather than
the alternate declarative syntax
* It doesn't allow a tag/tasklist to be part of a widget_template
Technically this is a behavior change, but I doubt anybody will notice
given it is a dark and little documented corner of the API. Chances are
nobody have been using this API for years.
With this helper, it becomes possible to avoid manually setting common
properties such as the client in the tasklist of tag in the taglist when
the children widgets of the template have a set_+property_name.
This decision was taken out of necessity. While adding more style
elements to `awful.widget.common` isn't something I want, there is
little else to do here. The problem is that popup based lists only
have size constraints in one direction. So without a way to limit
the icon size, it will take 9999 pixels.
Instead of having the default template hardcoded as code, this turns the
template into a descriptive version. This makes it easier to come up
with own templates: Just copy the default template and make a slight
change to it.
No functional changes are intended, but I cannot rule out that I did no
mistakes.
Signed-off-by: Uli Schlachter <psychon@znc.in>
There is not much good reason why this should be required and making it
optional is almost trivial, as this patch shows.
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.
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.
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.
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
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.
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.
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 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>
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
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.
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 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>
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>
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>
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.
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>
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()
Emmanuel Lepage Vallée
Uli Schlachter
Uli Schlachter
mergify[bot]
Daniel Hahler
warptozero
Sorky
Yauhen Kirylau
Peter Nerlich
Michele Lazzeri
Sergey Vlasov
tototest99
Aire-One
Alyssa Ross
Peter Kasza
Laszlo Toth
Daniel Hahler
Kevin Zander
Rastislav Barlik
Anatolii Aniskovych
ma9e
Kirill Funtov
ikselven
Stefan Loewen
getzze
SpiritCroc
Nick Diego Yamane
Florian Gamböck
José Romildo Malaquias
Jan Larres
mqus