Ted’s Rants and Raves by Ted M. Young

The Silicon Valley Linux Users Group (SVLUG) is having another InstallFest in San Mateo, CA (2800 Campus Drive), this Saturday (March 1st) as part of the larger Bay Area InstallFest for Schools. Other areas include San Francisco, Berkeley, and Novato. The goal is to donate 500 computers, with Ubuntu pre-installed, to Bay Area schools. Here’s more information: http://www.untangle.com/installfest.

Sounds like fun, especially with free pizza and schwag from the Mozzilla Foundation!

When I’m editing a file, I like to know immediately whether I’ve checked it out for editing, or if it’s in read-only mode. Sure, you can look at the at the editor tab and see if there’s a little tiny lock icon on the editor tab (when you’re running at 1920×1200 on a laptop screen, tiny is really tiny), or maybe the color of the tab text is black. However, I prefer a much more obvious way: making the background of the editor a color other than the standard white. Note: if you have colors set up such that the background isn’t white, you can still use this tip, just use a different color than in my example.

So, an editable file looks like this (white background):

And a read-only file looks like this (a slightly blue-tinted background):

I find that the slight color change is obvious enough to let me know I’m looking at a read-only file at first glance, yet subtle enough not to get in the way of reading the code.

Changing It

I recommend opening up a read-only file before adjusting the settings so that you can see how it looks while you’re adjusting the colors (see step 6 below).

1. Open up the IDE Settings (Ctrl+Alt+S for me) and select “Colors and Fonts”:

2. If the General tab isn’t selected, click on it. Underneath you’ll see a list of items: select “Background in readonly files” (pointed to by the green arrow). Don’t confuse this entry with the “Readonly fragment background” (pointed to by the red arrow).

3. If the Background checkbox isn’t selected, then select it.

4. Right-click on one of the gray boxes on the right-side to customize the color. You’ll see this dialog show up:

5. Adjust the color to something subtle: keep in mind that you want a very light (i.e., low saturation) color. The little swatch that you see in the color selector is misleading: you’ll think the color is light enough, but it’ll end up being darker than you expect when it’s the background color for the whole editor. I suggest using the RGB values above (R=247, G=255, B=255), but feel free to experiment. After you’ve “mixed” your color, click the OK button and you’ll now see your color as one of the “customized colors” on the right side of the pre-selected color palette:

6. After you click on your new color, you can hit the Apply button and, if the current file showing in the editor is read-only, you’ll immediately see the background color change. Click the OK button once you’re done and you’re all set!

As I mentioned in my first IntelliJ IDEA Tip post, I’ll be talking about the many plugins that I use—I’m something of a plugin maniac. Hopefully you’ll give them a try and find them as useful as I do.

The Describe Key Plugin

Written by Vincent Mallet, today’s plugin is one that does one little thing, but does it extremely well: tell you what a specific keystroke or key sequence does.

You can bring up the Describe Key plugin through the menu:

Or use its default shortcut: Ctrl+Alt+K. When you bring it up, you’ll see the dialog:

And you can start trying out keystrokes, in this case I hit Ctrl+Shift+S, the default shortcut for Structural Search. This dialog should look familiar, it’s pretty much the same one that’s used in the Keymap settings page. A nice addition is the ability to browse and search all actions that you could attach to a shortcut by clicking on the Browse button:

While you could do this from IDEA’s built-in Keymaps settings page, using the Describe Key plugin is a much quicker way to do it. Thanks Vince for a nice little plugin!

IntelliJ IDEA continues to surprise me…the other day I was looking for a class in a package, but I wasn’t sure if the package was task, tasks, or something else, but I knew it started with the letter t. Lo and behold, IDEA’s Goto Class (typically the Ctrl+N shortcut) will help you with this problem:

Here you can see that I’ve typed a letter, t, that I know is the start of the package name (which could be the first name, or the fifth dotted name) and then an asterisk (the wildcard) and then Task, because I know the class ends with Task. And IDEA will show you all of the classes that match. You don’t need the wildcard for the package name, the dot makes the wildcard implicit, i.e., if you use t.SomeClass, it knows that you want to find a class named SomeClass that’s in a package where the last part of the package name starts with the letter t.

Just a quick tip for today: when using version control, there are times when I want to switch to a set of files that are open in another changelist (what IDEA calls a list of files that would be submitted/checked-in at the same time). However, instead of clicking on each file in the list, you can right-click on the changelist title and then click on Jump to Source:

IDEA will then open all of the files at once. If you don’t want all of the files opened, you can multi-select the ones you want and then do the right-click -> Jump to Source (or just hit F4, the default shortcut key).

IntelliJ IDEA 7 (from JetBrains) is my preferred development environment for Java (and Groovy as well). Even though I’ve been using it since it first came out many years ago, I still find features that I hadn’t noticed or different ways of using features that are well-known. There are also a number of high-quality plug-ins that deserve attention as well. This is the first in a series of such tips. I’d certainly welcome any tips that you might have.

Why Quick Lists?

As time goes by, the menus in IDEA get longer, with more nesting, especially if you have plug-ins. For example, the right-click menu on a file — at least in my environment — looks like this (with the Perforce nested menu showing as well):

Since Perforce is the version-control system in use at my company (Guidewire Software), I tend to use the Perforce operations quite a bit (no surprise there). However, having to navigate the long menus is annoying and, when my mouse isn’t cooperating, really frustrating. The first thing that I did was to assign keyboard shortcuts to my common actions: add, open for edit, submit file, etc. This works well for the more frequently used functions, but for those that I don’t use often enough to deserve shortcuts (or if they did, I’d forget them when I needed to use them), it’d be nice if there was a way to create a menu that had all of the Perforce functions that I need, without having to traverse down long, nested menus. Enter the Quick Lists.

You can see how this is much better than the long menus, plus it’s easy to tie it to a keyboard shortcut: I use Ctrl+Shift+P (for Perforce).

Creating A Quick List

Go to the menu File -> Settings -> Keymaps

You’ll see the Keymaps dialog, so click on the Quick lists tab:

And then click on the Add button to add a new Quick List. Enter a short name and a description, though the description is optional.

Once you’ve named it, you can now start adding action items to your Quick List. On the left are all of the available actions and you simply select each one and add it to the right column. Since I’m creating a Perforce Quick List, I’ve navigated to the Perforce part of the tree, under Version Control.

Now that the Quick List has been created, I can assign a shortcut to it. Click on the Keymaps tab and now you’ll see the Perforce Quick List:

Select Perforce, and then define a keyboard (or mouse) shortcut on the right side of the dialog. Click OK and you’re done.

Now whenever you want quick access to the commonly used actions, you can use the QuickList.