(Please bear in mind during the following, that my Eee is not running any desktop environment (DE—i.e.GNOME, KDE, XFCE, LXDE, etc…)

For some time, I’ve been looking for a non-fiddly (and preferably GUI) way of switching display modes on my Eee, especially if an external VGA monitor is connected. The basic tool for controlling displays, xrandr, is powerful and flexible, but also quite difficult to use if one is not gifted with a particularly good memory for complicated command-line strings (especially if more than one display is involved).

lxrandr

There are a number of graphical front-ends for xrandr, but I found all the ones that I tried, were either clunky, buggy, partially or entirely ineffective, or a combination of these. However, the other day (and I can’t remember where), I read a suggestion that Linux users not employing a DE, could try lxrandr, the display settings GUI used in the LXDE desktop environment.

Installing lxrandr isn’t difficult, as it can be found in the main Arch repositories—a simple sudo pacman -S lxrandr should be sufficient. As you can see from the screenshot, the program makes it very easy to activate, deactivate and configure displays; I have used it to control the output from my Eee to a VGA monitor, and as long as xrandr can detect display modes and the like, then I imagine lxrandr should be able to do so too.

In short: if you’re after a simple but effective GUI for a Linux system without a DE, then you could do far worse than try out lxrandr.

Enabling “native” PDF viewing in Chromium

The default Web browser I use on the Eee is Chromium (basically, the open-sourced relative of Google Chrome without the Google branding and other “hooks”). In most respects, the Chromium in the Arch Linux repositories is more or less identical to Chrome in functionality, but one missing feature—which you may or may not miss—is Chrome’s built-in PDF-viewing functionality.

If you do miss it, the Arch wiki reveals a few options for PDF-enabling Chromium; my preferred option, which I’ve used on the Eee, is to install chromium-stable-libpdf from the AUR. This seems to work without a blip, and Chromium auto-updates from then onwards without losing the PDF feature, so it’s worth a try if you want this (and/or are looking for an alternative to Adobe Reader, Evince, xpdf and their ilk…).

And the “old friend”…

NCSA Mosaic on my Eee, "displaying" the Google home page...

Time to show my age: the first Web browser I ever saw, was NCSA Mosaic, running on Windows 3.1x in the autumn of 1994. It was soon overtaken by Netscape, and I didn’t think much about Mosaic until recently, when I learned someone has been modifying the X11 Mosaic source code, so it will compile and run on modern Linux systems. Moreover, as I suspected would happen, someone has added a Mosaic package to the AUR, so I just couldn’t resist finding out if I could get the ancient browser going on my 701…

And here is a screenshot to prove it: NCSA Mosaic running on my Eee under Arch Linux (the screenshot was taken from a 1280×1024 external display, in case you wondered why it looks larger than 800×480)!

There’s probably a whole blog post to be written about how well Mosaic copes (a) on a modern Linux system, and (b) on the Web after fifteen years of leaving Mosaic behind, but suffice it to say, the screenshot on the right is supposed to be the Google home page. You may draw what conclusions you like from this…

My Eee Desktop - January 2012

If you’ve read the last post I wrote on this blog, you will be aware that I am eagerly awaiting the launch of the Raspberry Pi (an ultra-low-cost computer on a circuit board the size of a credit card, running on an ARM processor). To cut a long story short, I’m already thinking of software I could run under Linux on the machine, and the Fluxbox window manager (which I use on my Eee 701) is one possibility I have been considering.

With the above in mind, I thought I would try creating a Fluxbox “style” (theme) based on the Raspberry Pi logo and its colours. Not only would the theme aim to reflect this identity, but I wanted a Fluxbox style which would be clear, minimalist and uncluttered, and be usable and readable at a wide selection of screen resolutions (up to and including full HD (1920×1280), which the “RasPi” is apparently more than capable of).

This month’s “My Eee Desktop” shows where I have reached with the Raspberry Pi style. I created the wallpaper image in Inkscape—the RasPi logo has been made available as an SVG vector image, so I took this and placed it over a gradient-filled circle (to give the “halo” effect) on a black background.

The wallpaper image is set at 800×480 resolution (that of the Eee 701), but if a higher resolution is used, the image is centred on the screen and the background around it is also black, so the style is very adaptable. As I would envisage connecting a RasPi to an HD TV, I chose black as the most suitable background colour for looking at over a lengthy period (just in case!). The menu and window fonts are set a little larger than normal for my Fluxbox styles, to make them more readable at high resolutions, whilst still not taking up too much space on an 800×480 display.

The only other point to note (particularly for longer-term readers here), is the addition of a GKrellM plugin to add an analogue clock. This takes up slightly less vertical space than a WindowMaker dockapp (as do most of GKrellM’s “monitors”), which on a screen with only 480 vertical rows of pixels, makes plenty of difference!

That’s all for this month—see you in February with another desktop

If you follow the tech and gadget press—and perhaps even the “regular” media’s technology supplements—you may have got wind of a British-initiated IT project which has garnered a considerable amount of interest in recent months… and has now grabbed my attention too

The product in question is the Raspberry Pi, and although it is officially aimed at schools and the education market, the device already has computing and Linux fans straining at the leash to get their paws on one.

Judging by the coverage, the reasons are not hard to understand. In short, the Raspberry Pi is a functioning computer, with (on the “Model B”) an ARM processor, 256Mb RAM, a OpenGL-capable graphics system with HDMI and component video output, audio out, 10/100 Ethernet, USB and 5V micro-USB power… all built onto a circuit board the size of a credit card, and likely to cost around UKP25. Initially, the device will be sold “as is”, without a case or enclosure, though from what I have read, there is no shortage of enthusiasts stepping up to design custom cases, or suggest alternative enclosures (an empty tin of Altoid mints seems to be a popular one!).

There are plenty of news sites picking up on the potential of a device like this. To pick one out at random, The Guardian has given the Pi some attention in its Education section, focusing on the avowed aim of the project to revitalise the teaching of computing in schools (and perhaps even inspire a new generation of coders and ‘hackers’ (in the non-criminal, inventive sense of the term)).

OK… so why am I posting on my Eee blog about the “R-Pi”? One reason is that I’ve always been interested in small and inexpensive computers, from the Psion Series 3x and Series 5mx I owned in the late 90s, through to the Eee 701 itself, and the Raspberry Pi looks like it packs a lot of functionality into a very small and cheap package.

Furthermore, as a leaf through this very blog should reveal, I am a keen Linux “tinkerer” when it comes to my Eee, and the R-Pi provides ample scope for experimentation, with HDMI, USB and Ethernet connectivity in a low-power device. There are a number of prominent Linux distributions which have been ported to the ARM processor family, including Debian and Fedora, but most of interest to me is Arch Linux ARM, as I could hopefully “port” my experience with Arch’s x86 sibling to the R-Pi.

Finally: quite simply, my imagination is fired by the idea of a usable computer which could fit in a pocket. Any HDMI display could be used as a monitor, as well as just about any keyboard or pointing device with a USB interface—even a combined one with a wireless “dongle” should work—so the device should be usable wherever you could find a “spare” TV or HDMI-equipped monitor. I’m not the only one thinking that the R-Pi could make an extremely affordable “media centre” computer, and look forward to seeing how that pans out…

The word is that the Raspberry Pi will be made available to purchase from their Web site from the end of this month (January 2012), and I for one will be keeping an eye on this very closely.

Thanks to everyone who has stuck with this blog since I resurrected it last July—it has had a few quiet periods since then (including December, as it happens), but I have a couple of thoughts for posts this month, the first of which you should see here in a few days’ time.

I’m not sure yet whether I’ll do a “My Eee Desktop” post in January, as my 701′s desktop is likely to look virtually identical to the screenshot in this article (i.e. virtually unchanged), but perhaps I’ll upload a pic anyway to keep the tradition going.

Anyway, thanks again for reading, and best wishes to all you good readers for 2012!

My Eee Desktop - December 2011

Actually, I’m already thinking about revamping this setup, at least with regard to the wallpaper, which I feel is a bit “busy” (especially as Conky is being displayed on top of it). Otherwise, I think it captures the mood of this time of year pretty well…

You may have noticed that Cairo Composite Manager is still running—I was wondering recently if it was possible to run Conky, xsnow and Cairo at the same time, but I haven’t found a way at time of writing, so I’ve decided to leave xsnow on the sidelines for the moment.

Not much else to report here, except to explain the white square in the “slit” on the right-hand side: it’s supposed to be the XMMS spectrum analyser dockapp, but for some reason it didn’t show up in this screenshot.

Anyway, hope you enjoyed this month’s My Eee Desktop, and if that’s not enough festive fun for you, try checking out  the December 2009 and December 2010 entries

At the moment, I am trying to assemble a suitably Christmassy instalment of “My Eee Desktop” for next month, but I’ve run into a small problem. At the moment, I am running Cairo Composite Manager on top of Fluxbox, and for the most part it works fine, providing various desktop effects (translucent windows, animations, etc.). At the same time, I also run Conky, with the “own window” setting enabled so that it will appear when cairo-compmgr is operational.

For my Christmas Eee desktop, I’d like to add the old X favourite xsnow… but there’s a problem: xsnow draws to the “root window” (i.e. desktop), as does cairo-compmgr. In other words: if the latter is running, you can’t see xsnow. (This has been a known problem with desktop environments like GNOME and KDE for years, as they too use the root desktop to draw folders, icons and so on.)

Basically, if I turn off Cairo, I can get xsnow and Conky running together, due to the latter’s “own window” setting, but Conky “blocks” the view of xsnow (as Conky is running in its own window, on top of xsnow). There are solutions for running xsnow with GNOME and KDE, but neither seems to work with cairo-compmgr—I would’ve thought there was a way to add some kind of “exception” in Cairo for xsnow, but I haven’t yet found it.

So, in short: can anyone think of a way to run xsnow with cairo-compmgr?

(Also, I’d be interested to hear if anyone knows of any other “festive” Linux applications, such as “strings of blinking lights across the top of the screen” and that sort of thing—frankly, the cheesier the better )

Thanks in advance for any help, and I’ll be glad to reveal the results in a few weeks’ time…

The other day, I was skimming through the Wikipedia article on the Fluxbox window manager (which I use on my Eee), and a sentence which I hadn’t spotted before, caught my eye:

Effects managers such as xcompmgr, cairo-compmgr and transset-df (deprecated) can add true transparency to desktop elements and windows.

In (relatively) plain English, it seemed to be saying: if you use Fluxbox, you can now add desktop “eye candy” such as translucent windows, fades, slides, etc. to your slimline desktop.

This came as a surprise to me. I’d always believed that you couldn’t add “compositing” effects to Fluxbox, because the leading compositing effects managers like Compiz used their own window manager—in other words, if you want the whizz-bang visuals, it was “bye-bye Fluxbox”.

In fact, there is a composite manager which works with the window manager of your choice (including Fluxbox): Cairo Composite Manager.

The article on Cairo in the Arch Linux Wiki tells you how simple it is to install from the Arch community package repository (sudo pacman -S cairo-compmgr), and from there you can test it by running cairo-compmgr & from the terminal. If you like what you see, and want the manager to start with your X session, you just add cairo-compmgr & to your .xinitrc file.

Fluxbox desktop with cairo-compmgr (note the transparent terminal window)

For me, it really was as simple as that, and here is the obligatory screenshot to prove it The main indicator that cairo-compmgr is running, is the truly-translucent XFCE Terminal window in the middle—I could’ve experimented a bit more with the translucency effects, but at present I haven’t had time to do much more than use the default settings. I’d like to see if the Fluxbox “slit” (dock) can exhibit true transparency/translucency, and I’ll probably try that out when I put together the December (Christmas) instalment of “My Eee Desktop”. (Yes, that time is coming around again…)

I would’ve liked to add a video as well, to show off some of the animated desktop effects, but am not sure that the screen-capture solutions available would display them to best effect. I’d probably end up pointing a camcorder at the Eee’s screen!

Oh, and in case anyone wondered: the only different addition to the desktop since last month aside from Cairo, is the XMMS Spectrum analyzer dockapp I found in the AUR. It installs as an XMMS plugin, and I thought it might make a change to add this to the slit this time around.

One small tweak I had to make as a result of Cairo’s arrival, was to my Conky setup file (.conkyrc). When I activated Cairo, my Conky display disappeared—a quick Google revealed that this was basically Cairo and Conky disagreeing about which program could draw to the root window. This is similar to how Conky works with the GNOME desktop (Nautilus grabs the root desktop for itself), so the solution is to add some lines like this to your .conkyrc:

own_window yes
own_window_type desktop
own_window_transparent yes

As ever, you may have to experiment if you try this for yourself, but it fixed the Conky issue for me.

I haven’t noticed Cairo making the Eee work much harder, although clearly there will be an impact on the system (even if it is a small one). Until (if?) I notice anything untoward, I’m content to keep this app running, simply because it adds some polish to an already lean and functional desktop—I’ll be sure to come back here and update you, should this change.

In the meantime, if you’re running a lightweight desktop or window manager, but still crave some of that composited eye-candy goodness, you may find Cairo Composite Manager fits the bill nicely.

This isn’t a case of “oh, Linux can’t do that”—distributions like Ubuntu come ready to automount removable drives “out of the box”. This behaviour is standard with desktop environments such as GNOME or KDE (which usually take care of it themselves), but as you’ll know if you’ve been reading here for a bit, my Eee 701 isn’t running a DE, but “simply” the Fluxbox window manager (mostly for the sake of speed).

Also, the “keep it simple” philosophy of Arch Linux, doesn’t tend to add features “by default” because not all users will want or need them. If you want your Arch system to include a given feature, most likely the maintainers and community have provided the means (applications and guidance) to add it, but it’s down to the user to do the “donkey work” from there.

I certainly wanted to have automounting enabled on my Eee, so after some Googling and Arch wiki/forum-ing I found a udev rule which looked as if it would fit the bill. And so it did… within limitations. The rule would create a mountpoint directory within /media/, and mount the drive contents there; however, it wouldn’t “clean up” after itself, leaving the mountpoint directory within /media/ once the drive was umounted. Also, the rule usually failed to mount some drive volumes, and most annoyingly, wouldn’t mount the disc inside my USB CD/DVD drive.

This last is what led me to the Arch wiki page on udev, which suggested using a “udev wrapper script” (these have their own wiki page) for handling optical drives. The wrapper page in turn put forward a few candidates, of which devmon came at the top of the list. It’s in the AUR rather than the main Arch repositories, but no matter—I built the package and installed devmon as per the instructions on its home page. I also moved the “old” udev rule to another location where it couldn’t be accessed by udev itself, just in case it might disagree with the newcomer.

In short: how I wish I’d found devmon earlier.

So far, it has handled the mounting of almost every device I have “thrown” at it, including my optical drive. I have assigned a Fluxbox key combination (Ctrl-Alt-J) to devmon‘s command for umounting and ejecting an optical disc, though I’d prefer to find out how to have devmon eject the disc on receiving an umount from elsewhere (e.g. the wmvolman dockapp, which doesn’t even display the mounted optical disc). The script also removes the device’s mountpoint upon umounting, which I definitely appreciate.

The only “drive” that devmon has yet to work with, is the “mass memory” on my Nokia N8, which the old udev rule couldn’t handle either. I suspect this is something to do with the device number that shows up when the phone is connected to the Eee in “mass storage” mode (/dev/sdX rather than /dev/sdX1), but this is something I have to look into further when I can be bothered It’s not the fault of devmon, as far as I can see, as the udev rule also exhibited the same issue. (Update (2011/10/17): I have a lead on this—see the update below…)

In summary: if you’re assembling a Linux system without GNOME or KDE (and certainly if you want to use a “light” window manager like Fluxbox or Openbox), but you would still like the system to automount removable drives, you owe it to yourself at least to give devmon a try.

Update (2011/10/17):

I received an email from the developer of devmon, who judging by the script’s home page, is often on hand to help users who run into issues. Between us, we confirmed my suspicions that devmon isn’t the source of the N8 mounting problem—it looks to be a bug in udisks, which devmon interacts with.

Just like to point out I haven’t had any other issues with the script, and am grateful to “IgnorantGuru” for helping to clear that up

E7P with retro Mac OS theme

As the wonderful folk at wordpress.com laboured through the night to bring Boing Boing’s fine “retro Macintosh” WP theme to wordpress.com blogs, I couldn’t resist switching to it for a few days, in tribute to former Apple CEO Steve Jobs. (If you’re reading this more than a week or so after the date of this post, I’ve probably switched back to the old theme.)

Yes, I know this is a blog about a Linux-powered Eee netbook, but we have had two Macs in the house, and I certainly have no difficulty using Mac OS X alongside my “penguin-powered” devices. Furthermore, I don’t think anyone would deny that the last ten years in computing would’ve turned out quite differently without Apple’s influence, especially from the “iDevices”. For one thing, I’m pretty sure my current Nokia mobile (an N8) would look more like my previous one (an N95) if the iPhone hadn’t made such a splash.

However expected Steve Jobs’ death may have been, his loss is felt by millions around the world, and although the nature of his legacy may be fought over in the months and years to come, perhaps only Bill Gates (for better or worse) can claim to have made a comparable impact on computing for the masses.

RIP Steve, and my condolences to his family at this time.

My Eee Desktop - October 2011 (modified WinSpace)

Here is the first, and let’s start with the “theme”: it’s a modified version of the Windows 95-influenced “WinSpace”, one of a set of themes created for Fluxbox’s predecessor Blackbox. I needed to make a few adjustments, mainly to the fonts (to adapt to the Eee’s 800×480 screen), but also to make the window borders match the background colour for the main feature…

The apps in the “slit” on the right-hand side here, have changed quite a bit even since the last desktop shot from a few weeks ago. Two apps have remained (wmdrawer at the top, with the Arch Linux logo, and wmvolman (the one with the disk icon)), but the other dockapps have “gone on holiday”, to be replaced by two others.

In the bottom-right is wmbinclock, a binary clock display (check out the app’s home page to find out how to tell the time from it). This app is not even in the Arch User Repository (AUR), so I had to compile it from the source code—still, it scores me a few points on the “geek scale”…

Sandwiched inbetween the dockapps, is another old fave: the venerable GKrellM system monitor, here using the “Hardware” “skin”. The slit has “pseudo-transparency” switched on, mainly to show off the GKrellM design.

Call the above the cartoon before the main feature…

My Eee Desktop - October 2011 (TheGrid)

Here is my current desktop setup, which I can see myself sticking with for a while. I have to say I’m quite pleased with my latest Fluxbox theme here, which I modified heavily from an earlier one of mine. I was going for a “TRON”-influenced look—all cyan-neon text and lines—and call this theme “TheGrid”. The background isn’t an image, but a gradient-fill defined in the theme file—the computer world in the original “TRON” always seemed to have that “just before dawn” look, which inspired my choice of background.

The “slit” has been reworked again, and I’ve added a couple of new monitors to the GKrellM stack (still experimenting on that front; since this shot was taken, I’ve replaced the CPU graph with a “photo frame” plugin). The GKrellM “skin” is called “CoplandOS”, and I think it blends quite well with the rest of the theme. Note the XMMS plugin in the GKrellM stack—that’s quite handy, and can almost replace the main XMMS interface (but for me, not quite).

Only two dockapps remain: wmdrawer at the top (with a new Arch Linux logo image for the “button”—I have also activated the drawer in this shot), and wmvolman at the bottom (I haven’t yet found a GKrellM plugin which does the same job with automounted volumes).

I may not present a desktop post next month, but if not, I’ll treat you to something suitably festive for December