Eee 701 Planetoid


Quick tip: invert colours on a Linux X11 display

Filed under: Linux, Software — Tags: , , , — Tim @ 17:33

One feature I have set up (and find very useful) on my iPhone, is a triple-press on the “home” button to invert the colours on the screen. (I won’t go into details on how to do this in iOS—it’s not the purpose of this post—but basically, look in Settings > General > Accessibility for details.) This is really handy for moments when you just don’t want to look at a very white screen (and unfortunately, iOS7 has lots of those), and a triple-press will turn white to black, to spare one’s eyes, blushes, etc…

I wondered if there was a not-too-complex way to set up a similar feature on a Linux machine, preferably at the X11 level (i.e. not tied into a particular window manager or desktop environment), and a quick Google search revealed I was in luck.

In short, there’s an command-line utility called xcalib, which is mainly intended for monitor calibration, but which has a handy feature: yes, it can invert the current X display’s colours (effectively, giving you a negative of the display). The program isn’t included in Arch Linux’s main package repositories, so you’ll have to build/install xcalib from the AUR—it’s a tiny program, so that will barely take you longer than installing it from a repo would.

Once the program is installed, running

xcalib -i -a

(for “invert” and “action”—i.e. “do it”) will invert your display’s colours; running the same again will switch it back.

Very useful, and even more so if you assign it to a keyboard shortcut—each DE and WM has its own way of setting this up, but in Xfce you do this in Xfce menu > Applications > Settings > Keyboard > Application Shortcuts [tab]. I used Ctrl-Alt-I (for “invert”), but that’s just personal taste 🙂

Maybe this feature is already present in some DEs, but at least this one will work in any environment—hope it helps you too!


A new beginning for my Eee… or at least, a reboot

Filed under: Linux, Software — Tags: , — Tim @ 17:49

It’s almost twelve months to the day since I last posted anything to this blog, because of a busy life and the fact that my Eee was working quite nicely. No change with the former, but the latter is about to get some serious attention…

Thanks to botched “manual intervention” on my part, whilst trying to accommodate Arch Linux’s recent consolidation of all binary executables in /usr/bin, I ended up with an unbootable OS on the Eee (and the Raspberry Pi too, though that’s another, less pressing, issue). Despite Googling around and trying all sorts of fixes, I simply don’t have the time or the inclination to hack the system back to working order.

Given that the system has a number of long-standing issues (again, which I’ve never quite got around to trying to resolve), and the Eee’s solid-state drive is permanently over 95% full, I have taken the decision to “wipe the slate clean”. I’ve made a backup of my home directory and any other important files I could think of, and I am going to wipe the Eee’s drive and do a complete, “ground-up” reinstallation of Arch.

This time around, I want to avoid installing any GNOME-related material wherever possible, and am planning to go for XFCE and Fluxbox as my desktop environment and lightweight window manager respectively (so I can choose between them). I’ll be setting up Chromium, Dropbox and various other applications I make regular use of, and I’ll try and drop by here from time to time and let you know how it’s getting on.

I know that a total reinstallation sounds drastic, but I’ve had it on my mind for the Eee for some time. I still think Arch is the Linux distribution most suited to the 701—though I can’t pretend I’m entirely happy about the way the distro handles major “under-the-bonnet” system changes (and the /usr/bin one isn’t the first to cause me problems), in my view Arch’s customisability (especially for limited hardware) gives it a serious advantage over the Linux competition, at least for me.

So, if there’s anyone still “following” this blog: thanks for sticking around all this time, and I’m about to hoist it out of mothballs…


Review: Turpial

Filed under: Raspberry Pi, Reviews, Software — Tags: , , , , , — Tim @ 21:12

It might surprise readers to learn that I’ve had surprising difficulty finding a “lightweight” graphical Twitter client for Linux, that works comfortably on a small screen and (for good measure) has a multi-column display mode.

For some time, my favourite Twitter application has been TweetDeck—either in its “native” form (usually on the Mac) or its Chromium app version (Arch Linux on my Eee). However, whilst the Chromium TweetDeck app “does the job”, I have used it while at the same time, watching out for a “native” app which might function usably on the Eee’s more constrained hardware. (This became more pressing when I acquired my Raspberry Pi Model B, as the Chromium browser doesn’t run particularly comfortably on the machine.)

Screenshot of Turpial

Turpial running on the Eee 701SD (thumbnail – no larger version available)

The other week, I searched the Arch Linux package listing of Twitter clients, and amongst the fairly lean selection—much of which were text-mode/console programs (which perhaps I’ll check out another time), I found a client I hadn’t heard of previously: Turpial, created by a self-professed “bunch of crazy people” (!) in Venezuela. (I don’t think I’ve seen so many coders credited by name for an open-source app before, but the project seems to benefit 🙂 )

Turpial can be found in the Arch “community” repository, so installation is simply a matter of entering (as root)

pacman -S turpial

It’s a Python program, so if you don’t already have the dependencies installed (and there are quite a few, mostly python2 and related packages), pacman will need to retrieve them. Once it’s installed, Turpial will ask you to enter your account details and authenticate with Twitter; the latter will ask you to enter a number into Turpial itself, to ensure the app has permission to interact with your Twitter account.

In action, Turpial runs reasonably smoothly, considering it is a Python program. “Out of the box”, it displays three columns at a time in its window, and you can toggle between two “sets” of three columns:

  • “Master” timeline, “at-replies” and direct messages; and
  • Your profile, favourites and a search column.

The window maximises comfortably and tidily into the Eee’s 840×480 display, without looking particularly squashed-up. If you’re using a larger screen (hold that thought), Turpial doesn’t take up much space, though I am curious to find out whether the program can be set to display fewer columns (or even a single one), for use on a very low-res display, such as VGA (640×480) or a non-widescreen SD television set. I may soon get that very opportunity…

If you have a notification daemon running, Turpial will let you know when new tweets are received. I use the XFCE notifier on my Eee and RasPi, with no problems experienced.

A row of pictogram buttons below the message columns, takes the place of a text-menu, giving you access to the application’s other options, including posting a tweet, finding and following other users, posting an image (but not other multimedia) and the program’s preferences.

The “update status” dialogue box has a handy “add friend” option, to choose friend(s) from a list box to include in a tweet. There is also a separate field for shortening URLs (you set the shortening service of your choice in the preferences). Both handy features, and not always implemented in more “modest” Twitter clients—thumbs-up to the Turpial team here.

Image-uploading is relatively straightforward as well—again, you set the Twitter-image host of choice in the Preferences. Almost all the common services are present in the list, with the notable exception of Flickr (which my favourite mobile phone social-networking client, Gravity, includes). It would really “put the icing on the cake” for me if Flickr support could be added in a future version of Turpial; however, it is not a “show-stopper” for me, as I usually upload images from my phone to Flickr, which then updates my Twitter timeline. (I don’t mind using Yfrog for more “ephemeral” images, either.)

Turpial also packs a couple of useful features which are rare on Twitter clients:

  • If you’re a Twitter regular, you’ll occasionally (or more?) find that a user may start sending a large amount of posts (say, “live-tweeting” an event), which may clog up your timeline, or otherwise make you feel that you’d rather not see all their tweets, without actually un-following them. Turpial offers an ingenious solution: a “mute” option. Just tick the box next to the “friend(s)” in question, and the application will not display their tweets until you un-tick them in the list. Potentially handy, but if you use this, just remember to take said friends off the list… 😉
  • Similarly, the “filter” option allows you to specify words which you would rather not see in your timeline. I haven’t tried this yet, so I don’t know whether it “bleeps out” words or hides entire tweets containing them, but it could be handy if you want to hide a certain hashtag!

A tip, which I originally didn’t spot: to exit the program, don’t simply close the main app window, as this leaves Turpial running (and consuming resources). Instead, the application places an icon in your system tray, so you need to right-click this and select “Quit” to exit. If you’re using the keyboard only, or for whatever reason your desktop environment/window manager doesn’t have a system tray, I’m not quite sure what you do, but neither apply to me in this case…

Overall, with Turpial, I feel I have found the Twitter client I have been watching for all this time, and not only for my Eee 701: it works usably well on my Raspberry Pi too. Being a Python program, Turpial doesn’t require separate compilation for the Pi’s ARM processor, so new versions generally arrive around the same time in the Arch repositories for ARM and x86. Turpial takes around thirty seconds to load on the Pi, but once it’s running, I find you can leave it up without great impact on the system.

Want an uncluttered, native, graphical Twitter client with a multi-column interface, which will run comfortably on a modestly-specced machine? Tall order, but I think Turpial meets these requirements, and is well worth a look.


Snippets: lxrandr, PDFs in Chromium, and a VERY old friend…

Filed under: Software — Tags: , — Tim @ 12:50

GUI tool for display settings

(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).

Screenshot of 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”…

Screenshot of the NCSA Mosaic Web browser

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… 🙂


cairo-compmgr, Conky AND xsnow: is it possible?

Filed under: Desktops, Software — Tags: , , , , — Tim @ 18:14

I don’t often ask you good readers for help on this blog (sorry about that!), but I was hoping that someone reading this might be able to dig me out of a metaphorical snowdrift…

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…


Adding visual effects to Fluxbox with Cairo Composite Manager

Filed under: Desktops, Linux, Software — Tags: , , , , — Tim @ 17:30

(or “My Eee Desktop – November 2011” 🙂 )

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.

Image of Fluxbox desktop with Cairo Composite Manager

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.


Automounting removable drives with devmon

Filed under: Linux, Software — Tags: , , , , , , — Tim @ 18:46

One of the early issues I grappled with when I installed Arch Linux on my Eee, was that removable drives were not mounted automatically when connected—i.e. it was not a case of “plug and play”.

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 🙂


My Eee Desktop – October 2011

Filed under: Desktops, Software — Tags: , , — Tim @ 12:20

For this month’s “My Eee Desktop”, I’ve a special treat for you: not one, but two screenshots, both taken within the last two weeks…

Screenshot of desktop

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…

Screenshot image of "TheGrid" Fluxbox theme

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 🙂


Lightweight network access with wicd

Filed under: Linux, Software — Tags: , , , — Tim @ 18:42

One of the double-edged features of Arch Linux, is that it encourages the user to put together a software system which suits their needs, and not necessarily the system which someone else has assembled for them.

That’s not meant as a criticism—Linux distros like Ubuntu are great if you want/need a workable OS “out of the box”. However, as I’ve written here before, it’s not what I wanted for my Eee 701—my aim was to put together a “leaner” OS for the machine, which would use as many “lightweight” alternatives to the usual GNOME and KDE applications as possible.

Desktop environments like GNOME do a lot for the user, that they don’t always realise—one example is GNOME’s NetworkManager. It sits unobtrusively in the GNOME panel, quietly doing its best to connect the user to wired and wireless networks. If you want a Linux setup without GNOME and its associated apps, but would still like a measure of “hand-holding” managing your network connections, what is the alternative?

Image of wicd graphical and console clients

wicd graphical and console clients, running under Arch Linux (with Fluxbox)

For me: the answer is wicd. Wicd (pronounced “wicked”, apparently) is a network manager for Linux, which at its simplest has no GNOME or KDE dependencies, so it is well-suited to running under lightweight window managers like Fluxbox or IceWM (and is installed as part of quite a few “light” Linuxes, such as Zenwalk). In fact, wicd doesn’t need to run under X at all—it operates as a client-server application, where the server (daemon) does all the network-connection work, and you use a client application to interact with it. There are graphical (Python/GTK+) and console (ncurses) clients, so you can choose which you prefer (or need) to use.

Should you wish to give wicd a spin on your Linux system, you should be able to install it via your package manager, or compile it if you prefer. You need to start the wicd daemon at boot time; in Arch Linux, I add it to the “daemons array” in /etc/rc.conf. (For the finer points of setting-up, the wicd page at the Arch wiki is most useful.)

Most of the time, I’ve found wicd a “set it and forget it” kind of application—it stays in the background and just gets on with managing your connections. It’s not perfect—sometimes it fails to reconnect a dropped wireless link (giving a “bad password” error, even if the password is given correctly), though I believe I read this is a DHCP client issue, rather than wicd specifically—but in general I find wicd a pretty essential part of my Eee’s software setup. I especially appreciate that because of its client/server design, wicd is always running on the Eee, whether I am using the graphical interface or console. In X, the graphical wicd client can always be found in the system tray, and checking the network link is just as easy at the command-line.

Compared with GNOME NetworkManager, there are a few missing features; the main one that I would like to see, is a graphical interface for managing VPN connections. The wicd FAQ states that direct VPN support is planned for version 2—in the meantime, wicd offers the option to trigger per-connection scripts (a bit fiddly-looking to set up, but probably better than nothing). The developers have also expressed an interest in adding options such as management of 3G modem connections, but it looks like a lack of resources is holding this back for the moment. I think I’d like to keep an eye on the VeryPluggableBackends development branch, though…

In short: if you’re looking to build a Linux system without GNOME or KDE, but still want help managing your network connections, wicd is definitely worth investigating.


My Eee Desktop – September 2011

Filed under: Desktops, Software — Tags: , , , — Tim @ 19:23

I’m back from my late summer break, and as autumn hoves into view, it feels like time to share my current Eee desktop:

Desktop screenshot image

My Eee Desktop - September 2011

You can see from the screenshot, that I have a new Fluxbox theme which I have knocked together: I call it “Pugin“, after the Victorian “Gothic Revival” designer perhaps best known for the interiors of the Houses of Parliament in London. I created the tiled wallpaper at BgPatterns, using the wine-red and deep gold colours which are often associated with Pugin’s designs, and also applied these to the various Fluxbox window decorations (apologies for forgetting to include the Fluxbox menu in this shot).
(A word of caution about BgPatterns: it’s highly addictive, especially if you have a penchant for tiled desktop patterns, so I wouldn’t visit if you don’t have time to kill 😉 )

The main apps visible are “top” (running in XFCE Terminal), XMMS and xfontsel. For the “dockapps” down the right-hand side, you can refer to the last desktop article to find out the purpose of most of them—Conky is also running on the root desktop, but it is mostly obscured here by the other application windows.

Until next month…

Older Posts »

Create a free website or blog at