No ads? Contribute with BitCoins: 16hQid2ddoCwHDWN9NdSnARAfdXc2Shnoa
Apr 012018

This is a continuation of an earlier post regarding ECC memory under Linux, and is how I added a little widget to display the current ECC memory status. Because I don’t really know lua, most of the work is carried out with a shell script that is run via cron on a frequent basis.

The shell script simply runs edac-util to obtain the number of correctable errors and uncorrectable errors, and formats the numbers in a way suitable for setting the text of a widget :-

# Use edac-util to report some numbers to display ...

correctables=$(edac-util --report=ce | awk '{print $NF}')
uncorrectables=$(edac-util --report=ue | awk '{print $NF}')

if [[ "$correctables" != "0" ]]
if [[ "$uncorrectables" != "0" ]]

echo "ECC: $correctables/$uncorrectables "

This is run with a crontab entry :-

*/7 * * * * /site/scripts/gen-ecc-wtext > /home/mike/lib/awesome/widget-texts/ecc-status

Once the file is being generated, the Awesome configuration can take effect :-

-- The following function does what it says and is used in a number of dumb widgets
-- to gather strings from shell scripts
function readfiletostring (filename)
  file =, "r")
  s =
  return s

eccstatus = wibox.widget.textbox()
eccstatus:set_markup(readfiletostring(homedir .. "/lib/awesome/widget-texts/ecc-status"))
eccstatustimer = timer({ timeout = 60 })
      eccstatus:set_markup(readfiletostring(homedir .. "/lib/awesome/widget-texts/ecc-status"))
layout = wibox.layout.fixed.horizontal, ... eccstatus, ...

There plenty of ways this could be improved – there’s nothing really that requires a separate shell script, but this works which is good enough for now.

Sep 202017

By default, the Awesome window manager sets up 9 tags and uses a rather clever method for setting keyboard shortcuts for those tags.

And that is also one of the irritations of using Awesome because I have gotten into the habit of using more virtual screens (“tags”) than this. After a dumb way of increasing the number, I have come up with a rather improved method that can be used to replace the existing method in the Awesome rc.lua file :-

local taglist = { "1", "2", "3", "4", "5", "6", "7", "8", "9", "0", "-", "=" }
-- The list of tags that I use.
 awful.tag( taglist, s, awful.layout.layouts[1])
for i = 1, #taglist do
  globalkeys = awful.util.table.join(globalkeys,
    awful.key({ modkey}, taglist[i],
                  function ()
                        local screen = awful.screen.focused()
                        local tag = screen.tags[i]
                        if tag then
                  {description = "view tag", group = "tag"}),
        awful.key({ modkey, "Control" }, taglist[i],
                  function ()
                      local screen = awful.screen.focused()
                      local tag = screen.tags[i]
                      if tag then
                  {description = "toggle tag", group = "tag"}),
        awful.key({ modkey, "Shift" }, taglist[i],
                  function ()
                      if client.focus then
                          local tag = client.focus.screen.tags[i]
                          if tag then
                  {description = "move focused client to tag", group = "tag"}),
        awful.key({ modkey, "Control", "Shift" }, taglist[i],
                  function ()
                      if client.focus then
                          local tag = client.focus.screen.tags[i]
                          if tag then
                  {description = "toggle focused client on tag", group = "tag"})

That’s three different parts of the code to change – a list of tags to use at the top of the file, a replacement somewhere in the middle, and a large chunk replacing existing code at the end of the keyboard configuration. I don’t claim this is better than the standard way, but it is handy for me.

The Window

May 202017

I just love messing around with run-time languages that I know relatively little about (and if your sarcasm detector isn’t flashing red about now, take it out and give it a good talking to).

The problem detailed here is something that you are unlikely to encounter unless you get into weird stuff like running an odd-ball window manager, aren’t content with the version of said window manager distributed with your Linux distribution, and are used to re-compiling things from scratch.

It all started when I upgraded Ubuntu on my work machine (to Zesty Zapus). The window manager version was upgraded from 3.5 to 4.0, which broke on my configuration file (3.5); not a big problem I thought, as I had already upgraded my window manager at home to 4.1 and reconfigured the configuration file. I copied the updated configuration file from home into place.

And it failed. Apparently I use 4.1-isms within the file. As I was not happy about tinkering with the file to downgrade it (in a language I know relatively little about), I decided to re-compile Awesome 4.1 instead.

Which failed with a weird error :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: [string "return require('lgi.version')"]:1: module 'lgi.version' not found:
	no field package.preload['lgi.version']
	no file '/usr/local/share/lua/5.3/lgi/version.lua'
	no file '/usr/local/share/lua/5.2/lgi/version.lua'
	no file '/usr/local/share/lua/5.3/lgi/version/init.lua'
	no file '/usr/local/share/lua/5.2/lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version.lua'
	no file '/usr/local/lib/lua/5.3/lgi/version/init.lua'
	no file '/usr/share/lua/5.3/lgi/version.lua'
	no file '/usr/share/lua/5.3/lgi/version/init.lua'
	no file './lgi/version.lua'
	no file './lgi/version/init.lua'
	no file '/usr/local/lib/lua/5.3/lgi/'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi/'
	no file '/usr/lib/lua/5.3/lgi/'
	no file '/usr/local/lib/lua/5.3/'
	no file './lgi/'
	no file '/usr/local/lib/lua/5.3/'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/'
	no file '/usr/lib/lua/5.3/'
	no file '/usr/local/lib/lua/5.3/'
	no file './'

Which had me stumped for a while, and it turns out that DuckDuckGo didn’t have an obvious fix (one of the reasons for writing this).

Eventually I figured out that awesome was not finding the LGI module (I can be slow at times) which was odd because it was definitely installed. However it turns out that it was installed in /usr/share/lua/5.2/lgi. So despite having lua 5.3 installed, extra lua modules can only be seen if you have lua 5.2 installed?

The “fix” for this was to create an environment variable telling LUA to search for files in rather more places before starting Awesome :-

export LUA_PATH="/usr/local/share/lua/5.3/?.lua;/usr/local/share/lua/5.2/?.lua;/usr/local/share/lua/5.3/?/init.lua;/usr/local/share/lua/5.2/?/init.lua;/usr/local/lib/lua/5.3/?.lua;/usr/local/lib/lua/5.3/?/init.lua;/usr/share/lua/5.3/?.lua;/usr/share/lua/5.2/?.lua;/usr/share/lua/5.3/?/init.lua;/usr/share/lua/5.2/?/init.lua;./?.lua;./?/init.lua"

This was created by running lua from the command line and running print(package.path) to display the default setting, and adding the 5.2 equivalent for many elements.

As to whether it works or not, well I cannot be sure (I’m not going into work on a weekend just to check if the window manager fires up), but Awesome itself seems happy with the result :-

» awesome --version
awesome v4.1 (Technologic)
 • Compiled against Lua 5.3.3 (running with Lua 5.3)
 • D-Bus support: ✔
 • execinfo support: ✔
 • xcb-randr version: 1.4
 • LGI version: 0.9.1

So it can find LGI, but whether it can do anything useful with it remains to be seen!

Mar 072015

So there I was, wandering down the street thinking about :-

  1. Sometimes being unable to remember custom key sequences that I've configured.
  2. That my "Help" button on my keyboard was unused.

And I thought that it would be fun to knock up a little application that would pop up a window and show a file. Then I got real, and realised that the application was already written and allowed fancy formatting of the help file(s) – it's called a browser.

Now for a whole bunch of reasons, you probably don't want to use a full blown browser, but something a little simpler and without any fancy controls, and I plumped for dilloTurns out that the "-f" flag turns off the fancy menu and toolbar, so what I needed was to persuade my window manager (Awesome) to run it when I pressed "Help" :-

	awful.key({ }, "Help", function () awful.util.spawn("dillo -f /home/mike/lib/help-files/index.html") end))

If you need help adding that to your Awesome configuration file, you're in the wrong place!

And of course it works :-


(And now of course I need to spend some time writing some help files!)

Mar 242013

The default title bar provided by Awesome is not quite to my taste. And this posting is about fixing that.

The first part is to select some colours. For me, I prefer window decorations to be subtle … grey scale; the window decorations should disappear until you focus on them. And I’m choosing to have a lighter grey for focused windows, and darker for others. The colours are set in the default-theme.lua file :-

theme.titlebar_fg_normal = "#000000"
theme.titlebar_fg_focus = "#000000"

theme.titlebar_bg_normal = "#cccccc"
theme.titlebar_bg_focus = "#e8e8e8"

The next step is to restrict the number of buttons that appear in the title bar – this is of course a matter of choice, but personally I believe that there are too many buttons by default. This is done within the main configuration file and by deleting the buttons you wish removed, which in my case means removing the lines :-


Lastly, and in keeping with making the titlebar less obtrusive, there’s shrinking the titlebar to a sensible size :-

awful.titlebar(c, { size=16 })

Which is added after the line: awful.titlebar(c):set_widget(layout) (it could be merged). There are two features I’d like to use with no method easy enough for a thicko like me to spot :-

  1. There seems no obvious way to put the title bar on the left (or right) side of the window; it seems an obvious thing to try given that screens are usually far wider than tall. There are hints that there is an attribute (if that’s the right word) called “position”, but I don’t see a way of setting it.
  2. I have removed a certain number of options for controlling the window, partially because I can never remember what those silly icons mean. But I would quite happily add a menu with all of the relevant methods – and this would be a good place to add the keyboard shortcuts (us old foggies need some helpful hints like that).


Dec 312012

This has been updated for Awesome 3.5

I have long been interested in tiling window managers, which would seem to offer the flexibility I crave. But switching is painful when you want your machine to be as functional as much as possible. On at least two occasions I have switched … and very quickly switched back when problems were encountered.

So just for the fun of it, I have decided to give it another go … in a way that can be gradually worked into functionality.

But first, what exactly is a tiling window manager? Well a conventional window manager works with overlapping windows where windows can stack on top of each other and overlap. A tiling window manager on the other hand uses tiling to maximise the size of every displayed window.

Or in other words, if you want to make the maximum use of space on your screen, a stacking window manager usually asks you to manually move and resize windows yourself whereas a tiling window manager does it all automatically. Although with a tiling window manager, you will need to rotate amongst different tiling layouts to suit.

Tiling window managers tend to be keyboard driven rather than mouse driven, but this is merely an aspect of their implementation.

A Testing Environment

The key to setting up any window manager gradually over time without losing an existing working environment, is to create a separate display which a new window manager can control. This can be quite easily accomplished with a nesting X server, which is provided by the xserver-xephyr package.

As to the choice of window manager, the title of this post gives away the secret – Awesome. Of course the same method works for other window managers too.

The first step is to install the required packages :-

sudo apt-get install xserver-xephyr awesome awesome-extra

The next step is to create a simple shell script to start the nested X server. This basically starts the nested X server with a sensible screen size, and sets the $DISPLAY environment variable so that any further X programs are directed to communicate with the nested X server. The nested X server simply starts up as a standard window within which Awesome operates. The script looks like :-


Xephyr -ac -reset -screen 1280x1000 :1 &
export DISPLAY=:1.0
sleep 5
awesome --config ~/src/site/etc/awesome/config.lua

The sleep command in there is to wait until X has settled down before trying to manage it … without this, it is possible that awesome will fail to open the display (on a slower laptop it worked without; on a faster desktop it did not). The parameter to awesome is to set the preferred location for the configuration file (which I will describe next), although you can leave it out to use the default.

Don’t start it yet! Before doing that, copy the default configuration file to the specified location so you have something to work with :-

cp /etc/xdg/awesome/rc.lua ~/src/site/etc/awesome/config.lua

It’s All In The Repository

The custom configuration file I specified just happens to point to a directory and file within the working copy of a Subversion repository. Using a repository for configuration files has all sorts of benefits; not least of which is to reverse “poor” choices made along the way. Whilst describing how to get one set up is beyond the purpose of this post, it is well worth doing.

Of course if you are working with a repository, it is important to remember to commit changes at every stage :-

% svn add ~/src/site/etc/awesome 
A         /home/mike/src/site/etc/awesome
A         /home/mike/src/site/etc/awesome/config.lua
% svn commit ~/src/site/etc/awesome -m "Awesome: Initial Configuration from default"
Adding         src/site/etc/awesome
Adding         src/site/etc/awesome/config.lua
Transmitting file data .
Committed revision 166.

I won’t be documenting every single commit, but they are all in there!

It is also helpful (at this stage) to create a symlink between the default configuration directory (~/.config/awesome) and the working copy of your repository. The configuration directory can probably be changed, but one thing at a time!

Status Bar Size

One of the annoyances I remember from the last time I played with Awesome, was the tiny size of the status bar. It is all very well maximising the size of the main screen area, but some of us have high resolution screens and tired old eyes! Within the config.lua file (or whatever you named your file), look for :-

mywibox[s] = awful.wibox({ position = "top", screen = s})

And change it to add a height parameter :-

mywibox[s] = awful.wibox({ position = "top", screen = s, height=32 })

The exact choice of size is of course down to personal preferences! However changing the size also means changing the font would be wise :-

awesome.font = "LMSans10 10"

Making the font too much larger will result in some display oddities … at least for now.

Adding A Title Bar

In theory, there is no need for a title bar with a tiling window manager, but I guess I am a little too conventional as a window without a title bar still looks a little weird to me. Plus my shell prompts stick useful bits of information into the window title bar and I would really rather hang on to that extra information. Still, drawing title bars on windows turns out to be really simple … just find the existing code to do so and :-

local titlebars_enabled = true

Some appearance tweaks and indeed messing around with the unnecessarily large number of buttons could be usefully accomplished, but for now this is fine.



Of course messing around with the appearance of a window manager is probably best dealt with using themes (if they are supported). The default configuration file I worked with included enabling beautiful via :-


It is easier to tinker with themes with a configuration file you can edit, so I copied this theme.lua to the configuration directory named as default-theme.lua, and changed the configuration :-

-- beautiful.init("/usr/share/awesome/themes/default/theme.lua")
beautiful.init(awful.util.getdir("config") .. "/default-theme.lua")

I also removed the previous section’s font setting and set the same font within the new configuration file :-

theme.font = "LMSans10 10"

To cope with the larger font, I also increased the width of each menu item :-

theme.menu_width  = "300"

Although this width does depend on having an appropriately sized screen, and not having too many levels to your menu (if it gets too wide, the extra levels don’t appear neatly).

And finally I commented out the command used to set the background … having a background image for a tiling window manager (which is designed to utilise the whole screen) is a touch unnecessary. And I don’t particularly like the default image :-

--theme.wallpaper_cmd = ...

For now I will leave the colours alone … the defaults may not be perfect but are not sufficiently irritating to spend time on right now. But the details of how to change colours of various components can be found in the theme file we have created.

Disabling Layouts

Personally I believe that you can have too much of a good thing, and choosing between the rather large number of different possible layouts that Awesome makes available is one of those. To reduce the number of possibilities, simply comment out some of the possibilities when setting the “layouts” variable in the configuration file :-

layouts =

Which you command out does not matter so much, and indeed you may very well change you mind at a later point.

A Menu

Whilst the menu built into Awesome has undoubtedly many advantages, I already have a somewhat adequate menu built up over years that relies on myGtkMenu. Whilst changing this menu could well be sensible, it does also seem sensible to keep it around during the transitional period. To do so is simply a matter of replacing certain bindings :-

 -- {{{ Mouse bindings
-    awful.button({ }, 3, function () mymainmenu:toggle() end),
+    --awful.button({ }, 3, function () mymainmenu:toggle() end),
+    awful.button({ }, 3, function () awful.util.spawn("/opt/bin/myGtkMenu /home/mike/lib/") end),
     awful.button({ }, 4, awful.tag.viewnext),
     awful.button({ }, 5, awful.tag.viewprev)

If you hadn’t guessed, I’ve started using diffs to show the changes where it makes sense; if you cannot read diffs, this page is probably not for you.

That bit replaces the root window, but not the status bar menu :-

 mylauncher = awful.widget.launcher({ image = image(beautiful.awesome_icon),
-                                     menu = mymainmenu })
+--                                     menu = mymainmenu })
+                                       command = "/opt/bin/myGtkMenu /home/mike/lib/" })

My own menu has some issues in that it doesn’t yet have anything to control awesome itself. But is good enough to get started with.

Final Word … Or Not!

And that is it! Or at least it is enough to be getting on with.

WP Facebook Auto Publish Powered By :

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.