Note: I have provided .patch files, etc. at the bottom of the post for those who, like me, are a bit lazy.

What is Terminal Nirvana?

As a developer, Terminal is one of my best friends. Maybe you can relate. I have constantly been in search of the ultimate Terminal configuration, and it has ever eluded me… until now.

But what is Terminal Nirvana? Here are my criteria:

1. I want the Home / End keys to move the cursor to the front / end of the line. I grew up on Windows, and I like the keys to function this way. To me, it just makes sense. Unfortunately, KeyFixer doesn’t work in Terminal (but I highly recommend it for changing the behavior in most other apps!).
2. I don’t want Home / End to behave differently when I am in a screen session. I use screen all the time, and Home / End need to behave consistently.
3. I don’t want Home / End to do unexpected things in VIM – ever. Pressing Home / End in VIM should, at the very least, not do weird things like delete lines, whether I am in a screen session or not.
4. I want my terminal window available at all times. With as much as I use the terminal, opening Terminal.app all the time feels wasteful. There should be a better way. This is where SIMBL and Visor come in.
5. I don’t want it to show up in the Dock, or in my Command + Tab list. As useful as Terminal is, there are a lot of other useful applications around, and I use a lot of them. Since I always want Terminal open anyway, it is annoying to constantly avoid / ignore / tab over it when I am using Command + Tab to switch to another running application. Oh, and it should stay away from my Dock, too.
6. I want good, configurable colors in my shell. Fortunately, Visor takes care of this one by including TerminalColours as part of the package, so you get this one “for free.”

Sound like a tall order? It took me a few hours crawling around the web and experimenting to come up with a good solution, but I managed it in the end. Hopefully my experience can help save a few people some time in the future.

This is how I did it.
Read more…

CouchDB

If you don’t know what CouchDB is, well, there are a lot of other places where you can find that out better than I could explain it.  Google it, my friends, google it.

Harder than it should be

Installing CouchDB with MacPorts should really be as easy as typing “sudo port install couchdb”.  Unfortunately, at least as of the date this was posted, it is not that easy.  The problem is that CouchDB is written in erlang, and erlang has been updated in macports to be a newer version than CouchDB 0.11 (the current stable version) supports.

I have written a post previous to this one about how to downgrade that.  Please read that and do it before proceeding with these instructions.  If you don’t — it just won’t work.

Read more…

The problem

I’ve been using couchdb a lot lately, and I really like it; unfortunately, someone isn’t really on the ball in the MacPorts world.  They upgraded erlang in macports to default to R14A, which breaks backwards compatibility for a *lot* of other ports, including couchdb.  We’re going to change that so that we get a version compatible with couchdb.

Read more…

After recently answering a question on Stackoverflow using Boost.Preprocessor, i wondered how the sequences, e.g. SUM_MACRO((1)(2)(3)), actually work.

Read more…

Ahh, the great debate; which is the best text editor of them all?  I have used many of them, but I keep falling back to what for me is the classic one: VIM.

Second to VIM, however, I have always been very impressed with TextMate. There are features in TextMate that just make me happy.  My favorate is the “Go to file…” option (Command-T).  For those of you who aren’t familiar with it, when you press Command-T in TextMate a little popup window appears.  You type part of the filename that you are looking for and TextMate displays all files in your project that contain that string.

Read more…

A while ago, i inquired on StackOverflow if anybody knew about meta-programming techniques to ease bridging between Objective-C and C++:

In a pure C++ world we can generate interfacing or glue code between different components or interfaces at compile time, using a combination of template-based compile-time and runtime-techniques (to e.g. mostly automatically marshall to/from calls using legacy types).

When having to interface C++ applications with Objective-C/Cocoa for GUI, system integration or IPC though, things become harder due to the less strict typing – yet often not more then a flat repetitive interface layer is needed: thin bridging delegates have to be defined or conversion code to language bridging calls has to be written.

If you have to deal with interfaces of non-trivial size and want to avoid script-based code generation this quickly becomes cumbersome and is just a pain every time refactorings have to take place. Using a combination of (template) metaprogramming and the Objective-C runtime library, it should be possible to reduce the amount of code considerably…

As i didn’t get any answers that were satisfactory for me, i started on a prototype.
Read more…

Most who are deep in the plugin world already know this, but I will repeat it quickly for those who only dabble:

Firefox 3.6 has removed support for XPCOM plugins.

This means that if you use XPCOM for your javascript interface (i.e. you have an IDL file on your npapi plugin, you us nsScriptablePeer, etc) your plugin will no longer be able to communicate with javascript in Firefox 3.6.

Thus I repeat advice that I have given in the past: Never, never, *never*, *ever* use XPCOM for your javascript interface in your plugin.

There might conceivably be reasons to use other aspects of XPCOM in a plugin, that might even work in other browsers. At present, I don’t know of them. Please enlighten me if there are (cookies?).

Oh, yeah, and FireBreath now has linux and mac support (experimental) as well as windows support (stable). Come join the fun. http://firebreath.googlecode.com

Thank you.

The Problem:

I’ll be up-front about something here; I don’t particularly like ActiveX.  I understand a lot of the reasons for creating it, and I won’t go so far as to claim that it shouldn’t exist or anything like that; in fact, it does very well for certain types of things.  The main thing I don’t like about it is the complexity; it’s not something that you just pick up and start using one day.  You have to do a lot of research to understand what is happening, and though I’ve been working on ActiveX Controls hosted in Internet Explorer for over a year now, there is still a lot I don’t understand about what is really happening under the covers.

Because of this, I am a big fan of NPAPI.  I think it’s a great technology.  It’s simple.  It’s straightforward.  It provides an interface for one purpose, and that is to allow 3rd party developers to write browser plugins.  It’s great.  But, there is a problem: in my world, you can’t just say “I like Firefox better than IE, so I’m not going to support IE.”  Why?  I will make no claims here about security, usability, viability, or even disability of any browsers.  I will simply refer to one statistic: according to the w3schools browser statistics, Internet Explorer accounted for over 25% of the total web traffic every month last year.

So we find the classic challenge of all browser plugin developers: Internet Explorer only supports ActiveX controls, other browsers support NPAPI, and a plugin written for one isn’t neccesarily going to be easy to just port to the other.  Thus was born FireBreath, in an attempt to solve this issue.  Today, however, I want to address only one piece of the solution that we use in FireBreath:  How to create a scripting interface that will be “write once, run anywhere” on web browsers.

Read more…

Introduction

Ever since I started this series of posts on NPAPI and plugins, I have started receiving occasional emails requesting additional help with aspects of NPAPI that are particularly confusing.  With full-time work, FireBreath development, and a 6 month old baby to take care of, I often don’t have as much time as I’d like to give these questions the attention that they deserve.  One that I got today struck me as being a particularly confusing bit for many people, and one that I hope I can answer briefly, so I’m going to give it a shot.  I’m still kinda hoping to get to the point that I can explain smaller bits with shorter posts, which will make it easier for me to post new material more often.

Read more…

The Firebreath project

It’s been awhile since my last post!  Rest assured, that isn’t because I have lost interest, or because there was nothing to write about; rather, I was occupied with what I considered to be more important things.  If you’re reading this, you likely have already read my previous post, “Call for plugin Developers.”  If you haven’t, you might want to glance over it so that you know what I’m talking about =]

Firebreath has been sponsored by PacketPass, Inc.  I don’t have a web address for them, but I’ll post one later if they want me to do so.  The good news about that is that it means that unlike the vast majority of new open source projects, development of Firebreath is not going to halt before there is at least some sort of a usable project.

Read more…