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>