Hi,

I'll let a wall of text speak for itself:

E: awesome: signal_fatal:254: signal 11, dumping backtrace
./awesome(backtrace_get+0x41) [0x423f12]
./awesome() [0x40ccea]
/lib/x86_64-linux-gnu/libc.so.6(+0x35180) [0x7fa5bec4d180]
/lib/x86_64-linux-gnu/libc.so.6(cfree+0x14) [0x7fa5bec944a4]
/lib/x86_64-linux-gnu/libglib-2.0.so.0(g_string_free+0x3b) [0x7fa5c146a83b]
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0(g_boxed_free+0x13b) [0x7fa5c171d70b]
/usr/lib/x86_64-linux-gnu/lua/5.1/lgi/corelgilua51.so(+0xed5e) [0x7fa5baf8cd5e]
/usr/lib/x86_64-linux-gnu/lua/5.1/lgi/corelgilua51.so(lgi_marshal_2lua+0x3cc) [0x7fa5baf9020c]
/usr/lib/x86_64-linux-gnu/lua/5.1/lgi/corelgilua51.so(+0x82ca) [0x7fa5baf862ca]
/usr/lib/x86_64-linux-gnu/lua/5.1/lgi/corelgilua51.so(+0xa1c6) [0x7fa5baf881c6]
/usr/lib/x86_64-linux-gnu/liblua5.1.so.0(+0xc1f0) [0x7fa5bf5161f0]
/usr/lib/x86_64-linux-gnu/liblua5.1.so.0(+0x16d42) [0x7fa5bf520d42]
/usr/lib/x86_64-linux-gnu/liblua5.1.so.0(+0xc64d) [0x7fa5bf51664d]
/usr/lib/x86_64-linux-gnu/liblua5.1.so.0(+0xb92e) [0x7fa5bf51592e]
/usr/lib/x86_64-linux-gnu/liblua5.1.so.0(+0xc7bb) [0x7fa5bf5167bb]
/usr/lib/x86_64-linux-gnu/liblua5.1.so.0(lua_pcall+0x5c) [0x7fa5bf51242c]
./awesome() [0x4191ac]
./awesome(luaA_parserc+0x61) [0x41bdc0]
./awesome(main+0x863) [0x40d6a6]
/lib/x86_64-linux-gnu/libc.so.6(__libc_start_main+0xf5) [0x7fa5bec39b45]
./awesome() [0x40ca59]

So I bisected and found:

$ git bisect good
0a76e41cb850e67c34085a4e3aa87b11424588d7 is the first bad commit
commit 0a76e41cb850e67c34085a4e3aa87b11424588d7
Author: Daniel Hahler <[email protected]>
Date:   Tue Feb 10 00:59:15 2015 +0100

    Use lgi.GLib.String():append(tb):hash()

:040000 040000 d7ec53bbf2b9e5104eac6deed572aee6f11093e7     7f3f56c3384068ecc9dd979d3529a0491121866a M  lib

A quick experiment confirms:

$ lua -e 'require("lgi").GLib.String():append("foo")'
*** Error in `lua': munmap_chunk(): invalid pointer: 0x00000000007ea2e0 ***
[1]    11823 abort      lua -e 'require("lgi").GLib.String():append("foo")'

Looking at lgi's lgi/override/GLib.lua I can't find anything interesting, so I guess the bug must be in GLib. I have glib 2.42.1 installed and a quick look into glib's git repo didn't find anything that would explain this behavior.

I would suggest to just stop using GLib.String() (you only call it for the hash anyway) and use the backtrace string directly as key in the table.

By the way: lua intern's strings anyway (so a pointer uniquely identifies the string), so it kind-of hashes the string already. Going through lgi to obtain another hash cannot really speed things up much, I guess.

Edit:

Now I think that this bug is in lgi:

[...]
==12951== Command: lua -e require("lgi").GLib.String():append("foo")
==12951== 
==12951== Invalid read of size 8
==12951==    at 0x6863830: g_string_free (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.1)
==12951==    by 0x63B170A: g_boxed_free (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==12951==    by 0x5F65D5D: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.1-lgi.so.0.0.0)
[...]
==12951==  Address 0x5c80510 is 0 bytes inside a block of size 24 free'd
==12951==    at 0x4C29E90: free (in /usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==12951==    by 0x6863822: g_string_free (in /lib/x86_64-linux-gnu/libglib-2.0.so.0.4200.1)
==12951==    by 0x63B170A: g_boxed_free (in /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0.4200.1)
==12951==    by 0x5F65D5D: ??? (in /usr/lib/x86_64-linux-gnu/liblua5.1-lgi.so.0.0.0)
==12951==    by 0x5F6920B: lgi_marshal_2lua (in /usr/lib/x86_64-linux-gnu/liblua5.1-lgi.so.0.0.0)
[...]

I will also open a bug report there, but for now awesome cannot use this function.

Since upgrading to 3.5.5 my maximized windows, such as Firefox in a floating tab, overlap my bottom wibox by the height of my top menubar. Not sure why this is coming up now, but I did some initial investigation and I found the most relevant code.

I have confirmed that this works with the latest git version and a default rc.lua with two modifications.

Create a bottom wibox in the screen creation loop:

-- Create a wibox for each screen and add it
mywibox = {}
mywibox_bot = {}

...

-- Create the wibox
mywibox[s] = awful.wibox({ position = "top", screen = s })
mywibox_bot[s] = awful.wibox({ position = "bottom", screen = s })

Enable titlebars:

local titlebars_enabled = true
if titlebars_enabled and (c.type == "normal" or c.type == "dialog") then

With those changes, you may reproduce by:

• Going to a tag with a floating layout.
• Open a window that should normally be floating (Firefox or the Arduino IDE in my case).
• Maximize the window. Notice that it does not occlude the bottom wibox.
• Soft restart awesome.
• You should see the floating window (still maximized) covering the bottom wibox.

I have tracked down the offending geometry adjustment to titlebar_resize in objects/client.c line 1678 (30b313f), specifically:

static void
titlebar_resize(lua_State *L, int cidx, client_t *c, client_titlebar_t bar, int size)
{
...
switch (bar) {
    case CLIENT_TITLEBAR_TOP:
        geometry.height += change; //  when commented, the issue disappears
        property_name = "property::titlebar_top";

I don't understand all of the subtleties with window geometry and I don't know the best solution to this problem. I'm not even sure if this needs to be fixed in the LUA libraries or the C code! More research is required on my part.

Linux: 3.17.6-1-ARCH
Awesome: v3.5.2-225-g30b313f (The Fox)
Eclipse: Luna Service Release 1 (4.4.1)
Java: java-8-jdk, java-8-jre/jre (Oracle), or OpenJDK

Pressing Ctrl+Space in Eclipse activates the content assist. The content assist window with a list of proposals will appear. When I choose an item of the list with the mouse or when I press the Tab-key to give focus to the content assist window, the content assist will stop working flawless: Each time, I hover the cursor above the content assist window, it disappears immediately. I can temporarily fix the content assist, by moving Eclipse to another workspace. But choosing an item of the proposal list with the mouse will corrupt the content assist window again.

I read about the problems with non-reparenting window managers and java (though awesome is a reparenting WM now, I guess) on http://awesome.naquadah.org/wiki/Problems_with_Java: I could not fix the problem.

I replaced awesome 3.5 with awesome 3.4: The problem vanishes, Eclipses content assist works flawless.

P. S.: The same problem occurs to the tooltip-windows in Eclipse: to give focus to a tooltip-window will cause the next calling of a tooltip-window AND completion-window to fail. The problem is related to JFace. Two snippets with the same problem:

• autocomplete snippet
• tooltip snippet

Awesome is not the only tiling-WM having this problem:

Same bug as Awesome:

• bspwm 0.8.9
• wmii 3.9.2
• i3 4.8
• qtile 0.8.0
• spectrwm 2.6.1
• wmfs2 (-g3c701a9) 2 beta

No problems with Eclipse detected:

• dwm 6.0
• herbstluftwm 0.6.2
• frankenwm
• notion
• ratpoison 1.4.8
• subtle 0.11.3243
• wmfs
• xmonad 0.11

b4c83d0 breaks dialogs.

They now appear to get handled as tiled first, before being set to floating state (not sure about that latter, since they not necessarily are displayed in the taskbar).

TEST CASE:

1. in GVim (in a tiled layout)
2. :call inputdialog("foo")

The dialog box will appear tiled (oversized) as master.

It is probably caused by this change: b4c83d0#diff-7de93d6ae06f822664ee72cf4127a1e8L616

Someone asked for how to do this on IRC. I think it is a good idea, should we do this by default?

Addition to rc.lua:

client.connect_signal("property::maximized", function(c) 
    c.border_width = c.maximized and 0 or beautiful.border_width
end)

I need a Moon Calendar, which show up the calendar http://en.wikipedia.org/wiki/Lunisolar_calendar

its possible to realize it in additon to the currentyl existing calendar?

this is f.e.: es js code for such kind od calendar: http://kde-apps.org/content/show.php/Vietnamese+lunar+calendar?content=150816

client, tag, screen, drawable, key and drawin should have their (unknown) property handler delegated to lua.

This API could be used to:

• Implement dynamic properties (replace awful.{...}.getproperty / setproperty)
• Forward property to awful.{client, tag,...}.set_ and get_ when they exist
• Other use

Those handlers should be per object (because someone will eventually complain if they aren't) but always fallback to a common (per class) handler.

New API for all objects:
.index_handler (property with set and get)
.newindex_handler (property with set and get)

I've started with adding integration with Travis in a separate branch.

1. "make check" fails with 3 errors, which are related to assert not being special as it should be. Line 51 is this:

   assert:register("assertion", "widget_fit", widget_fit, "assertion.widget_fit.positive", "assertion.widget_fit.positive")

   43 successes / 0 failures / 3 errors / 0 pending : 0.06 seconds
   Error → spec/wibox/test_utils.lua @ 51
   ./spec/wibox/layout/align_spec.lua
   spec/wibox/test_utils.lua:51: attempt to index global 'assert' (a function value)
   Error → spec/wibox/test_utils.lua @ 51
   ./spec/wibox/layout/flex_spec.lua
   spec/wibox/test_utils.lua:51: attempt to index global 'assert' (a function value)
   Error → spec/wibox/test_utils.lua @ 51
   ./spec/wibox/layout/fixed_spec.lua
   spec/wibox/test_utils.lua:51: attempt to index global 'assert' (a function value)
   make[3]: *** [CMakeFiles/check] Error 3
   make[2]: *** [CMakeFiles/check.dir/all] Error 2
   make[1]: *** [all] Error 2
   make: *** [cmake-build] Error 2
   The command "make" failed and exited with 2 during .

2. I'd like to run the functional tests on Travis, and tried using Xvfb for
   this (which is installed on Travis:
   http://docs.travis-ci.com/user/gui-and-headless-browsers/).

   There are assertion errors from lib/gears/debug.lua:

   lib/gears/debug.lua:23: Assertion failed: 'Cairo context entered error state: INVALID_FORMAT'
   stack traceback:
   lib/gears/debug.lua:23: in function 'assert'
   lib/wibox/drawable.lua:65: in function 'do_redraw'
   lib/wibox/drawable.lua:245: in function <lib/wibox/drawable.lua:243>
   [C]: in function 'pcall'
   lib/gears/timer.lua:103: in function <lib/gears/timer.lua:101>
   lib/gears/debug.lua:23: Assertion failed: 'Cairo context entered error state: INVALID_FORMAT'

The functional tests can be run headless locally using:

   CI=true t/run.sh

Builds can be seen at https://travis-ci.org/blueyed/awesome/branches / https://travis-ci.org/blueyed/awesome.

NOTES:

• shared-mime-info is required for gdk-pixbuf to recognize images from files. Errors looked like this: error: lib/gears/surface.lua:39: Couldn't recognize the image file format for file /usr/local/share/awesome/themes/default/background.png'' (with the very minimal / teared down ubuntu:precise Docker image).

When specifying border colors in an awesome theme, the alpha channel is ignored.
Far as I can tell, only the border colors are affected, but I have only played around
with the values supplied in the default theme.

Current behavior:

Consider this screenshot: https://paste.xinu.at/ckn2U/

For the titlebar, the alpha channel works, with the color being "#7fff00b4".
The border, being assigned a color of "#7fff0000", should be invisible, but isn't transparent at all.

Expected behavior:

For the borders to honor the alpha channel, which for the supplied example values would mean
the border would be fully transparent.

PS: Someone in the IRC channel implied that the alpha channel is actively stripped/otherwisely ignored in the C part of awesome; And while the lua part of awesome does have a function to strip the alpha channel from a color, I haven't seen it applied to any border property.

Hi,

On current master there seems to be a race condition, that sometimes makes focus go wrong on new clients. This was made manifest after #118, but I guess it was there hidden before that.

I have configured awesome to set focus on new clients via a rule focus = true. For me, it doesn't work for the first client in a tag, but does work when the tag already has a client. After introducing some printf's in the right places, I observed this sequence of calls after creating a new client:

EDIT: It turns out the client always gets focus! What happens in case A below is that the focus signal fails to set the border color for the client. I was just looking at that to tell when a client has focus or not... sorry!

A. Case in which focus does not work (no clients in a tag)

1. client_focus
2.   client_focus_update (focused_new = 1)
3. client_focus
4.   client_focus_update (focused_new = 0)
5. client_focus_refresh
6. client_focus_update (focused_new = 0)

B. Case in which focus does work (with existing clients in a tag)

1. client_focus
2.   client_focus_update (focused_new = 1)
3. client_focus_refresh
4. client_focus
5.   client_focus_update (focused_new = 0)

I think what makes the focus work or not is the ordering of those calls, and not the fact that the tag is empty or not. That the second implies the first may be just a matter of timings... However I'm not 100% sure of that.

From the data above, there are two things that seem wrong to me plus a mystery:

1. Why on earth client_focus is called twice for a client?
2. Assuming the hypothesis that the ordering is what breaks the focus, it is wrong that the relative ordering between the second client_focus and client_focus_refresh has an effect on the focus behaviour.
3. Who calls client_focus_update in A.6 ??

I'm sorry for not being able to be more helpful. I don't fully understand the way signals work in awesome (it is a bit of a mess), and don't have the time to look deeper right now... However I can do any test you want!

I am looking into adding a awesome-git package to Nix / nixpkgs, and it uses --depth 1 when fetching the git source, which does not allow for "git describe" to work properly.

I've seen another build definition, which passes in makeFlags = "VERSION=v${version} GIT_VERSION=v${version}"; (https://github.com/NixOS/nixpkgs/blob/master/pkgs/applications/editors/emacs-modes/haskell/git.nix), which might be helpful in this regard.

My current workaround is not using Git to fetch it (which is good anyway), and then write the version to .version-stamp manually.

While the current approach is good enough for me in this case, it might be nice to support passing in VERSION maybe for this?

It would be useful to also store Lua tables in X properties.

Awesome would need to handle (de)serializing them in luaA_get_xproperty and luaA_set_xproperty probably.

This would allow for adding e.g. floating_geometry to the persistent properties for clients.

When using fake inputs with or without keygrabbers, Awesome always intercepts the input. While this is the expected behavior, it doesn't cover many use cases. Awesome needs to support sending raw inputs to clients without intercepting them. The workaround when using keygrabber is to stop and restart it between fake inputs, but there is no equivalent hack for capi.key.

Original:
In the docs for awful.keygrabber, it's mentioned that a keygrabber can return false to pass the keypress to the next grabber on the stack. As far as I can tell, although a stack is maintained in awful.keygrabber, keygrabber.c simply passes the keys to the last run grabber and a keygrabber will swallow a keypress no matter what.

It would make keygrabbers much more flexible if they behaved as described.

Systray seems that is not working with qt5 trays (dropbox for example) and appear with a strange grey background.

I googled about it and found some other people with the same problem and it was, initially, a Qt5 bug. But nowadays the issue seems that was fixed( https://qt.gitorious.org/qt/qtbase/source/34ce66cd89ea1c618d8f63dd2d9b95aed0a81b11:dist/changes-5.4.0#L436 ) and tint2, lxde, xfce can render the transparency correcly now but this behavior persists in awesome.

I'm running awesome v3.5.6

I find when I Mod4 + N a window (minimize it), I'm unsure what window next has focus. With the default theme, the focussed window has a very subtle outline. I could check in the bar at the top.

Better would be for the focus to follow the mouse as it usually does. So, if I minimize a window, the new window that is now under my cursor has focus and would be the next one to be minimized if I were to hit Mod4 + N again.

As it is, I find myself reaching for the mouse and wiggling it out of the window it's currently over and back again to get the focus to settle on that window.

When using < ("less") in a global keybinding, , (comma) in a client keybinding does not work.

globalkeys = awful.util.table.join(
    ....
    awful.key({ modkey }, "less",  function () naughty.notify({text="less"}) end),

clientkeys = awful.util.table.join(
    ...
    awful.key({ modkey }, ",", function(c) naughty.notify({text="comma"}) end),

I've tried using < and comma instead.
I am using a German keyboard layout, and < is next to the left shift and comma right next to m.

Output from xev:

For <:

KeyRelease event, serial 34, synthetic NO, window 0x3a00001,
    root 0x94, subw 0x0, time 393382277, (438,630), root:(439,631),
    state 0x10, keycode 94 (keysym 0x3c, less), same_screen YES,
    XLookupString gives 1 bytes: (3c) "<"
    XFilterEvent returns: False

For ,:

KeyRelease event, serial 34, synthetic NO, window 0x3a00001,
    root 0x94, subw 0x0, time 393403254, (103,14), root:(104,15),
    state 0x10, keycode 59 (keysym 0x2c, comma), same_screen YES,
    XLookupString gives 1 bytes: (2c) ","
    XFilterEvent returns: False

When using both in globalkeys it works.

I might be doing something stupid here, but I've been using the mapping with comma since a while already.

Awesome Version 3.5.6-1 (from the arch-community repo)

I am using an alternative keyboard layout (using setxkbmap de neo, after I started awesome wm), which utilizes CapsLock and AltGr to get more than 2 layers. (example: a, A, {, <DOWN>, α and ∀ are all located on the qwerty-key d and caps+d gives you {)

The Run- and the Lua-prompt are ignoring those additional modifiers (Caps, AltGr). The result is just the letter from layer 1.

 $ awesome --version                                                                                                                                                                              
  awesome v3.5.6 (For Those About To Rock)
 • Build: Jan 14 2015 20:56:29 for x86_64 by gcc version 4.8.2 (buildd@lgw01-04)
 • Compiled against Lua 5.1.5 (running with Lua 5.1)
 • D-Bus support: ✔

After an upgarde on my ubuntu host I have rendering problems with several (but not all) applications.
Attached below is an image of chromium after i switched away and back to a workspace running chromium. The window is not rendered fully.

For other apps this never happens. For example gnome-terminal or gedit. There are no problems at all
with the applications running on other window managers. Some of the upgraded packages (which might be relevant):

  2015-03-26 08:51:21 upgrade libdrm-intel1:i386 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:22 upgrade libdrm-intel1:amd64 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:22 upgrade libdrm-nouveau2:i386 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:23 upgrade libdrm-nouveau2:amd64 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:23 upgrade libdrm-radeon1:i386 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:23 upgrade libdrm-radeon1:amd64 2.4.56-1~ubuntu1 2.4.56-1~ubuntu2
  2015-03-26 08:51:23 upgrade x11-common:all 1:7.7+1ubuntu8 1:7.7+1ubuntu8.1
  2015-03-26 08:51:24 upgrade xserver-common:all 2:1.15.1-0ubuntu2.6 2:1.15.1-0ubuntu2.7
  2015-03-26 08:51:25 upgrade libgles2-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:26 upgrade xserver-xorg-core:amd64 2:1.15.1-0ubuntu2.6 2:1.15.1-0ubuntu2.7
  2015-03-26 08:51:26 upgrade libgl1-mesa-dri:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:27 upgrade libgl1-mesa-dri:i386 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:28 upgrade libgl1-mesa-glx:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:29 upgrade libgl1-mesa-glx:i386 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:29 upgrade libglapi-mesa:i386 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:30 upgrade libglapi-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:30 upgrade libwayland-egl1-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:30 upgrade libegl1-mesa-drivers:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:31 upgrade libxfont1:amd64 1:1.4.7-1ubuntu0.1 1:1.4.7-1ubuntu0.2
  2015-03-26 08:51:32 upgrade libgbm1:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:32 upgrade libopenvg1-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:33 upgrade libegl1-mesa:amd64 10.1.3-0ubuntu0.3 10.1.3-0ubuntu0.4
  2015-03-26 08:51:33 upgrade libgudev-1.0-0:amd64 1:204-5ubuntu20.9 1:204-5ubuntu20.10
  2015-03-26 08:51:34 upgrade libicu52:amd64 52.1-3 52.1-3ubuntu0.2

chromium itself and spotify were both also updated. But as I said they are rendered just fine in other window managers. Please let me know if there is any other useful info I could provide. I have
absolutely no idea how to solve this issue right now.

i use dvorak layout(but it is not important for this question)
and on my 3 level of layout i have useful symbols like digits and arrows
so
AltGr + a = 4
AltGr + o = 5
AltGr + e = 6

AltGr + h = left
AltGr + t = Down
AltGr + n = UP
AltGr + s = Right

But, in awesome wm 3 level doesn't work, and i don't understand why.
for example
awful.key({ modkey }, "Left", awful.tag.viewprev ),
awful.key({ modkey }, "Right", awful.tag.viewnext ),
it's works with simple arrows on keyboard, but not works with level3 arrows.

can I build awesome without that? and if so, how? or if it imposible, why?

Set theme.bg_focus to an invalid color string and try to open the menubar. I would expect the menubar to open with some placeholder color (e.g. white), since this is the behavior of other wiboxes when given invalid colors. Instead, you get this error

W: awesome: luaA_dofunction:78: error while running function
stack traceback:
        [C]: in ?
        [C]: in function 'error'
        /usr/share/awesome/lib/wibox/widget/textbox.lua:61: in function 'set_markup'
        /usr/share/awesome/lib/awful/prompt.lua:225: in function 'run'
        /usr/share/awesome/lib/menubar/init.lua:276: in function 'show'
        /home/max/.config/awesome/rc.lua:256: in function 'press'
        /usr/share/awesome/lib/awful/key.lua:42: in function </usr/share/awesome/lib/awful/key.lua:42>
error: attempt to concatenate a userdata value

This error occurs because Pango.set_markup does not handle invalid colors well and no attempt is made to check the color before sending it. There are two problems here:

1. By default, the menubar formats the cursor using text, and it gets the text color from theme.bg_focus which is not guaranteed to be a color (it could be some other pattern). Perhaps a new theme color needs to be added e.g. theme.cursor.
2. The regular text color is taken from theme.fg_focus, which again does not check the color string. If you set it to an invalid string the menubar will again refuse to open and you'll see <Invalid Text> in the taglist and tasklist.

Generating man pages for awesome wm failes even xmlto,docbook-xml,docbook-xsl install. Here is the output log of the failure
http://pastebin.com/2iaAvUpm

After a client has become invalid, e.g. after c:kill(), testing for it should be false.

Currently a test for it is true, but then calling a method on it generates error ("invalid object").

So, whenever luaA_checkudata (source ref) would generate that error, testing the object itself should return false/nil already.

It happens to me time to time (about twice per month I think) that keyboard stops responding as usual. If I hit a key, nothing happens. But if I hold a key, it starts writing after a while (but I need to hold every key from that time to be able to write anything).

Restart of Awesome doesn't help.
Quit Awesome and login again does help.

nenadalm@localhost:~$ awesome -v
awesome v3.5.5 (Kansas City Shuffle)
 • Build: Apr 14 2014 18:44:32 for x86_64 by gcc version 4.8.2 (mockbuild@)
 • Compiled against Lua 5.2.2 (running with Lua 5.2)
 • D-Bus support: ✔

nenadalm@localhost:~$ cat /etc/issue
Fedora release 20 (Heisenbug)
Kernel \r on an \m (\l)

i tried to use that method to send a signal via dbus to other applications, but signal was not received in any applications there i tried and method was always returning true

did anyone used it in the config? i can't figure out what am i doing wrong, here is an example for spotify:

  local result = dbus.emit_signal(
    "session",
    '/org/mpris/MediaPlayer2',
    'org.mpris.MediaPlayer2.spotify',
    'Next'
  )

from dbus-monitor output it looks like that:

correct call:

method call sender=:1.735 -> dest=org.mpris.MediaPlayer2.spotify serial=5 path=/org/mpris/MediaPlayer2; interface=(null); member=Next

resulting call from the example above:

signal sender=:1.724 -> dest=(null destination) serial=16 path=/org/mpris/MediaPlayer2; interface=org.mpris.MediaPlayer2.spotify; member=Next

so it seems like my problem what i don't know how to set the destination

Set theme.bg_normal to a nonexistent PNG file (e.g. "png:bg.png") and start awesome - it will crash. The error is:

error while running function
stack traceback:
        [C]: in function 'load_image'
        /usr/share/awesome/lib/gears/surface.lua:39: in function </usr/share/awesome/lib/gears/surface.lua:24>
        (...tail calls...)
        /usr/share/awesome/lib/gears/color.lua:73: in function '?'
        /usr/share/awesome/lib/gears/color.lua:202: in function </usr/share/awesome/lib/gears/color.lua:187>
        (...tail calls...)
        /usr/share/awesome/lib/wibox/widget/background.lua:74: in function 'set_bg'
        /usr/share/awesome/lib/awful/menu.lua:394: in function 'add'
        /usr/share/awesome/lib/awful/menu.lua:651: in function </usr/share/awesome/lib/awful/menu.lua:620>
        (...tail calls...)
        /home/max/.config/awesome/rc.lua:103: in main chunk
error: /usr/share/awesome/lib/gears/surface.lua:39: Failed to open file 'bg.png': No such file or directory
error while running function
stack traceback:
        [C]: in function 'load_image'
        /usr/share/awesome/lib/gears/surface.lua:39: in function </usr/share/awesome/lib/gears/surface.lua:24>
        (...tail calls...)
        /usr/share/awesome/lib/gears/color.lua:73: in function '?'
        /usr/share/awesome/lib/gears/color.lua:202: in function </usr/share/awesome/lib/gears/color.lua:187>
        (...tail calls...)
        /usr/share/awesome/lib/wibox/drawable.lua:133: in function 'set_bg'
        /usr/share/awesome/lib/wibox/drawable.lua:265: in function </usr/share/awesome/lib/wibox/drawable.lua:230>
        (...tail calls...)
        /usr/share/awesome/lib/wibox/init.lua:110: in function </usr/share/awesome/lib/wibox/init.lua:106>
        (...tail calls...)
        /usr/share/awesome/lib/naughty.lua:440: in function 'notify'
        /etc/xdg/awesome/rc.lua:18: in main chunk
error: /usr/share/awesome/lib/gears/surface.lua:39: Failed to open file 'bg.png': No such file or directory
E: awesome: main:535: couldn't find any rc file

If theme.bg_focus is given an nonexistent PNG, it does slightly better. Rather than a full crash, awesome loads the default config and shows a notification:

error while running function
stack traceback:
        [C]: in function 'load_image'
        /usr/share/awesome/lib/gears/surface.lua:39: in function </usr/share/awesome/lib/gears/surface.lua:24>
        (...tail calls...)
        /usr/share/awesome/lib/gears/color.lua:73: in function '?'
        /usr/share/awesome/lib/gears/color.lua:202: in function </usr/share/awesome/lib/gears/color.lua:187>
        (...tail calls...)
        /usr/share/awesome/lib/wibox/widget/background.lua:74: in function 'set_bg'
        /usr/share/awesome/lib/awful/widget/common.lua:82: in function 'update_function'
        /usr/share/awesome/lib/awful/widget/taglist.lua:130: in function 'taglist_update'
        /usr/share/awesome/lib/awful/widget/taglist.lua:171: in function 'u'
        /usr/share/awesome/lib/awful/widget/taglist.lua:194: in function </usr/share/awesome/lib/awful/widget/taglist.lua:164>
        (...tail calls...)
        /home/max/.config/awesome/rc.lua:178: in main chunk
error: /usr/share/awesome/lib/gears/surface.lua:39: Failed to open file 'bg_f.png': No such file or directory
W: awesome: color_parse:58: awesome: error, invalid color 'png:bg_f.png'
W: awesome: color_init_unchecked:96: awesome: error, invalid color 'png:bg_f.png'

Both behaviors are unexpected, since awesome does not crash at all when given invalid theme colors - it simply substitutes placeholders.

After one of the patches merged yesterday tags are not losing "urgent" state after receiving it.

Under Slackware current without adding manually

target_link_libraries(${PROJECT_AWE_NAME}
${AWESOME_COMMON_REQUIRED_LDFLAGS}
${AWESOME_REQUIRED_LDFLAGS}
${AWESOME_OPTIONAL_LDFLAGS}
${CMAKE_DL_LIBS})

awesome make fail

Entering a "magic character" for Lua patterns in the menubar causes it to freeze and issue an error, e.g., after entering only a "%":

W: awesome: event_handle_key:586: error running function: /usr/share/awesome/lib/menubar/init.lua:140: malformed pattern (ends with '%')

The menubar then can't be closed without reloading Awesome.

How should the following behave when called from tag 1, and with clients on tag 2?

echo 'client.focus = tags[1][2]:clients()[1]' | awesome-client

Currently it moves the input focus over to the client on the other tag, but does not switch the tag.

Is this the expected behavior after 6183d85?

What should happen for client.focus:raise() where client.focus is not visible (e.g. after the above)?

I would like to document the expected behavior in some tests.

The transient_for property does not get setup when restarting awesome.

The X property itself is still set.

Since awesome 3.5.6, closing a program from the systray (right click->close) makes the keyboard totally unresponsive. No keys work, neither the default ones nor my own keybinds. Tested with Dropbox and Google-MusicManager (I have no other programs that make use of the systray). To restore keyboard's functionality it's necessary to change tag by clicking with the mouse on the statusbar. No other action is sufficient to make the keyboard responsive again.

awesome v3.5.6 (For Those About To Rock)
 • Build: Jan 10 2015 23:18:34 for x86_64 by gcc version 4.9.2 (builduser@)
 • Compiled against Lua 5.2.3 (running with Lua 5.2)
 • D-Bus support: ✔

As X will be discarded in a short time by Fedora and Ubuntu etc. GNOME, KDE etc are being directly compatible with Wayland (or Mir ). Even with e19 release the enlightment window manager also directly supports wayland.
Is there any plan /roadmap for awesome for porting to wayland

It's seems like double value goes to nil, while string or integer works ok. Is it bug or my local problem? Simple test:

dbus.request_name("session", "ru.console.test")
dbus.add_match("session", "interface='ru.console.test', member='Value'" )
dbus.connect_signal("ru.console.test",
    function (...)
        local data = {...}
        naughty.notify({ text = "data table size " .. #data .. "; value " .. tostring(data[2]) })
    end
)

Check with

dbus-send --session --dest=org.naquadah.awesome.awful /ru/console/test ru.console.test.Value double:0.5
dbus-send --session --dest=org.naquadah.awesome.awful /ru/console/test ru.console.test.Value int32:5

/* Client module new index.
 * \param L The Lua VM state.
 * \return The number of pushed elements.
 */
static int
luaA_client_module_newindex(lua_State *L)
{
    const char *buf = luaL_checkstring(L, 2);
    client_t *c;

    if (A_STREQ(buf, "focus"))
    {
        c = luaA_checkudata(L, 3, &client_class);
        client_focus(c);
    }

    return 0;
}

This code prevent capi.client.focus = nil to work. There doesn't seem to be a non-hacky way to remove the focus. A potential solution is to check nil there and set globalconf.focus.client and globalconf.focus.need_update = true; manually

Here we are again,

For the zillion-th time, someone asked for it, so I got bored of the same feature request and hacked it. Here is the code:
Elv13@bb987e4

I need some feedback before porting this to master and doing a proper PR.

It seem to work fine. Is it useful: no. Does it look nice: maybe. Will I recommend anyone using that: no

The taglist code defines:

if not tag.getproperty(t, "icon_only") then

However, this property does not have a signal attached in tag.lua which results in following warnings from awesome when tags have this property:

W: awesome: luaA_object_emit_signal:291: Trying to emit unknown signal 'property::icon_only'
W: awesome: signal_object_emit:239: Trying to emit unknown signal 'property::icon_only'

Fix is fairly trivial:

diff --git a/lib/awful/tag.lua.in b/lib/awful/tag.lua.in
index b1ddca3..3fab3c1 100644
--- a/lib/awful/tag.lua.in
+++ b/lib/awful/tag.lua.in
@@ -670,6 +670,7 @@ capi.tag.connect_signal("request::select", tag.viewonly)

 capi.tag.add_signal("property::hide")
 capi.tag.add_signal("property::icon")
+capi.tag.add_signal("property::icon_only")
 capi.tag.add_signal("property::layout")
 capi.tag.add_signal("property::mwfact")
 capi.tag.add_signal("property::ncol")

What do you think about passing hotkey description to awful.key() as an optional argument (and when describing all of them in default rc.lua)?

It will be useful for 3rd party widgets (i seen at least 4 different ones) which shows list of current hotkeys. And at the same time it still will be readable from config (sort of replacement to commenting each hotkey).

Later it can be agreed on design for such widget and it can be implemented as part of awesome's lua libraries.

I think to have such cheatsheet will be very useful.

Hi. I have rendering issues with some applications (e.g. gvim).

When I open long document in gvim and scroll using keys (j, k - down, bottom) everything works fine.
When I use vertical scrollbar with mouse, everything works fine too.
But when I use mouse wheel, only small parts re-render during scrolling, so the text is terribly broken.

$ cat /etc/issue
Fedora release 20 (Heisenbug)
Kernel \r on an \m (\l)

$ awesome -v
awesome v3.5.5 (Kansas City Shuffle)
 • Build: Apr 14 2014 18:44:32 for x86_64 by gcc version 4.8.2 (mockbuild@)
 • Compiled against Lua 5.2.2 (running with Lua 5.2)
 • D-Bus support: ✔

some time notifications will be thrown. it woul be nice to have a timer for this notifications, else it waste the screen and need to manually closing by mouse action.

this is annoying.

http://pix.toile-libre.org/upload/original/1426428215.png

Similar to the exit signal, it would be useful to have a startup signal, which would be emitted just before the main event loop starts, and all clients are being managed (when restarting).

Just like with exit it could also provide a boolean argument with a value indicating if awesome is restarting or not.

You can currently achieve this somehow using the refresh signal and then disconnecting yourself again. But it's not quite the same (gets called at the end of the loop?!), and requires you to disconnect when being called, which requires to use a function reference (AFAICS).

Saving windows' geometry in awful.layout.suit.floating so that it is restored when switching between layouts can be easily implemented in the config, but awful.client.floating uses its own way of saving and restoring window geometry. It would have been nice to get access to it. First, because it saves initial window geometry when program is launched in any other layout than awful.layout.suit.floating and second, because it seems logical to save window geometry between awful.layout.suit.floating and awful.client.floating.

Hi,

I'm running awesome 3.4.15 and am currently experiencing a problem where windows of github's atom editor are not shown. Atom is definitely running (verified via ps), and windows are created:

tinloaf@janeway ~ % xwininfo -tree -root | grep -i atom
     0x2a0002a "atom": ("atom" "Atom")  200x200+0+0  +0+0
     0x2c00001 "Atom": ("atom" "Atom")  800x600+560+240  +560+240
     0x2a0001e "atom": ("atom" "Atom")  200x200+0+0  +0+0
     0x2a00003 "atom": ("atom" "Atom")  200x200+0+0  +0+0
     0x2a00001 "atom": ("atom" "Atom")  10x10+10+10  +10+10

I'm not sure why atom creates 5 windows when started only once, but none of these is visible on any of my tags, not even in minimized state. Here's the detailed info on one of those:

tinloaf@janeway ~ % xwininfo -id 0x2c00001             

xwininfo: Window id: 0x2c00001 "Atom"

  Absolute upper-left X:  560
  Absolute upper-left Y:  240
  Relative upper-left X:  560
  Relative upper-left Y:  240
  Width: 800
  Height: 600
  Depth: 24
  Visual: 0x20
  Visual Class: TrueColor
  Border width: 0
  Class: InputOutput
  Colormap: 0x22 (installed)
  Bit Gravity State: ForgetGravity
  Window Gravity State: NorthWestGravity
  Backing Store State: NotUseful
  Save Under State: no
  Map State: IsUnMapped
  Override Redirect State: no
  Corners:  +560+240  -560+240  -560-240  +560-240
  -geometry 800x600+560+240

I tried finding out more using awesome-client, but for some reason, awful.client.iterate is not available for me, and I can't find another way of getting a handle to one of these windows.

Any idea what's wrong here?

Hello, I have something strange here.

 Xephyr :1  +xinerama -screen 1280x800+0+600  -screen 1280x800+1280+600 

With this and my real X server, then I click on the taglist of screen *, all inputs go to the other screen if it was selected first. So if I launch X and do ctrl+enter, it will launch the terminal on the other screen. My 3rd and 4th screens are unaffected. It happen with both the default config and mine. I use the latest gentoo packages for just about everything and never saw that before.

I also have strange errors with the default config (3.5.6 and master), but not always

W: awesome: luaA_dofunction:78: error while running function
stack traceback:
    [C]: in function 'ipairs'
    /usr/share/awesome/lib/awful/layout/init.lua:46: in function 'inc'
    /etc/xdg/awesome/rc.lua:171: in function 'press'
    /usr/share/awesome/lib/awful/button.lua:42: in function </usr/share/awesome/lib/awful/button.lua:42>
    [C]: in function 'emit_signal'
    /usr/share/awesome/lib/wibox/widget/base.lua:59: in function </usr/share/awesome/lib/wibox/widget/base.lua:27>
    (tail call): ?
    /usr/share/awesome/lib/gears/object.lua:68: in function 'emit_signal'
    /usr/share/awesome/lib/wibox/drawable.lua:279: in function </usr/share/awesome/lib/wibox/drawable.lua:273>
error: /usr/share/awesome/lib/awful/layout/init.lua:46: bad argument #1 to 'ipairs' (table expected, got number)

X -version
X.Org X Server 1.16.3
Release Date: 2014-12-20
X Protocol Version 11, Revision 0
Build Operating System: Linux 3.18.3 x86_64 Gentoo
Current Operating System: Linux localhost 3.18.3 #5 SMP Tue Feb 10 12:18:31 2015 x86_64
Kernel command line: BOOT_IMAGE=/boot/vmlinuz-3.18.3 root=/dev/sda2 rw
Build Date: 25 January 2015  06:48:17AM

Current version of pixman: 0.32.6
    Before reporting problems, check http://wiki.x.org
    to make sure that you have the latest version.

NVIDIA driver (but it happen on Xephyr too...)

I tried (and failed) to reproduce on other computers with other distros. I really have no idea (and did not look too deep beside a git bisect that show that all awesome 3.5+ versions are affected, I didn't tried older)

Sorry, i registered to report bug on https://awesome.naquadah.org/bugs/ but site doesn't allow me to open new report. So my problem is, awesome wm won't start because my system language is Turkish. But it works when i start it with "LC_ALL=en_US.UTF-8 startx". Here is the output when i tried to start it with my default system language (Turkish):

error while running function
stack traceback:
    [C]: in function 'assert'
    /usr/share/lua/5.2/lgi/override/cairo.lua:673: in main chunk
    [C]: in function 'require'
    /usr/share/lua/5.2/lgi/namespace.lua:176: in function </usr/share/lua/5.2/lgi/namespace.lua:148>
    (...tail calls...)
    /usr/share/awesome/lib/gears/color.lua:15: in main chunk
    [C]: in function 'require'
    /usr/share/awesome/lib/gears/init.lua:11: in main chunk
    [C]: in function 'require'
    /home/doublet/.config/awesome/rc.lua:9: in main chunk
error: /usr/share/lua/5.2/lgi/override/cairo.lua:673: assertion failed!
error while running function
stack traceback:
    /usr/share/awesome/lib/gears/color.lua:62: in function 'create_solid_pattern'
    /usr/share/awesome/lib/gears/color.lua:211: in function </usr/share/awesome/lib/gears/color.lua:187>
    (...tail calls...)
    /usr/share/awesome/lib/wibox/drawable.lua:133: in function 'set_bg'
    /usr/share/awesome/lib/wibox/drawable.lua:265: in function </usr/share/awesome/lib/wibox/drawable.lua:230>
    (...tail calls...)
    /usr/share/awesome/lib/wibox/init.lua:100: in function </usr/share/awesome/lib/wibox/init.lua:96>
    (...tail calls...)
    /usr/share/awesome/lib/naughty.lua:440: in function 'notify'
    /etc/xdg/awesome/rc.lua:18: in main chunk
error: /usr/share/awesome/lib/gears/color.lua:62: attempt to call field 'create_rgba' (a nil value)
E: awesome: main:535: couldn't find any rc file

If I have only one unminimized window (or only one window) on a tag, and try to minimize that window, it will minimize momentarily, then it will pop back up automatically. The background will very briefly flash, then the window will be raised.

This is new behavior since upgrading to 3.5.6.

Signals for the modifier keys (Alt_L, Ctrl_L, Super_L, etc.) are emitted only on key press events, not on key release events.

I added

awful.key({ modkey }, "Alt_R", nil)

to globalkeys, then added the lines

for i,v in pairs(globalkeys) do
    if v.key == "Alt_R" then
        v:connect_signal("press", function(...)
            print("press signal received")
        end)
        v:connect_signal("release", function(...)
            print("release signal received")
        end)
    end
end

Running awesome inside Xephyr, I see the press signals but not the releases.

Other keys such as alphanumerics work as expected.

It would be greatly appreciated if align layouts would accept widget and expand mode arguments:

local layout = wibox.layout.align.horizontal()
layout:set_expand("none")
layout:set_middle(widget)

would become

local layout = wibox.layout.align.horizontal(widget, "none")

Here's a rudimentary change I propose as RFC

diff --git a/lib/wibox/layout/align.lua.in b/usr/share/awesome/lib/wibox/layout/align.lua
index ab1e557..7e19b9d 100644
--- a/align.lua.in
+++ b/align.lua.in
@@ -216,7 +216,7 @@ function align:reset()
     self:emit_signal("widget::updated")
 end

-local function get_layout(dir)
+local function get_layout(dir, widget, expand)
     local ret = widget_base.make_widget()
     ret.dir = dir
     ret._emit_updated = function()
@@ -229,7 +229,8 @@ local function get_layout(dir)
         end
     end

-    ret:set_expand("inside")
+    if widget then ret:set_second(widget) end
+    ret:set_expand(expand or "inside")

     return ret
 end
@@ -238,8 +239,8 @@ end
 -- three widgets. The widget set via :set_left() is left-aligned. :set_right()
 -- sets a widget which will be right-aligned. The remaining space between those
 -- two will be given to the widget set via :set_middle().
-function align.horizontal()
-    local ret = get_layout("x")
+function align.horizontal(...)
+    local ret = get_layout("x", ...)

     ret.set_left = ret.set_first
     ret.set_middle = ret.set_second
@@ -252,8 +253,8 @@ end
 -- three widgets. The widget set via :set_top() is top-aligned. :set_bottom()
 -- sets a widget which will be bottom-aligned. The remaining space between those
 -- two will be given to the widget set via :set_middle().
-function align.vertical()
-    local ret = get_layout("y")
+function align.vertical(...)
+    local ret = get_layout("y", ...)

     ret.set_top = ret.set_first
     ret.set_middle = ret.set_second

Problem:
I use awesomewm v3.5.6 and have the following problem in a multi-monitor setup:
When I use chromium browser I cannot rearrange tabs using the mouse. When I try to drag a tab I instantly get a new window with that tab. After that it is not possible to move this tab back into the main window.
Another issue: in the bookmark manager (of chromium) it is not possible to reagange the bookmarks using drak and drop either.

Why I think this is an awesomewm issue:
Today I found, that these issues only occur on screen two and three.
On screen one everything works fine.
More precisely: it only works on the primary monitor (see below)

What I did to setup monitors:
xrandr --output eDP1 --auto --primary --output DP4 --auto --right-of eDP1 --output HDMI1 --auto --right-of DP4

the screen where I can move tabs moves with the --primary flag

I'd like awful.client.swap.bydirection prefer clients that are at the top of the stack.

It uses client.get internally to loop over them, and I could imagine having a new C function, or option, which would return the clients as they are on the stack globalconf.stack.

Would it make sense to change the default of client.get even, or are not all clients necessarily in globalconf.stack?
But then any missing clients could be appended.