Why Run A Tiling Window Manager?

 Computing  No Responses »
Jun 302024
 

The funny thing is that this post is not about window tiling but about conventional tiling window managers that to a great extent are “do it yourself” window managers. That is they kind of expect you to do a lot of configuration yourself.

This is not about specific tiling window managers even though I use Awesome and Hyprland.

Tiling vs Floating

In the earliest days of gooeys, windows tended to be tiled so that they didn’t overlap; if you added a new window to the screen, the existing windows would shrink to make room for the new window.

So-called (at least in tiling window managers) “floating” windows were hailed as a brilliant new feature where windows were independent and could overlap. Cool right?

And this is certainly the way that most conventional gooeys work – from Windows, MacOS, and even Linux, they all support floating windows by default. On the other hand, tiling window managers support tiling by default (most will support floating windows as well).

So why would you want to go back to the dawn of gooeys? And it is not just us weird geeks running minimalist window managers looking at tiling – many mainstream desktop environment have tiling features.

It maximises screen real-estate by automatically sizing windows so the whole desktop is covered. I can remember carefully dragging windows to resize them to maximise their size with conventional ‘floating’ window managers. Something that now happens automatically.

Customisation

So tiling can be done with conventional desktop environments – some of which allow support for tiling. KDE has Bismouth; GNOME has the Tiling Assistant, and even Windows has options. Now a tiling window manager does treat tiling as a first class feature, that’s not really why those who prefer them like them.

No, it’s the minimalism and customisation.

Most desktop environments carry with them lots of bonus features – which is fine for most. But if you don’t need those features and/or want to do things in a different way, then a full desktop environment isn’t what you want.

And tiling window managers tend to be minimalistic; even to the extent that some do not include a status bar requiring an optional status bar to be installed. The default configuration (if any) tends to be minimalistic requiring lots of tinkering to get the most out of it.

Which is a positive feature for tinkerers if a negative feature for those who just want to be up and running. But tinkering whilst it takes time, does tend to product a more productive environment – for example my Hyprland configuration includes a custom key binding to grab IP addresses and URLs from a highlighted section of the screen (and optionally “defangs” safely specified dangerous URLs which give you a hint about what I do).

Picture of a Raven
Who Are You Looking At?

An Awesome Window Manager ECC Widget

 Computing, Linux  No Responses »
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 :-

#!/bin/zsh
#
# 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}')

c="chartreuse"
if [[ "$correctables" != "0" ]]
then 
  c="orange"
fi
if [[ "$uncorrectables" != "0" ]]
then
  c="red"
fi

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 = io.open(filename, "r")
  io.input(file)
  s = io.read()
  io.close(file)
  return s
end

eccstatus = wibox.widget.textbox()
eccstatus:set_markup(readfiletostring(homedir .. "/lib/awesome/widget-texts/ecc-status"))
eccstatustimer = timer({ timeout = 60 })
eccstatustimer:connect_signal("timeout",
  function()
      eccstatus:set_markup(readfiletostring(homedir .. "/lib/awesome/widget-texts/ecc-status"))
  end
)
eccstatustimer:start()
...
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.

Awesome: A “Better” Way Of Setting Up Tags

 Computing, Linux, Working Notes  No Responses »
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
                           tag:view_only()
                        end
                  end,
                  {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
                         awful.tag.viewtoggle(tag)
                      end
                  end,
                  {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
                              client.focus:move_to_tag(tag)
                          end
                     end
                  end,
                  {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
                              client.focus:toggle_tag(tag)
                          end
                      end
                  end,
                  {description = "toggle focused client on tag", group = "tag"})
    )
end

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

Ubuntu, Compiling Awesome, and Messing With Lua

 Computing, Linux, Working Notes  No Responses »
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/version.so'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi/version.so'
	no file '/usr/lib/lua/5.3/lgi/version.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './lgi/version.so'
	no file '/usr/local/lib/lua/5.3/lgi.so'
	no file '/usr/lib/x86_64-linux-gnu/lua/5.3/lgi.so'
	no file '/usr/lib/lua/5.3/lgi.so'
	no file '/usr/local/lib/lua/5.3/loadall.so'
	no file './lgi.so'

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!

An Awesome Custom Help Screen

 Computing, Linux, Working Notes  No Responses »
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 dillo. Turns 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 :-

2015-03-07_1457

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

 Older Entries