Austin Matherne | 25 Nov 02:47 2014

Working Cursor Themes

I stumbled across the section of the FAQ ( that states that "The reason your cursor fall-backs to default, over a wibox or the background, is because XCB does not support Xcursor yet." Searching the mailing list brings up conversations about it not working, as well. I found this strange since I've been happily using custom mouse cursors with awesome for years now without issue. The trick I've found to preventing the mouse cursor from being reset is to create a default theme that inherits from the actual theme I want to use, then when the cursor "resets" it does so to cursor that I'm already using.

Perhaps it's only working because of something unique to my system, but I'm attaching the index.theme that I use. Copy it to ~/.icons/default/index.theme and install the gruppled_black cursor theme ( or whatever other cursor theme you'd like (just swap out the inheritance in the default theme) into ~/.icons, as well.

Hopefully this works for others and the FAQ can be updated.

Austin M. Matherne
Attachment (index.theme): application/x-theme, 109 bytes
Abhijeet Rastogi | 21 Nov 08:59 2014

Force mouse to follow opened window but only when in same screen

Hi everyone,,

Right now, I've this small snipped in my rc.lua that makes the mouse
focus to the center of newly opened window.

client.connect_signal("focus", function(c)
    if mouse.object_under_pointer() ~= c then
        local geometry = c:geometry()
        local x = geometry.x + geometry.width/2
        local y = geometry.y + geometry.height/2
        mouse.coords({x = x, y = y}, true)

The problem with this is that, it also focuses to a window if it's in
a separate "screen". I only want it to happen for current screen. How
do I make this possible?

I tried to add "c:isvisible()" as one more condition but for some
reason it isn't working. I'm dealing with "IceadTea" java windows so
support for it is already messy. Could that be the reason?


Abhijeet Rastogi (shadyabhi)

Paul Jolly | 18 Nov 17:55 2014

Changing dpi settings

I have my screen hooked to an Apple Thunderbolt display for most of the time but then need to quickly switch resolution when I drop onto using the MacBookPro screen only

My switch in ~/.Xresources is essentially:

Xft.dpi:196 -> ! Xft.dpi:196 
URxvt*font: xft:DejaVuSansMono:medium:size=7:antialias=false -> URxvt*font: xft:DejaVuSansMono:medium:size=8:antialias=false

This is accompanied by a couple of changes to my Awesome config.

An Awesome restart (unsurprisingly) doesn't pick up the .Xresources changes.  

Any thoughts on how best to achieve this?


Wisatbff Li | 16 Nov 05:32 2014

disable mouse click switch

Hi. I'm looking for how to prevent the mouse click from switching
windows. It's annoying especially when I'm using the magnifier layout.
I often click on an inactive window by mistake when I actually want to
scroll the current active one. I'm new to awesome and I've been
searching for a while but find nothing helpful. Any help is

Ian Denhardt | 8 Nov 01:03 2014

Weird placement of krita window?

Hey all,

I've recently set up awesome, and it seems to be mostly working as
expected, with one problem: krita only takes up about 3/4 of the screen,
regardless of the active layout -- The window sits in the upper left,
and doesn't expand to fill the rest of the screen in tiling modes,
Can't be moved in floating mode...

I'm not really sure what to make of this, has anyone hit this before?


Stefan Geneshky | 7 Nov 16:48 2014

New Firefox behaves weirdly

After the last update, my Firefox stopped abiding to Awesome's rules. It does not tile, does not float properly, does not resize or anything.
Has anyone else seen this happen?

Stefan G.
David Henderson | 7 Nov 14:58 2014


Good morning everyone!  I am working on a project and wanted to
incorporate the awesome window manager into it.  Currently the base OS
for the project is the latest version of TinyCore Linux
(  Due to time constraints, I wanted to
reach out to the community of this WM to see if anyone would be
interested in helping to get this incorporated.  I am willing to pay
for your help.  If this is not the place to post a request like this,
I apologize.


Rob Hoelz | 5 Nov 04:39 2014

Placement of web notifications on the screen

Hi fellow Awesome users,

I've encountered some annoying behavior with web notifications on
Chrome and Firefox, and I was wondering if others had seen this
behavior before me and if they were able to remedy it.

My problem is this: when I see a web notification
displayed, it always appears on screen 0 of my two monitor set up, even
if the browser displaying the notification is on screen 1.  As I tend
to put "back burner" stuff on screen 0 and primarily work off of screen
1, this causes me to sometimes miss web notifications, which is pretty

Ideally, I would like them to show up in the upper right corner of
screen 1, where I have naughty displaying its notifications.  However,
after digging around, I've found that the X11 windows used to implement
these notifications do not generate client manage events; in fact, they
don't generate any events that are exposed to the Lua API, as far as I
can tell.  It seems that they generate a map notify (rather than a map
request, and not to be confused with a mapping notify) event, which
awesome doesn't seem to handle.

Has anyone seen this behavior and come with a good solution for their
rc.lua?  If not, developers of awesome: would you be open to a patch
exposing map notify events via the Lua API so that users may handle
this scenario?


Joren Heit | 3 Nov 22:21 2014

memory leak in cairo context paint() method?

Hi all,

I received a bug-report on github the other day of someone who's been having problems with my alt-tab implementation. The preview-window that pops up is refreshed at some rate (e.g. 30fps) calling cr:paint() each time for every widget to draw the window-contents in a preview-box. However, he noticed that awesome's memory usage is increasing while this happens, filling his 2 gigs of ram within 20 seconds. He was able to narrow it down to the paint() call, and the effect disappeared when he removed it from the module.

I was unable to reproduce this, so it must be somehow related to our platform and/or versions of lua/cairo. My specs are the following:
Debian Jessie, kernel 3.16
awesome v3.5.5 (Kansas City Shuffle)
 • Build: Jun 11 2014 02:21:37 for x86_64 by gcc version 4.9.0 (root <at> miyumi)
 • Compiled against Lua 5.1.5 (running with Lua 5.1)
 • D-Bus support: ✔

His specs:
awesome v3.5.5 (Kansas City Shuffle)
• Build: Apr 11 2014 09:37:47 for i686 by gcc version 4.8.2 (nobody <at> )
• Compiled against Lua 5.2.3 (running with Lua 5.2)
• D-Bus support: ✔
Cairo 1.14.0

So there are some differences. What could this be related to? Could it be a bug in the (32 bit) cairo 1.14 library?

Alfredo Palhares | 24 Oct 09:19 2014

Cannot Fill cairo rectangle

Hello fellow awesome users.

I am trying to upgrade my widget to support 2 batteries, i've got it to
work but the cr:fill()[1] is not working. Can anyone point me out ?

Excuse me the bad code, its a WIP


Alfredo Palhares


To unsubscribe, send mail to awesome-unsubscribe <at>

Elv1313 . | 20 Oct 17:27 2014

Announcing Retrograde 1.0: A module to configure your widgets like Awesome 3.4.*

Hello everyone Awesome,

I wrote this little module yesterday and I think some users will like it:

It allow you to setup layout using a declarative syntax again,
something I missed since the 3.4.* days. It is rare I consider a
module as complete and ready for the general public after 1 commit,
but this is quite small and straightforward. So enjoy!