Easy Display Layout Switching in Ubuntu

I use Ubuntu on my laptop and am generally very happy with it. The only limitation is that the X server does not expand the desktop to new monitors and projectors as they are plugged in. However, I've been able to configure GDM to provide a simple workaround by adding options to the menu on the GDM login screen to switch between display layouts before logging in. I've not found the approach I've used documented anywhere on the web, so here's how I did it.

First I defined server layouts in the X server configuration file (/etc/X11/xorg.conf) for each display configuration I need: the built-in laptop screen by default, the laptop display and a 16:9 display for when I'm at home, the laptop display and a 4:3 display for when I'm at work, and so on. Here are the server layout sections from my X configuration:

...

Section "ServerLayout"
        Identifier      "Default"
        Screen          0 "Default Screen"
        InputDevice     "Generic Keyboard"
        InputDevice     "Configured Mouse"
        InputDevice     "stylus" "SendCoreEvents"
        InputDevice     "Synaptics Touchpad"
EndSection

Section "ServerLayout"
        Identifier      "Home"
        Screen          0 "Default Screen"
        Screen          1 "External 16:9 Screen" Above "Default Screen"
        InputDevice     "Generic Keyboard"
        InputDevice     "Configured Mouse"
        InputDevice     "stylus" "SendCoreEvents"
        InputDevice     "Synaptics Touchpad"
EndSection

Section "ServerLayout"
        Identifier      "Work"
        Screen          0 "Default Screen"
        Screen          1 "External 4:3 Screen" RightOf "Default Screen"
        InputDevice     "Generic Keyboard"
        InputDevice     "Configured Mouse"
        InputDevice     "stylus" "SendCoreEvents"
        InputDevice     "Synaptics Touchpad"
EndSection

...

Then I configured gdm to launch the X server with the layout read from a configuration file named xserver-layout stored in the /etc/gdm directory by adding the following section to the /etc/gdm/gdm.conf-custom config file:

[server-Standard]
name=Standard server
command=/etc/gdm/xserver
flexible=true

The command /etc/gdm/xserver is the following script. It needs to be executable by root.

#!/bin/sh

LAYOUT=`cat /etc/gdm/xserver-layout`
if [ -z "$LAYOUT" ]; then
        LAYOUT=Default
fi

exec /usr/X11R6/bin/X -br -audit 0 -layout "$LAYOUT" $*

I then wrote another script, /etc/gdm/set-xserver-layout, to change the contents of the /etc/gdm/xserver-layout file and restart GDM. Again, this has to be executable by root.

#!/bin/sh

echo -n "${1:?no layout name given}" > /etc/gdm/xserver-layout
/etc/init.d/gdm restart

I then added menu items to the GDM menu to run the xserver-layout command with different parameters to switch GDM between different display layouts. You can do this from the System > Administration > Login Window control panel or add a section like the following to the /etc/gdm.conf-custom file:

[customcommand]
CustomCommandLabel0=Mobile Display Configuration
CustomCommandLRLabel0=Switch to Mobile Display Configuration
CustomCommandIsPersistent0=true
CustomCommandTooltip0=Switch to Mobile Display Configuration
CustomCommand0=/etc/gdm/set-xserver-layout Default

CustomCommandLabel1=Work Display Configuration
CustomCommandLRLabel1=Switch to Work Display Configuration
CustomCommandIsPersistent1=true
CustomCommandTooltip1=Switch to Work Display Configuration
CustomCommand1=/etc/gdm/set-xserver-layout Work

I can now easily select the display configuration I need before I first log in. Having also configured the Network Manager to not ask for my keychain password every time it wants to log into a WiFi network, being mobile with Ubuntu is a much smoother experience.

If you know of a better way, ideally a tool that lets me configure the X server on the fly, please drop me a line in the comments.

Update #1: thanks to Brendan, I've updated the xserver script above to pass the arguments from gdm through to the X server process.

Update #2: fixed a typo in the xserver script.

Multiple Build Monitors on a 3D Rotating Cube

In my current project we have two builds. The fast build compiles all the code and runs unit tests only, to quickly check that we haven't forgotten to commit all the files associated with a change. The slow build compiles and packages the entire system, runs unit tests of classes that interact with databases and message brokers, and then deploys the system into a production-like environment and runs end-to-end tests through it.

We visualise the state of both builds with two Piazza build monitors. Unfortunately, we only have one physical build monitor.

Rather than make Piazza automatically switch between build monitors, we came up with a cunning hack to do the same, and which looks much more flashy at the same time. We run the two build monitors in full-screen mode on different virtual desktops of our (Ubuntu) build server and then run a script that switches between the two desktops every few seconds. The script uses the xsendkeys command to send the appropriate key combination for "next desktop" or "previous desktop" to the window manager. It's all very "scrapheap challenge".

When the compositing window manager is running (aka Desktop Effects in Ubuntu), the build monitors appear to be on the faces of a rotating cube, which looks very impressive.

Update: it's inconvenient that cycling between build monitors like this interferes with the desktop interface. If you can live without the spinning cube effect you can use the FullerScreen and Tab Slideshow Firefox extensions to cycle between full-screen views within Firefox without disrupting the desktop.

Using the MoGo Mouse with Linux

The MoGo Mouse is an elegant, portable Bluetooth mouse that fits into a laptop's PC slot and charges its batteries while in there. I find it very useful when travelling with my laptop but the process of getting it connected to the Ubuntu desktop is not as smooth as it could be. Here's how.

% hcitool scan
Scanning ...
        AA:BB:CC:DD:EE:FF       MoGo Mouse BT

Then tell the Linux HID daemon to connect to that Bluetooth device and use it as a mouse:

% sudo hidd --connect=AA:BB:CC:DD:EE:FF

If your GNOME Bluetooth setup is configured correctly you'll be asked to enter the mouse's PIN and then you'll be connected.

For convenience I've set up a GNOME application launcher to run the following command so that I don't have to connect the mouse from the terminal every time I want to use it:

gksu --message="Enter your password to authorise the connection to the MoGo mouse" \
    "hidd --connect=AA:BB:CC:DD:EE:FF"

I've also created this icon for the launcher that you can download if you want to do the same.

Concrete to Abstract Syntax Transformations with SableCC

I'm known to grumble about Java technologies, especially those used for enterprise development but I have to grudgingly admit that there are some pretty cool Java things out there that don't suffer from "enterprise quality". One example is SableCC, my top choice of parser generator. I often use SableCC to define the syntax of configuration files and other data formats that must be read and/or edited by people. It makes for formats that are more human-friendly than XML but are still easy to parse and process.

Why SableCC?

SableCC has an elegant design that cleanly separates the grammar definition from the programming language used to implement the parser, meaning you don't have to embed Java code into the grammar. Instead, SableCC creates classes to represent the syntax tree and abstract visitor classes that you extend to perform transformations, semantic analysis and other processing by walking the tree.

The main drawback of the current release of SableCC, 2.18.3, is that the generated classes represent the concrete syntax tree, not the abstract syntax tree that you really want to work with. Defining the abstract syntax tree and writing transformations from to concrete to abstract tree is quite an effort, and then you have to write your own visitor classes to process that tree.

The latest beta version of SableCC has a feature that addresses this problem: you can define an abstract syntax in the grammar and specify how the concrete syntax relates to the abstract syntax. The generated parser translates from the concrete syntax to the abstract syntax as it parses and returns you the abstract syntax tree. The generated visitor classes all work on the abstract syntax tree so your software is shielded from the complexities of the concrete syntax.

Currently this feature has virtually no documentation, so here's a short tutorial. I assume you already have some experience of using SableCC. If not, give it a try; I think it's really good.

Concrete vs. Abstract Syntax

What's so great about concrete to abstract syntax transformations? Let's use the following grammar of simple arithmetic expressions as an example.

Tokens

add = '+';
sub = '-';
mul = '*';
div = '/';
left_paren = '(';
right_paren = ')';
number = [0-9]+;
whitespace = (' ')+;


Ignored Tokens

whitespace;


Productions

expr = {add} [left]:expr add [right]:factor
     | {sub} [left]:expr sub [right]:factor
     | {factor} factor;

factor= {mul} [left]:factor mul [right]:value
        | {div} [left]:factor div [right]:value
        | {value} value;

value = {number} number
      | {parens} left_paren expr right_paren;

Using this grammar to parse the expression "(1 + 2) * 3" produces the following concrete syntax tree.

AFactorExpr
|
+- factor : AMulFactor
   |
   +- left : AValueFactor
   |  |
   |  +- value : AParenValue
   |     |
   |     +- "("
   |     |
   |     +- expr : AAddExpr
   |     |  |
   |     |  +- left : AFactorExpr
   |     |  |  |
   |     |  |  +- factor : AValueFactor
   |     |  |     |
   |     |  |     +- value : ANumberValue "1"
   |     |  |
   |     |  +- "+"
   |     |  |
   |     |  +- right : AValueFactor
   |     |     |
   |     |     +- value : ANumberValue "2"
   |     |
   |     +- ")"
   |
   +- "*"
   |
   +- right : AValueFactor
      |
      +- value : ANumberValue "3"

As you can see, the concrete syntax tree is pretty complex. This complication affects code that analyses this tree and couples that code to the operator precedence rules defined by the grammar. One result of this coupling is that the analysis code will frequently break when we change the language.

Ideally, our code would process the tree below, which represents the expressions themselves rather than the particular notation we use to represent expressions.

AMulExpr
 |
 +- left : AAddExpr
 |   |
 |   +- left : ANumberExpr "1"
 |   |
 |   +- right : ANumberExpr "2"
 |
 +- right : ANumberExpr "3"

This is the abstract syntax tree of the concrete syntax tree shown above. The abstract syntax of our expression language can be also be represented as a grammar:

expr = {add} [left]:expr [right]:expr
     | {sub} [left]:expr [right]:expr
     | {mul} [left]:expr [right]:expr
     | {div} [left]:expr [right]:expr
     | {number} number;

If only we could tell the parser how to translate the concrete syntax to this abstract tree...

With SableCC 3 we can! A SableCC 3 grammar specifies both the concrete and abstract syntaxes with the same notation and annotates the concrete syntax to define how it is translated to the abstract syntax.

CST to AST Transformations

The abstract syntax tree is defined in a new section called "Abstract Syntax Tree" that goes after the productions in the grammar file. Once we've defined our abstract syntax tree, we then annotate the concrete syntax tree with translations to the abstract syntax tree.

The translation for each concrete production is specified in two parts: the concrete production is annotated to specify which abstract production it maps to and each alternative of the production is annotated to specify how to translate it to an alternative of the abstract production.

Starting with the concrete expr production, we want to translate that into the abstract expr production we have defined in our "Abstract Syntax Tree" section. To do so, we use the following annotation written between curly braces:

expr {-> expr} = ...

We then need to specify how the alternatives of the concrete expr production map to those of the abstract expr production. We must map the concrete add and sub productions to new nodes of the appropriate abstract type. Here's what these transformations look like:

expr {-> expr} = 
    {add} [left]:expr add [right]:factor  {-> New expr.add(left.expr, right.expr)}
  | {sub} [left]:expr sub [right]:factor  {-> New expr.sub(left.expr, right.expr)}
  ...

Again, the transformations are specified in curly braces and preceded by an arrow. New nodes are created with the New keyword followed by the name of the node of the abstract syntax tree to create and its children, if any, as arguments. The identifier of an abstract syntax tree node is the name of the production suffixed with the name of the alternative. E.g. "expr.add" identifies the add alternative of the expr abstract production, "expr.sub" identifies the sub alternative.

The child nodes passes as arguments have already been transformed to abstract syntax by the time they are passed to the new node. You identify a transformed node by the name of the child in the concrete grammar suffixed by the type that it has been transformed to. E.g. "left.expr" identifies the left subexpression that has been transformed to an abstract expr production.

The last alternative of the concrete expr production is expr.factor. This exists in the concrete syntax to define operator precedence and doesn't exist in our abstract syntax. We want to replace it with the transformation of it's only subtree, also named factor.

expr {-> expr} =
    {add} [left]:expr add [right]:factor  {-> New expr.add(left.expr, right.expr)}
  | {sub} [left]:expr sub [right]:factor  {-> New expr.sub(left.expr, right.expr)}
  | {factor} factor                       {-> factor.expr};

factor {-> expr} =
    {mul} [left]:factor mul [right]:value {-> New expr.mul(left.expr, right.expr)}
  | {div} [left]:factor div [right]:value {-> New expr.div(left.expr, right.expr)}
  | {value} value                         {-> value.expr};

value {-> expr} =
    {number} number                       {-> New expr.number(number)}
  | {parens} left_paren expr right_paren  {-> expr.expr};

The transformations of the factor and value productions follow the same pattern.

Transforming Lists

Another common difficulty with SableCC concrete syntax trees is that arbitrarily sized lists often have an unwieldy representation in the generated Java code. As an illustration, let's extend the expression language to support functions:

value = {number} number
  | {parens} left_paren expr right_paren
  | {function} [name]:identifier left_paren [args]:arg_list right_paren;
  
arg_list = 
    {single} [arg]:expr
  | {multiple} [arg]:expr comma [rest]:arg_list;

The concrete definition of argument lists is pretty awkward. Our analyser has to deal with the "single" and "multiple" alternatives and follow the "rest" link in the multiple alternative to collect all the arguments. It would be much easier to analyse if the argument expressions were stored in a collection.

Again, SableCC 3 come to the rescue. We can transform the concrete arg_list into a list of exprs. In the generated code, this list is stored in a standard Java List.

Firstly, we'll need to add a function alternative to our abstract syntax:

expr = {add} [left]:expr [right]:expr
     | {sub} [left]:expr [right]:expr
     | {mul} [left]:expr [right]:expr
     | {div} [left]:expr [right]:expr
     | {number} number
     | {function} [name]:identifier [args]:expr*;

The "expr*" type indicates a list of zero or more expr clauses.

Now we need to annotate the concrete function syntax with the transformation to the abstract syntax:

value {-> expr} = 
    {number} number                                                     {-> New expr.number(number)}
  | {parens} left_paren expr right_paren                                {-> expr.expr}
  | {constant} [name]:identifier                                        {-> New expr.constant(name)}
  | {function} [name]:identifier left_paren [args]:arg_list right_paren {-> New expr.function(name,[args.expr])};

Note the square brackets around the "[args.expr]" argument. They indicate that the "args" clause is translated into a list of exprs, not a single expr.

Finally we need to define how the different alternatives of the args_list are collected into a single list.

arg_list {-> expr*} = 
    {single} [arg]:expr                         {-> [arg.expr]}
  | {multiple} [arg]:expr comma [rest]:arg_list {-> [arg.expr, rest.expr]};

The annotation of the arg_list production "{-> expr*}" indicates that it is translated to a list of expr elements. The annotations of the "single" and "multiple" alternatives specify how to build that. The single transformation builds a list with one element, the subexpression named arg. The multiple transformation prepends the subexpression named arg to the list created by transforming the rest of the arg_list.

Conclusion

That covers the basics of concrete-to-abstract syntax transformations in SableCC 3. I hope this overview sheds some light on a powerful but underdocumented feature. Concrete-to-abstract syntax transformations let SableCC shine in an iterative development process. By working on the abstract syntax, analysis code is shielded from changes to concrete syntax. You can add to or change the grammar during the project without breaking a lot of existing code. I've found it easy to design a language test-first, repeatedly writing unit tests to specify syntax and semantics and then changing the grammar and interpreter to make the tests pass. This has let me play with language design and quickly experiment with new language features.

All the source code used in the examples above and IntelliJ project files are available in a Zip archive.

Update 28/09/2005: SableCC 3.0 is now a stable release, so you can happily use it in production systems.