Tag: linux

Code

A note on the paging behaviour of more(1) in util-linux 2.38

Chris Cannam1 Comment

I just updated this system from util-linux 2.37 to 2.38 (util-linux is a set of small, commonly-used command line programs) to find a small but distracting change in the behaviour of more(1), the venerable text file pager utility.

For as long I can remember, the behaviour of more when run on a text file shorter than the current height of the terminal has been to print the contents of the file and return without any interaction.

In util-linux 2.38 this changes, so that more when run on a small text file will clear the terminal, show the file at the top of the window, print END at the bottom, and wait for input before returning. This is kind of distracting: clearing the terminal is not something I want, and also it makes the file look as if it has lots of blank lines at the end.

I spent a wee while figuring out where and why this change was introduced: turns out it’s for POSIX standards compliance. The commit that introduced the change is titled “POSIX compliance patch preventing exit on EOF without -e”, and the POSIX version of the man page for more(1) indeed supports this behaviour. I don’t remember ever seeing it before. I wonder which system it originated with.

Anyway the good news is that the new option -e or --exit-on-eof restores the expected behaviour, and adding export MORE="--exit-on-eof" to .bashrc makes it the default again.

Programs for Music

Rosegarden v15.08

Chris Cannam

D. Michael McIntyre today announced the release of version 15.08 of Rosegarden, an audio and MIDI sequencer and music notation editor.

Rosegarden is a slightly crazy piece of work.

As a project it has existed for more than two decades, and the repository containing its current code was initialised in April 2000. It’s not a huge program, but it is quite complicated, and during its most active period it was run by three argumentative developers all trying to accomplish slightly different things. I wanted to replace Sibelius, and typeset string quartets. Richard wanted to replace Logic and run his home studio with it. Guillaume wanted to replace Band-in-a-Box and make jazz guitar arrangements. We ended up with something that is essentially a MIDI sequencer, but with some audio recording and arrangement capacity and a lot of interesting (fragile) logic for adjusting score layout of music that is stored as MIDI-plus-notation-metadata rather than directly as notation.

Rosegarden has all sorts of rather wild features which even its developers routinely forget. It has a “triggered segment” feature that replaces single notes with algorithmically expanded sequences at playback time, intended for use in playing ornaments from notation but also potentially usable for simple algorithmic compositions. It knows the playable range and transpositions of large numbers of real instruments, and can transpose between them and warn when a part’s notes are out of range. It has a note-timing quantizer that aims to produce notation as well as possible from performed MIDI recordings, but that doesn’t change the underlying recorded MIDI, instead trying (futilely?) to keep tabs on the adaptations necessary to make the raw MIDI appear well on the score. It can record audio, play back MIDI through audio synth plugins, apply effects, and do basic audio editing and timestretching. It has a feature which surely nobody except me has ever used, that allows you to tap along on a MIDI keyboard to the beats in an audio recording and then inserts tempo events in your MIDI (assuming it represents the same score as the audio you were tapping along to) that make it play back with the same tempo changes as the audio.

Rosegarden contains about 300,000 lines of C++, excluding all its library dependencies, with (ahem) no tests of any sort. It has seen well over 10,000 commits from about 40 contributors, in a single Subversion repository hosted at SourceForge. (Previously it was in CVS, but the move from CVS to Subversion was hard enough that it has never moved again. Some of its current developers use git, but they do so through a bridge to the Subversion repository.) Although the code is moderately portable, and lightly-supported ports to Windows and OS/X have appeared, the only platform ever officially supported is Linux and the code has only been officially published in source code form—it is assumed that Linux distributions will handle compilation and packaging.

Despite its complexities and disadvantages, Rosegarden has survived reasonably well; it appears still to be one of the more widely-used programs of its type. Admittedly this is in a tiny pond—Linux-only audio and music users—but it has persisted in spite of all of its early active developers having left the project. Here are the top three committers per year since 2000, by number of commits:

2000 Guillaume Laurent Chris Cannam
2001 Guillaume Laurent Chris Cannam Richard Bown
2002 Richard Bown Guillaume Laurent Chris Cannam
2003 Chris Cannam Guillaume Laurent Richard Bown
2004 Chris Cannam Guillaume Laurent Richard Bown
2005 Guillaume Laurent Chris Cannam D. Michael McIntyre
2006 Chris Cannam Pedro Lopez-Cabanillas Guillaume Laurent
2007 Chris Cannam Heikki Junes Guillaume Laurent
2008 D. Michael McIntyre Chris Cannam Heikki Junes
2009 D. Michael McIntyre Chris Cannam Jani Frilander
2010 D. Michael McIntyre Julie Swango Chris Cannam
2011 D. Michael McIntyre Ted Felix Yves Guillemot
2012 Ted Felix D. Michael McIntyre Tom Breton
2013 D. Michael McIntyre Ted Felix Tom Breton
2014 Ted Felix D. Michael McIntyre Tom Breton
2015 Ted Felix D. Michael McIntyre Tom Breton

Some developers (Tom Breton for example) flatten numerous commits from git into single Subversion commits for the official repo and are probably under-represented, but this gives the general shape. Richard Bown mostly retired from this project in 2005, although his 794 commits in 2002 seems still to be the record. (Ted Felix has made 231 so far this year.) Guillaume Laurent forcefully moved to OS/X in 2007, and I faded out in 2010 after a big push to port Rosegarden from Qt3 to Qt4. What is most notable is the unifying thread provided by D. Michael McIntyre.

 

Computers

Replacing the GNOME Shell font in GNOME 3.16

Chris Cannam2 Comments

[Edit: see the comment by Hugo Roy after the article, describing a much simpler, more “official” way to achieve this]

When using Linux on a touchscreen laptop, I generally use the GNOME 3 desktop — logical design, big touch targets, good support for high-resolution displays, nice to look at.

While I mostly approve of the design decisions made for GNOME 3, there is one thing about it that I don’t get on with, and that’s its use of the Cantarell font. Cantarell is clear and readable, and a fine default for most UI text, but at the middle of the top of the screen there lives a digital clock:

Clock in Cantarelland I find this strangely annoying to look at. I think it has a lot to do with the excessively round zero. Since it’s always there, it annoys me a surprising amount.

Until GNOME 3.15, it was easy to change the font used throughout GNOME Shell by editing one property in a CSS file. Unfortunately GNOME 3.16 moved that CSS file into an opaque resource bundle and made it accessible only through some awkwardly-designed tools. I can’t fathom how that appeared to be a good idea, but there it is.

Anyway, with help from this forum post I knocked out a script to update this resource file so as to make it prefer the Fira Sans font from FirefoxOS. It makes a copy of the existing resource file with a .dist suffix.

This may be specific to Arch Linux (the distro I’m using), so caution advised if you refer to this for any reason. It’s necessary to have the glib2 and otf-fira-sans packages installed for this to work.

#!/bin/bash

set -eu

rname=gnome-shell-theme.gresource
resource="/usr/share/gnome-shell/$rname"

ext="$(date +%s)$$"
tmpdir="./fix_$ext"
mkdir "$tmpdir"
trap "rm -f $tmpdir/* ; rmdir $tmpdir" 0

manifest="$rname.xml"
cat > "$tmpdir/$manifest" <<EOF
<?xml version="1.0" encoding="UTF-8"?>
<gresources>
<gresource prefix="/org/gnome/shell/theme">
EOF

for file in $(gresource list "$resource"); do
    base=$(basename "$file")
    out="$tmpdir/$base"
    gresource extract "$resource" "$file" > "$out"
    echo "<file>$base</file>" >> "$tmpdir/$manifest"
done

cat >> "$tmpdir/$manifest" <<EOF
</gresource>
</gresources>
EOF

(
    cd "$tmpdir"
    perl -i -p -e 's/font-family:.*;/font-family: "Fira Sans", Cantarell, Sans-Serif;/' gnome-shell.css
    glib-compile-resources "$manifest"
)

sudo cp "$resource" "$resource.dist.$ext"
sudo cp "$tmpdir/$rname" "$resource"

Of course every time an update comes along, it overwrites the resource file and I have to run this again. Which is one reason I’m posting this as a reminder to myself.

Computers · Operating systems

Linux

Chris Cannam3 Comments

tagsI write plenty of tedious posts about computers and technology, and I usually tag them according to what they’re about.

As I write this, the tag cloud for this blog looks like the picture on the left—Apple and Microsoft loom large, Nokia and Oracle get a look in, and there’s no reference to Linux at all.

But Linux is the main operating system I use, and it has been for the last 15 years or more.

I never write about it because, like the boy in the German child joke, I’m content with it. I write about things that fascinate me, and there’s nothing less fascinating than a system that does what you expect it to, again and again.

Although I also develop software for Windows, OS/X, and Android among others, Linux is my home platform.

I like that it gives me a sense of independence from any particular platform I might deploy to. I like that it allows me to make my own decisions about the type of desktop environment I choose. (Never trust an OS that won’t allow you to change the system font.) I like the transparency of the development environment, and I appreciate being given the opportunity to find out how anything in it works—even though I don’t take as much advantage as I might.

So far, using mostly Linux has been a fine way to observe developments in other operating systems, from just enough distance not to get too caught up in any one of them.

A touch of froth

A jolt, though, comes with the arrival of touch interfaces. I’m not the only one to be surprised to find how pleasant a touch screen is to use with a laptop. For me, Apple had it wrong: though familiarity means I still prefer a mouse for detail work, I’d rather have a touch screen than a trackpad.

Maybe I just haven’t used touch screens enough to become really fatigued. But I wonder whether the research might not have underestimated how fatiguing the crabbing action of using a touchpad is. I don’t think “I’ve been waiting all my life for this touch screen”; I think “thank goodness I don’t have to use the touchpad”.

I’ve heard it remarked that innovative input devices interest consumers in a way that novel output devices seldom do. There are many examples of new input devices becoming mainstream, sometimes in wildly popular ways: the joystick, the mouse, the D-pad, the touchpad, gaming controllers with accelerometers and gyroscopes, computer vision devices (the Kinect) and so on. Meanwhile various innovations in output (such as 3D and very high-resolution screens) have appeared repeatedly and been largely ignored—unless they came in packages that were attractive for other reasons, such as the LCD display with its slender physical dimensions.

So, over the years I’ve taken quite good advantage of the ability to pick and choose my desktop interface on Linux. Like all self-regarding programmers, I’ve used my own window manager. I’ve used KDE, until I switched away when KDE4 arrived. Then I used GNOME, until I switched away when GNOME 3 arrived. Right now I’m using XFCE4. But it’s not at all touch-friendly, and nor are any of the applications I use. This one has so far completely passed me by.

In short, then, those Ubuntu and Gnome people that I’ve probably been rather rude about might have had a point. There was some reason to be piddling about with the basics of the user interface after all. I need to start finding out whether Linux, other than Android, can work well in the touch screen world.