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.
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>
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 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 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>
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>
Daniel Hahler
Daniel Hahler
Luke Bonham
Emmanuel Lepage Vallée
Uli Schlachter
Tim Roes
SammysHP
Yauhen Kirylau
nahsi
getzze
Simon Désaulniers
Caleb Maclennan
BuildTools
Uli Schlachter
Quentin Minster
Jonathan
Kevin Zander