No Title: Working around the missing –title parameter in Gnome Terminal

About a year ago the Gnome developers took away the option to run Gnome terminal with the –title parameter. This allowed you to give the terminal window a custom name like ‘SSH@MYBOX’ or ‘myProject’ instead of just ‘Terminal’. Why did they do that? I don’t know. It seems to just be what Gnome developers do these days.

If you prefer separate terminal windows for separate tasks, naming those windows is a nice way to tell them apart. This applies to general orientation (i.e. looking at the windows in the Activities overview and deciding which one to click on) and for scripting purposes (i.e. writing a script targets windows by title).

For me personally this latter option is the more important. I have a local terminal and a remote terminal and I would like be able to access either quickly and easily with a simple keyboard shortcut rather than mucking about with tabs. Here I will detail a way to accomplish that without the missing –title parameter.


Why GNOME keybindings silently resist customization

Note: This relates GNOME Shell 3.10 in Ubuntu 14.04. Other versions may differ and YMMV.

The keybindings of GNOME Shell can be changed using the system settings windows (All settings | Keyboard | Shortcuts). However, I have at times run into the feeling that these settings were only superficially customizable. Some keybindings would keep working the old way despite having their functionality set to another keybinding and some would seemingly ignore being disabled. GNOME keybindings seemed haunted by a ghost.

I’ve tracked down the ghost and the name of it is multiple keybindings. One functionality is often given to multiple key combos in the bowels of the system, not just one. The System settings window, however, only shows one, the first in the list. This means that if the keybinding you wish to assign to functionality A is secretly assigned to functionality B , the secret binding may overrule your attempts to use the keybinding. Only you won’t be asked to reassign the keybinding in system settings as that only checks the first, user-editable keybinding. A bug or a feature? You never really know with the GNOME development team.


Everything in it’s Right Place 4: Launch and switch

This is the fourth post in a series on achieving an orderly desktop environment in GNOME 3, using no add-ons, only old school hacks. See also the first, second and third post in the series.

Following the first two set of instructions we’ve got static workspaces and windows spawn where they should. That in itself is not terribly convenient as I now have to run up and down in the GNOME workspace stack to find the window I’m looking for – even if I just launched it – or rely on the old alt-tab trot that we know and hate from Windows. To torture this metaphor, we’re going to skip the stairs and install an express elevator thus also justifying the arbitrary choice of the post’s header image.

This is where the final piece of the puzzle comes in: A better way to start applications and switch between them. These two kinds of actions tend to be treated separately. You start up an application by clicking an icon or typing a command and then you find it again later on by different means. Both actions stem from the ‘I need application X now’ impulse. So you should channel that impulse the same way. There is an established way to integrate them, though. Windows 7+, GNOME Shell, and Mac OS X (I believe?) all tie an icon to a permanent process bar and have this work as both process launch and recall. I don’t think this is a good solution for a number of reasons: a) it’s not convenient (read: keyboard-centric) and b) I dislike bars (the taking-up-screen-space kind, not the other one one). The simple solution: Associate one application with one keyboard shortcut and leave it to the computer to figure out whether this means starting the application or retrieving a running instance. Either way it will obviously have to be on it’s proper workspace, see post the second, so we want to come to (move the focus to) the workspace of the window, rather than janking it out of it’s place and having it come to us.

To this end we introduce two tools that will help us achieve this: wmctrl for manipulating windows and xbindkeys for the keyboard shortcut bit. Also bits of Bash for glue. All of these are omnipresent on linux distibutions and should be installable as packages named just as written above. One word of warning, though. This entire series is composed of hacks but the previous ones are so established and solid that it hardly counts. This is where it gets a bit hairy.


Gnome Shell: Three years on

The big battle of GNOME Shell has beeen pretty much fought out by now. I think the general consensus is that GNOME Shell lost but that there’s no clear winner, since Canonical’s Unity hasn’t won anybody over but themselves (even if that does represent a sizeable chunk of linux desktop users).

So when this piece showed up in my feed reader, I could empathize. I also liked the idea of Gnome Shell, I also liked the look of Gnome Shell. But since the reality of Gnome Shell was above all buggy, uncustomizable and marked by the developers’ we-know-best attitude, I also left in search of pastures new. And also came up short.