Integrating Vim and GPG

Quite frequently, I need to take a quick textual note but when the content is sensitive, even just transiently, well, some things shouldn’t be left around on disk in plain text. Now before you pipe up with “but I encrypt my home directory” keep in mind that that only pretects data against it being read in the event your machine is stolen; if something gets onto your system while it’s powered up and you’re logged in, the file is there to read.

So for a while my workflow there has been the following rather tedious sequence:

$ vi document.txt
$ gpg --encrypt --armour 
    -r andrew@operationaldynamics.com 
    -o document.asc document.txt
$ rm document.txt
$

and later on, to view or edit the file,

$ gpg --decrypt -o document.txt document.asc 
$ view document.txt
$ rm document.txt

(yes yes, I could use default behaviour for a few things there, but GPG has a bad habit of doing things that you’re not expecting; applying the principle of least surprise seems a reasonable defensive measure, but fine, ok

$ gpg < document.asc

indeed works. Pedants, the lot of you).

Obviously this is tedious, and worse, error prone; don’t be overwriting the wrong file, now. Far more serious, you have the plain text file sitting around while you’re working on it, which from an operational security standpoint is completely unacceptable.

vim plugin

I began to wonder if there was better way of doing this, and sure enough, via the volumous Vim website I eventually found my way to this delightful gem: https://github.com/jamessan/vim-gnupg by James McCoy.

Since it might not be obvious, to install it you can do the following: grab a copy of the code,

$ cd ~/src/
$ mkdir vim-gnupg
$ cd vim-gnupg/
$ git clone git://github.com/jamessan/vim-gnupg.git github
$ cd github/
$ cd plugin/
$ ls

Where you will see one gnupg.vim. To make Vim use it, you need to put in somewhere vim will see it, so symlink it into your home directory:

$ mkdir ~/.vim
$ mkdir ~/.vim/plugin
$ cd ~/.vim/plugin/
$ ln -s ~/src/vim-gnupg/github/plugin/gnupg.vim .
$

Of course have a look at what’s in that file; this is crypto and it’s important to have confidence that the implementation is sane. Turns out that the gnupg.vim plugin is “just” Vim configuration commands, though there are some pretty amazing contortions. People give Emacs a bad rap for complexity, but whoa. :). The fact you can do all that in Vim is, er, staggering.

Anyway, after all that, it Just Works™. I give my filename a .asc suffix, and ta-da:

$ vi document.asc

the plugin decrypts, lets me edit clear text in memory, and then re-encrypts before writing back to disk. Nice! For a new file, it prompts for the target address (which is one’s own email for personal use) and then on it’s way. [If you’re instead using symmetrical encryption, I see no way around creating an empty file with gpg first, but other than that, it works as you’d expect]. Doing all of this on a GNOME 3 system, you already have a gpg-agent running, so you get all the sexy entry dialogs and proper passphrase caching.

I’m hoping a few people in-the-know will have a look at this and vet that this plugin doing the right thing, but all in all this seems a rather promising solution for quickly editing encrypted files.

Now if we can just convince Gedit to do the same.

AfC

Complaining about GNOME is a new national sport

Bloody hell. GNOME hackers, can someone sit Linus down and get him sorted so he stops whinging?

I mean, we all know GNOME 3 and its Shell have some rough edges. Given that computers users since the stone-age have been adverse to change, it’s not surprising that people complained about GNOME 3.x being different than GNOME 2.x (actually, more to the point, being different than Windows 95. How dare they?). Even though we believe in what we’re doing, we’re up against it for having shipped a desktop that imposes workflow and user experience changes on the aforementioned change-adverse hypothetical user.

BC comic strip

Surely, however, the negative PR impact of Linus constantly complaining about how he’s having such a hard time using GNOME exceeds what it might cost to the GNOME Foundation of getting somebody over to the Linux Foundation to help him out? Oh well, too late now.

Meanwhile, I certainly do agree that extensions.gnome.org is completely useless if the first thing you see on 3.4 release day is “your web browser version isn’t new enough”. It’s not just Fedora; running Epiphany 3.4 here on a current Ubuntu system, same problem. On the other hand, if you add ppa:gnome3-team/gnome3 and ppa:webupd8team/gnome3 to a system running the current Ubuntu release you can completely ditch Unity. You get an up-to-date GNOME 3.4 that works great, and thanks to webupd8 packaging extensions, you get a fair degree of customization over the experience.

Yeah, there is still lots of room for improvement, and of course there are design decisions that make you scratch your head, but come on, it’s not all bad.

AfC

Taming gVim on a GNOME Desktop

I love using GEdit to write text documents like blog posts marked up in Markdown. I’ve been using it extensively to write technical documentation for a while now. It’s a lovely text file editor.

Programming with GEdit is a bit more subject to critique. Sure, source code is text files, but as programmers we expect a fair bit of our editor. I’ve been writing my C code in vi for like 25 years. When I returned to Java after a few years in dot-com land I (with great scepticism) began using Eclipse. IDEs are for wimps, after all. Boy was I wrong about that. Once I got the hang of its demented way of doing things, I was blown away at the acceleration that code completion, hierarchy navigation, and most of all context appropriate popups of JavaDoc. Hard to leave that behind.

Lately, however, I’ve been doing a lot of work with Haskell and JavaScript, and that ain’t happening in Eclipse. Since I use GEdit for so much else, I thought I’d give it a whirl for programming in other-than-Java. Didn’t work out so well. I mean, it’s almost there; I tried a bunch of plugins but it seems a bit of a crap shoot. To make development easier I’d certainly need e.g. ctags, but there was nothing packaged.

You’re probably asking why I’m not content to just use Vim from a terminal; after all, been doing so for years. I’ve begun to have a bit of a backlash against running applications in terminal windows; command lines are for doing Linux things, but once you run an editor or email client or whatever in a terminal then suddenly your productivity on the Desktop goes to hell; the whole premise of Alt+Tab (we won’t even talk about the bizarre GNOME Shell Alt+` business) is switching between applications but having both $ and programs in the same type of window blows that up.

Vim, however, has long had a GUI version called gVim, and when running it shows up as an independent application. So, for the hell of it, I gave it a try.

Cut and Paste

Immediately I went bananas becuase copy and paste didn’t work like they should. Yes this is vi; yank-yank, baby. But as gVim it’s also a GUI, and we’ve all pretty much learnt that if you’ve got a white canvas in front of you, Ctrl+C and Ctrl+V are going to work. So much so that I have gnome-terminal rejigged to to make Ctrl+Shift+C result in SIGINT leaving Ctrl+C for copy. Consistency in user interaction is everything.

There’s an entire page on the Vim Tips Wiki devoted to using y, d, and P to yank or delete then put. No kidding. But just as I was about to give up I found, buried at the bottom, advice to add:

    source $VIMRUNTIME/mswin.vim

to your .vimrc. The script affects some behaviour changes which among other things makes selection, cut, copy, and paste work like a normal GtkTextView widget. Hooray!

As for the rest of the GUI, I’ve gone to a lot of trouble to tame it. You need to make quite a number of changes to gVim’s default GUI settings; it’s all a bit cumbersome and the gVim menus (which at first seem like such a great idea!) don’t actually give you much help. Figuring these customizations out took a lot of wading through the wiki and worse the voluminous internal help documentation to figure any of this out; it’s pretty arcane.

Cursor

In particular, I want an unblinking vertical bar as a cursor (to match the desktop wide setting properly picked up by every other GNOME app, here I had to manually force it):

    set guicursor=a:ver1,a:blinkon0

See the documentation for 'guicursor' for other possibilities.

Mouse pointer

Also for consistency, I needed to get standard behaviour for the mouse pointer (in particular, it’s supposed to be an I-beam when over text; the ability to change pointer depending on which mode you’re on is interesting, but it is jarring when compared to, well, everything else on the Desktop):

    set mouseshape=n:beam,ve:beam,sd:updown

The documentation for 'mouseshape' describes enough permutations to keep even the most discerning customization freak happy.

Window dressing

The remaining settings are certainly personal, but you’ll want to pick a default window size that makes decent use of your screen real estate:

    if has("gui_running")
        set lines=45 columns=95
    endif

You need to guard with that if block because otherwise running vim from your command line will resize your terminal (!) and that’s annoying.

You can set the editor font from the menu, but to make it stick across program invocations you need it in .vimrc as shown here; finally, the 'guioptions' at the end disables tearoff menus (t) and turns off the toolbar (T):

    set guifont=DejaVu\ Sans\ Mono\ 11
    set guioptions-=tT

Syntax colouring

I normally use Vim in a terminal with a black background, but for some reason I don’t much like the colour set chosen. Forcing the change to 'light' makes for a nicely different set, but since I run gVim with a white background to be consistent with other GUI programs, I had to do a bit of tweaking to the colours used for syntax highlighting:

    set background=light
    highlight Constant ctermfg=Blue guifg=DarkBlue
    highlight String ctermfg=Blue cterm=bold guifg=DarkBlue gui=bold
    highlight Comment ctermfg=Grey guifg=DarkGrey

Hopefully that does it. As I said, the new Vim wiki is full of an insane amount of information, but since Vim is so powerful it can, ironically, be hard to find what you need to fine tune things just the way you want them. So if you’re a power Vim or gVim user, why don’t you blog about your .vimrc settings?

Still not sure if using gVim is going to be a good idea; the fact that despite all this hackery the editor canvas is still not a GNOME app with behaviour matching the standards of the entire rest of the Desktop is going to make me crazy. Hopefully I can keep things straight in my head; frankly I’d rather be using GEdit but it is nice to have consistency between using Vim to do sysadmin work and using gVim to write code.

AfC

My sound hardware didn’t vanish, honest

I’ve been having intermittent problems with sound not working. Usually restarting (ie, killing) PulseAudio has done the trick but today it was even worse; the sound hardware mysteriously vanished from the Sound Settings capplet. Bog knows what’s up with that, but buried in “Sound Troubleshooting” I found “Getting ALSA to work after suspend / hibernate” which contains this nugget:

The alsa “force-reload” command will kill all running programs using the sound driver so the driver itself is able to be restarted.

Huh. Didn’t know about that one. But seems reasonable, and sure enough,

$ /sbin/alsa force-reload

did the trick.

That wiki page goes on to detail adding a script to /etc/pm/sleep.d to carry this out after every resume. That seems excessive; I know that sometimes drivers don’t work or hardware doesn’t reset after the computer has been suspended or hibernated, but in my case the behaviour is only intermittent, and seems related to having docked (or not), having used an external USB headphone (or not), and having played something with Flash (which seems to circumvent PulseAudio. Bad). Anyway, one certainly doesn’t want to kill all one’s audio-using programs just because you suspended! But as a workaround for whatever it is that’s wrong today, nice.

AfC

A good GNOME 3 Experience

I’ve been using GNOME 3 full time for over 9 months, and I find it quite usable. I’ve had to learn some new usage patterns, but I don’t see that as a negative. It’s a new piece of software, so I’m doing my best to use it the way it’s designed to be used.

Sure, it’s different than GNOME 2. It’s vastly different. But it is a new UI paradigm. The GNOME 2 experience was over 9 years old, and largely based on the experience inherited from the old Windows 95 muxed with a bit of CDE. There were so many things that the GNOME hackers wanted to do — and lots of things all the UI studies said needed changing — that the old pattern simply couldn’t support.

Still, a lot of people are upset. Surprise. Most recently it’s been people running Debian Testing who just recently found that their distro has migrated its packages from GNOME 2.32 to GNOME 3.x. Distros like Ubuntu have been shipping GNOME 2.32 for ages; but it has been well over 2 years since anyone actually worked on that code. It’s wonderful that nothing has changed for you in all that time [a true Debian Stable experience!] but I think it’s a bit odd not to expect that something that was widely advertised as being such a different user experience is … different.

What I find annoying about these conversations is that if they had gone and bought an Apple laptop with Mac OS X on it they would be perfectly reasonably working through learning how to use a new Desktop and not complaining about it at all. But here we are admonishing the GNOME hackers had the temerity to do something new and different.

Installing

I went to some trouble to run GNOME 3 on Ubuntu Linux during the Natty cycle; that was a bit of work but I needed to be current; now with Oneiric things are mostly up to date. GNOME 3.0 was indeed a bit of a mess, but then so was GNOME 2.0. The recently released 3.2 is a big improvement. And it looks like the list of things that seem targeted to 3.4 will further improve things.

I’m now running GNOME 3 on a freshly built Ubuntu Oneiric system; I just did a “command line” install of Ubuntu and then installed gdm, gnome-shell, xserver-xorg and friends. Working great, and not having installed gnome-desktop saved me a huge amount of baggage. Of course a normal Oneiric desktop install and then similarly installing and switching to gnome-shell would work fine too; either way you probably want to enable the ppa:gnome3-team/gnome3 PPA.

Launchers

One thing I do recommend is mapping (say) CapsLock as an additional “Hyper” and then Caps + F1 .. Caps + F12 as launchers. I have epiphany browser on F1, evolution on F2, my IRC client on F3 and so on. Setting up Caps + A as to do gnome-terminal --window means you can pop a term easily from anywhere. You do the mapping in:

    System Settings → Keyboard Layout → Layout tab → Options...

and can set up launchers via:

    System Settings → Keyboard → Shortcuts tab → "Custom Shortcuts" → `[+]` button

(you’d think that’d all just be in one capplet, but anyway)

Not that my choices matter, per se, but to gives you an idea:

AcceleratorLaunchesDescription
Caps + F1 epiphany Web browser (primary)
Caps + F2 evolution Email mail
Caps + F3 pidgin IRC client
Caps + F4 empathy Jabber client
Caps + F5 firefox Web browser (alternate)
Caps + F6 shotwell Photo manager
Caps + F7 slashtime Timezone utility
Caps + F8 rhythmbox Music player
Caps + F9 eclipse Java IDE
Caps + F10 devhelp GTK documentation
Caps + F11 gucharmap Unicode character picker
Caps + F12 gedit Text editor
Caps + Z gnome-terminal --window New terminal window

That means I only use the Overview’s lookup mechanism (ie typing Win, T, R, A… in this case looking for the Project Hamster time tracker) for outlying applications. The rest of the time it’s Caps + F12 and bang, I’ve got GEdit in front of me.

Of course you can also set up the things you use the most on the “Dash” (I think that’s what they call it) as favourites. I’ve actually stopped doing that (I gather the original design didn’t have favourites at all); I prefer to have it as an alternative view of things that are actually running.

Extensions

People love plugin architectures, but they’re quite the anti-pattern; over and above the software maintenance headache (evolving upstream constantly breaks APIs used by plugins, for one example; the nightmare of packaging plugins safely being another) before long you get people installing things with contradictory behaviour and which completely trash the whole experience that your program was designed to have in the first place.

Case in point is that it didn’t take long after people discovered how to use the extension mechanism built into gnome-shell for people to start using it to implement … GNOME 2. Gawd.

Seeking that certainly is not my recommendation; as I wrote above the point of GNOME 3 and it’s new shell is to enable a new mode of interaction. Still, everyone has got their itches and annoyances, and so for my friends who can’t live without their GNOME 2 features, I thought I’d point out a few things.

There are a collections of GNOME Shell Extensions some of which appear to be packaged, i.e. gnome-shell-extensions-drive-menu for an plugin which gives you some kind of menu when removable devices are inserted. I’m not quite sure what the point of that is; the shell already puts something in the tray when you’ve got removable media. Whatever floats your boat, I guess. Out in the wild are a bunch more. The charmingly named GNOME Shell Frippery extensions by Ron Yorston has a bunch of plugins to recreate GNOME 2 features. Most are things I wouldn’t touch with a ten-foot pole (a bottom panel? Who needs it? Yo, hit the Win key to activate the Overview and you see everything!).

My personal itch was wanting to have 4 fixed workspaces. The “Auto Move Workspaces” plugin from gnome-shell-extensions was close (and would be interesting if its experience and UI were properly integrated into the primary shell experience), but the “Static Workspaces” plugin from gnome-shell-frippery did exactly the trick. Now I have four fixed workspaces and I can get to them with Caps + 1 .. Caps + 4. Hurrah.

You install the plugin by dropping the Static_Workspaces@rmy.pobox.com/ directory into ~/.local/share/gnome-shell/extensions/, then restarting the Shell via Alt + F2, R, and then firing up gnome-tweak-tool and activating the extension:

    Advanced Settings → Shell Extension tab → switch "Static Workspaces Extension" to "On"

Hopefully someone will Debian package gnome-shell-frippery soon.

Not quite properly integrated

Having to create custom launchers and fiddle around with plugins just to get things working? “Properly integrated” this ain’t, and that’s my fault. I respect the team hacking on GNOME 3, and I know they’re working hard to create a solid experience. I feel dirty having to poke and tear their work apart. Hopefully over the next few release cycles things like this will be pulled into the core and given the polish and refined experience that have always been what we’ve tried to achieve in GNOME. What would be really brilliant, though, would be a way to capture and export these customizations. Especially launchers; setting that up on new machines is a pain and it’d be lovely to be able to make it happen via a package. Hm.

AfC

Fix your icons package

Updating today, suddenly a whole bunch of icons are broken; GNOME shell was presenting everything with a generic application diamond as its icon. Bah.

I noticed gnome-icon-theme was one of the packages that bumped. It turns out that package is now only a limited subset of the GNOME icon set and that you have to install gnome-icon-theme-full to get the icons you actually need. Bah², but now everything is back the way it should be.

AfC

Force Pidgin online

The Network Mananger 0.9 series has made some changes which break current Pidgin. After I installed network-manager 0.8.999 Pidgin won’t connect, stalling with “waiting for network connection”.

Turns out there is a workaround in Pidgin: you can force it to ignore what it thinks network availability by running it as:

$ pidgin -f

There’s no GUI way in gnome-shell to edit a launcher at the moment, fine; The old “edit menus” trick didn’t seem to work either. So to do that manually:

$ cp /usr/share/applications/pidgin.desktop .local/share/applications/
$ vi .local/share/applications/pidgin.desktop

And change the Exec line to:

Exec=pidgin -f

It won’t take effect until the desktop recaches things. Reload gnome-shell by typing “r” in the Alt+F2 run dialog and you’ll be on your way.

I’m sure upstream will catch up with the Network Manager changes in due course but I can live without network availability detection for now and this gets me back online.

I’ve been using Empathy for instant messaging for a long time, but I still love Pidgin for IRC. Go figure. So two clients it is.

AfC

Lovely Inconsolata

Federico writes that he’s recently discovered Raph Levien’s Inconsolata font and really liking it.

I likewise discovered Inconsolata not too long ago (it was packaged in Gentoo and I was really pleased to discover it also available in Debian), and have been using it as the constant-width font in Quill and Parchment for program listings in technical writing.

Parchment output showing Inconsolata font used for program code

We all tend to get obsessive about things we like, and so of course I tried it as a terminal console font. Interestingly, after a brief consideration, I decided not to use it for terminals and gedit and such. Deja Vu Sans Mono is still the king for that, especially if you’re using Deja Vu Sans and Deja Vu Serif for the rest of your UI; it means that the visual consistency across your desktop is really awesome.

gnome-apperance-properties Fonts tab, picking Deja Vu fonts

Inconsolata doesn’t have anything even remotely close to the kind of Unicode coverage you need in your full-time constant-width font, and when fontconfig does a fallback it looks awful because Inconsolata’s metrics are so different from others. That’s all ok; Inconsolata is meant for program listings, and looks incredible on paper.

Anyway, Federico noted that bold didn’t work when specified as a FontDescription, it doesn’t come up bold me either when I tried to do so via a bold PangoAttribute. But if you use Wouter’s Specimen, it shows up fine (on an Ubuntu box, anyway):

gnome-specimen showing Inconsolata font medium and bold

So there’s a bug in our stack somewhere.

AfC

Update

Or not. I just reread the JavaDoc for the FontDescription constructor, and lo and behold relearned what I wrote there in the first place. To get bold Inconsolata you just need to use a ',' in the right place:

    desc = new FontDescription("Inconsolata, Bold 8.0");
    ...

and my Cairo drawing code on screen in a XlibSurface shows bold. Great.

But nothing is ever simple. I ran the same drawing code out through to a PdfSurface, and no bold. What the hell? There’s a bug in our stack somewhere. {sigh}

In my original post, I misattributed Specimen… it’s written by our very excellent Wouter Bolsterlee, uws on IRC. Sorry!

Get your icons back

We recently upgraded a number of systems, and after a few days the (previously happy GNOME users) started to notice the dialog buttons were all lacking their icons. How did that break? At first I assumed it was a bug in Canonical’s then pending Linux release, “Karmic”. But the problem didn’t go away, and suddenly I noticed a fair bit of email and bug traffic about the issue.

It turns out that someone removed the icons on purpose!

It didn’t attract that much attention at the time, but this setting was changed by the small group who maintain GNOME Control Center. They claimed that text-only interfaces were better. Hm. That doesn’t seem right, but interesting choice on their part. Fine. So you start hunting around in System -> Preferences to find the place where you can return your GNOME desktop to normal.

There isn’t one.

The usability of icons

In the GNOME community, we’ve gone to immense effort over the years to get people to use the proper stock GTK icons in menus and buttons so that the user experience is consistent across applications. They’re a significant cue that aids navigation. Meanwhile non-GNOME applications poorly ported from other platforms often violate this consistency (Eclipse {cough}). So suddenly lacking icons the entire desktop looked ghetto.

The whole debate about what the user experience should be was an interesting one, but it seems a user experience change of this magnitude qualifies as just the sort of thing we don’t do to the huge communities of people using our Desktop during a stable release series. We have GTK 3.0 and “GNOME 3.0″ coming up, and surely those would have been the appropriate contexts to propose such change, and the right place to trial landing it.

The part that really puzzles me, though, is that after the people who made this change were (politely) asked if they could point to the usability research that makes them think that text only menus are better, they (politely) replied with reference to a respected source in HMI design, Jared Spool. Reading that page it indeed says that text only is better than icon only. But right before that, however, he indicates that the combination of icons-and-text is more usable than text-only, with the further emphasis being that consistent positioning (ordering in menus) of those illustrative aides being what really what matters. Which seems to make it strange that text-only was just rammed down users’ throats.

Find out what’s broken and fix it

That they changed something is NOT the issue; at the end of the day it’s the people who do the work and write the software who set the agenda. But something this widespread seems like it ought to have been discussed on the usability and accessibility lists. And that’s the problem; there’s no mechanism requiring that.

It’s not the GNOME Control Center hacker’s fault that this became such a sore point for the rest of us; they were in a position to change something they wanted to change and so they did so. That’s just another day in Open Source land. But in GNOME there’s nothing that enforces the GNOME Human Interface Guidelnes. If a change like this had been proposed as a change to the HIG and if following the HIG was mandatory then clearly people would have had a good focused discussion about user experience, we could have come to a consensus (or “Usability Team” could have made a decision), the HIG documents would have been patched as a part of that, and then we could all get with the program.

The GNOME “Release Team” puts new module proposals through hell to be accepted as a part of GNOME, with endless discussions about what the user experience will be. Libraries underneath the desktop work incredibly hard to maintain API and ABI compatibility across releases. We try to remember that corporate IT departments just want gentle improvement between their upgrade decisions, rather than having to deal with a wrecking ball every six months. So we all know the importance of not screwing the user around.

But unless we find a way to apply the same rigour to maintaining UI standards like we do to managing the internal technical aspects of our platform, it seems we’re doomed to keep breaking the consistency of our users’ experience (and more to the point, jerking the chain of all the people who work hard to install and support the systems that our users run). How to do that while still enabling people to innovate is the hard part, but surely requiring people to follow the HIG and making that document the heart of user experience debate would be a step in the right direction.

Meanwhile, lets fix your desktop:

Workaround: users

The Control Center hackers removed the “Interface” tab from gnome-appearance-properties which is a shame since it would have been a lovely place for the user to say whether or not they wish icons in their menus and buttons.

It was pointed out that this is all still controllable by the user… by changing GConf settings. I think most of us would agree that is the very definition of what normal users aren’t expected to be doing.

The GConf keys are:

/desktop/gnome/interface/buttons_have_icons

and

/desktop/gnome/interface/menus_have_icons

So to fix your desktop to be consistent with previous GNOME releases, you need to run:

$ gconftool-2 --type bool --set /desktop/gnome/interface/buttons_have_icons true
$ gconftool-2 --type bool --set /desktop/gnome/interface/menus_have_icons true

You’ll definitely need to repair your system like this if you’re working in applications such as Inkscape that have huge numbers of items in their menus; they become really difficult to tell apart if you don’t have the pictorial aides to help you identify the action you’re looking for.

Workaround: code

It turns out GtkImageMenuItem has a new property "always-show-image" for really important icons, ie where “the menu item would be useless or hard to use without it”. The idea is that application programmers using GTK manually need to call this for all the menu items where the icons is really important and you actually want the icon shown in the menu item (Given that you have to go some trouble to construct a GtkImageMenuItem rather than just a normal GtkMenuItem, I would have thought that that emphasis would have been a given. Alas). I just added a setter to java-gnome:

    quit = new ImageMenuItem(Stock.QUIT);
    quit.setAlwaysShowImage(true);

There are also GtkSettings "gtk-menu-images" and "gtk-button-images" which can be used to set the property globally in an application programatically or via .gtkrc:

    settings.setMenuImages(true);
    settings.setButtonImages(true);

Judging by the howls of protest, not too many people had noticed the importance of these properties, and so no one was setting it in their code. Assuming that the new default is likely to stand in the GNOME >= 2.28 era, then indeed we’ll all have to be doing this a lot.

Setting defaults

Thinking about this from the perspective of a bindings hacker and sometimes application developer, it all makes me realize the importance of exposing setters for properties, and calling setters even when the value you are setting is the default. It’s tempting to think “oh, I don’t need to call that method, it’s set by default”, but as episodes like this demonstrate, relying on defaults isn’t very reliable.

AfC

3 mobile broadband on Linux

I had to get a mobile broadband gizmo this week. It’s something I’ve been avoiding (not having internet access while sitting at a cafe by the beach is a feature, not a bug), but I need it for a current client. After advice from one of my colleagues that “3” (one of the carriers here and the first that did 3G digital phones in Australia) was reliable and, more importantly, that their device worked with Linux, I went and picked one up along with a prepay SIM.

3′s offering has two devices at the same price right now; the Huawei E160G and the ZTE MF627. I thought my friend had the latter and so bought that one. Big mistake.

E160G
Bit older
works great
MF627
Brand new
doesn’t work

Do not get the ZTE MF627 device if running Linux. Stay away from it. Even after trying the usb_modeswitch hassles, it still does not present as the device as a GSM modem like it is supposed to. Tried it on two separate laptops; one running Gentoo, the other with Ubuntu’s “J” version on it. Spent the better part of a day researching and debugging the issue, but no joy on either. One person in London claims to have a similar device working, but comparing their lsusb and dmesg output, I’m not convinced the electronics in the one available here were the same; after doing a mode switch the miniSD adapter presents, but not the modem. Anyway, sure, maybe someday someone will figure out how to make it work here, but that’s not right now.

Even worse, people writing in places like Whirlpool cite chronic quality problems with ZTE devices. Clearly this is something to avoid.

I took the thing back to the store the next day and finally managed to get a refund which I promptly used to buy their other device (why they couldn’t just do an exchange was as puzzling to the poor guy in the store as it was to me. Whatever; they kept him on the phone for almost an hour while the corporate drones he had to call for permission made up their minds that it was ok to give me my money back).

So home I went with a Huawei E160G (which is what Peter had) and it worked perfectly, right out of the box, literally. Plugged it in, device properly recognized by USB subsystem and, after adding a “mobile broadband” connection with NetworkManager 0.7, it immediately started working. Pretty amazing.

You need to have the PPP stack built into your kernel and pppd installed (once upon a time we all had that, but most of us haven’t needed to do point-to-point over a dialup modem for years, so if you’re running a modern system with a custom Linux kernel you might not have it). The relevant kernel modules are “ppp_async“, “usbserial“, and “option“.

So a big hooray to the NetworkManager team and all the people working on the drivers that made this magic work. That NetworkManager seamlessly handles all the PPP configuration and dialing is brilliant.

mobile broadband connection in NetworkManager
Neat connection active icon.

And as for the lovely staff in the store, don’t let them tell you that their service doesn’t work on Linux — but do get a device that does.

AfC