Friendly Project Names in Komodo Edit

For several years now, Eclipse has been my primary IDE. I’ve used it to write in a number of languages on a number of platforms and was more or less happy with it. In the last six months or so, the scales of justice began to tip away from more and towards less until a couple of months ago when I finally hit my breaking point. I decided that I’d had enough of trying to dedicate enough system resources to keep Eclipse happy. I’d had enough of trying to keep my installs on several machines using several operating systems synced up properly. I felt like Eclipse was taking over my life rather than making it easy.

I started looking around with only a couple of key requirements:

  1. Responsive. Not necessarily fast, just responsive.
  2. Cross platform. I’m cross-platform and I need my key software to be cross-platform too.
  3. Power user friendly. By that, mostly I mean a rich set of keyboard shortcuts and snippets.
  4. Free-ish. I’m happy to pay for good software, but I’m not willing to plunk down hundreds of dollars if there are almost-as-good options.

After trying a number of IDEs and text editors, I finally settled on Komodo Edit. It’s a text editor that’s lightweight and snappy the way that a text editor should be, but it has just enough IDE-like features to meet my minimal needs. It met all of my needs.

For me, one of the huge tipping points was that it is a project-based editor. I loved that particular metaphor once I started using Eclipse and it’s not something you see in a lot of text editors so I was happy to get that support. What I didn’t like was that, unlike Eclipse, I couldn’t enter a “friendly” name for my projects. Eclipse has its .project files and Komodo Edit has a projectname.kpf file, but in the latter there was no way to set a nice, human name for each project. Cracking open the .kpf project file showed me that it’s just an XML config file and that there’s a name attribute on the project root element, but changing that changed nothing.

I asked about this on the forum and one of the developers suggested that I enter an enhancement request. I did and, to my surprise, a patch was made available the same day – within an hour, if I recall correctly. Since doing so, the change has been rolled into the latest version (v5.1).

To give your Komodo Edit friendly project names that will show up in the project explorer:

  1. Create a project (if one isn’t already created).
  2. Open the .kpf file in a text editor.
  3. Set the value of the name attribute to the friendly value of your choice.
  4. Save, close and restart Komodo Edit.

Here’s what one of my .kpf files (scratchpad.kpf) looks like:

<?xml version="1.0" encoding="UTF-8"?>
<!-- Komodo Project File - DO NOT EDIT -->
<project id="714c52ec-687a-0241-b5ef-eb09952b79d5" kpf_version="4" name="Scratchpad">
<preference-set idref="714c52ec-687a-0241-b5ef-eb09952b79d5">
  <boolean id="import_live">1</boolean>

Clear All Growl Notifications

When IM errors occur, I have Adium’s Growl alerts set to remain onscreen until I dismiss them. Unfortunately, sometimes I accidentally leave Adium online when I go to work. When I get back home, I have a huge number of notifications waiting to tell me that my user for service X is logged in from multiple locations.

As it turns out, there’s a simple way to close all notifications at once—just hold the Option key before clicking on the first notification.

Take that AOLSystemMessage guy.

Session Interaction with Quicksilver

Although it’s true that, on the whole, I prefer the OS X environment to that of the Ubuntu Linux environment I’ve been using at work for the last few months, the degree of that preference is not as high as I would have ever thought. Nonetheless, I have to confess that I have a tremendous preference for Gnome Do over Quicksilver for OS X. I know, that borders on blasphemy, right?

I prefer Do for a number of reasons that are beyond the intent of this post, but one reason is that I’ve been spoiled by having the ability to logout, restart, shutdown and otherwise interact with my user session. My inability to do so with Quicksilver has begun to frustrate me lately and tonight I finally figured out that Quicksilver has the same capability. Unfortunately, that capability is tucked away and obscured so that it’s not immediately obvious. Session interaction, as well as a few other nice tools, is tucked away in the Extra Scripts plugin.

Another of my frustrations with Quicksilver is the complexity of the interface, but I wanted to know what was in included with this plugin, so I dug it up in Finder. Since the plugin is really just a collection of shell scripts, it’s pretty easy to see what’s in there. Here are some of the highlights:

  • Get your current IP addresses
  • Eject and close the disk tray
  • Logout of your current session
  • Lock the screen
  • Switch to root
  • Put the computer to sleep
  • Shutdown or restart the system
  • Control the system volume
  • Empty the trash

More is available, but these are the functions that I thought were the most interesting or potentially useful to me. I can’t find a way to see a list of functions available in the Quicksilver UI, but if you’re interested you can see what’s included using Finder:

  1. Open the Quicksilver preferences
  2. Go to the Plug-ins “tab”
  3. Click the gear icon at the bottom of the window
  4. Select Show Plug-ins Folder
  5. Right click on the Extra Scripts.qsplugin “file” and select Show Package Contents
  6. Open the Resources/ExtraScripts directory
  7. Explore the subdirectories

Most of the scripts are pretty descriptively named. It should be pretty apparent what functionality they provide.

Sony Releases New Stupid Piece of Shit That Doesn’t Fucking Work

I can’t wait to get home and spend my whole fucking night trying to figure the goddamn thing out.

I heart The Onion. I’ve watched this about 30 times today and it just doesn’t get old. Just in case the title somehow isn’t clear, this is NSFW. At least not without headphones.

When SSH Public Key Authentication Fails

I’m no Sys Admin, but I connect to enough Unix machines often enough that enabling public key authentication is a real time saver. For those that may not know, public key authentication allows a user to login to another machine via SSH without a password. I’ve written a bit more about the technique itself in my archive. The other day, in the course of setting up authentication for several machines at work, I noticed that it worked for most of the machines but failed for a few others. After spending a little over an hour checking and double checking the files in my ~/.ssh directory, I spent another hour comparing files on the machines that weren’t working with the ones that were. Everything was precisely the same.

Except that it wasn’t. Evidently I neglected to read my own earlier post, specifically step 5. I had no idea that permissions were such a hot button, but it makes sense. The permissions on my ~/.ssh/authorized_keys file were 664. The boxes wouldn’t let me login because the file was writeable by someone other than me (at least in principle). As soon as I changed the permissions to 644, I was able to connect just fine.

Of course, I realize that this is by design and a very good thing, but I wasn’t expecting it so I stumbled over it.