In setting up this site, I accidentally forgot to allow anonymous users to vote on my posts. Sorry about that. It's fixed.
But I did uncover a bug in the "Fivestar" module that I was using for voting.
Even though I told it to put the voting widget above the text of the node, it ended up putting it below for anonymous users. I fixed the bug. You can read all about it on my bug post, or download the patch from me.
The patch applies against fivestar 5.x-1.12.

Update

This was applied to the CVS in upstream, in both the drupal5 and drupal6 branches. The next release of the fivestar module will likely have it.

Sure, GUIs are nice and all, but I'm more of a command-line user. But does that mean that I have to cross the rubicon into command-line land and never come back? I should hope not!

One thing that happens with me a lot is that I'm typing on my terminal, and I find I want to open that spreadsheet document. At this point, I am faced with a choice. I can either strain my brain to remember what command-line options it takes to start the OpenOffice program correctly (was that ooffice -calc? Or openoffice -calc? Or soffice -calc? Or maybe openoffice-calc...). If I decide not to go that route, I could always open up a nautilus window at my home directory, and then navigate down whatever thorny pathways I've taken to reach the little crevasse in my filesystem that I'm working in. Sure, I did it once and I could do it again, but I've already got a command prompt right there!

Mac OS X offers a program called "open", where you type open <filename> and you get the same behavior you would've gotten if you'd double-clicked it in the finder. Excellent! That way, you don't need to even remember which application you have set as your preference for opening pdfs.

I set out to implement a similar feature for users of Gnome. I call it gnopen. Now I can do something like:

% gnopen SpreadsheetFile.xls

and it'll open just as if I had double-clicked it.

About the name

Normally, I am opposed to giving programs names that start with "g", or "k" or "py" or "lin". I think, "Hey, just give your software a discriptive name. I don't need to know how much you like gnu." Plus, it can get embarassing if you write a portable application (which you should). For example, my favorite python debugger is called "WinPDB", despite the fact that it works on many platforms. Or what about people who play "Lincity" under FreeBSD?

The reason I chose to name this program after its tech stack is that it is inherently not portable. What the program does is open files the way Gnome opens files. One day, there can be a"kopen", as well, and it would be handy to not have their names conflict.

In a previous post, I talked about my command-line program that opens files in the same manner as gnome would if you had double-clicked it in nautilus.
I have another piece of integration that I'd like to see: Clipboard integration.

The Problem

I'm always editing text files in vim, or viewing them in less, in a terminal window. Sometimes, though, I want to take that file and copy it to the clipboard so that I can paste it into, say, a textarea in my web browser.
I could normally just drag my mouse, or select all, or whatever, then copy/paste. But using the terminal breaks that metaphor, because selecting all just selects all the things on the screen (or at most the scrollback buffer). If my file is longer than the screen or the scrollback buffer, it's difficult to get it onto the clipboard.
What I usually do in that situation is to open the file in gedit and then select all, copy, then paste. Pain in the butt!

The Solution

Why not skip the middleman? make a program that runs on the command line, takes stuff from stdin (or a named file), and then uses the gnome or X11 apis to put that text onto the clipboard. Easy as pie.

% cat blog-entry-I-wrote-offline.txt | enclip

I just struggled with a ...bug?? that drove me a little crazy.  My site was chugging along just fine and then I would save a node, or a configuration or something, and suddenly all my views that used votingapi would blow up.

I kept looking for things that caused it -- was it the module I just enabled?  Was it this?  That?

I found out the problem, and it was subtle.

When the views blew up, I looked at the views UI screen and found that all my references to votingapi fields and sorts had been messed up -- replaced with blank lines with no descriptions and no options.

I found out that, when the views module called "module_implements('views_tables')", the votingapi module had not been loaded yet.

The solution:  I had to go into my database and decrease the module weight of votingapi.

UPDATE system SET weight=-1 WHERE name='votingapi' AND type='module';

Apparently, the two modules had the same weight, so whether or not they loaded in a propitious order depended on the random whims of their order in the database, which would sometimes change when I poked random data in there.

I don't think this is actually a bug, so much as an inevitable consequence of drupal. But mostly, something that a potential user of votingapi should know about.

I wanted to give you all anonymous access to my public git repositories, and I wanted to add a special field in my Drupal "Blog Post" content type to allow it.  (Results can be seen in my post about dbgp).  It was all pretty standard.  I added a field to my content type.  The field was of type "Link", as provided by the Drupal Link module.

I ran into a small stumbling block, however:  When I attempted to post my git:// url, the Link module told me that it was an "invalid url".  It's not.  It just has an unusual protocol name.

It turns out that the Link module  checks a variable called "filter_allowed_protocols", which was defined by the core "Filter" module.  Apparently, nobody provides a UI to edit this variable.  So I had to insert it into the database by hand.

First, I selected for that variable:

SELECT * FROM variable WHERE name='filter_allowed_protocols';

As it happened, my results were blank -- it was using the defaults. So I pulled the defaults out of the source code, and I wrote a little php, added 'git' as one of the allowed protocols, and then wrote a php script to print out the serialized version of this array.  (The reason for this step is that the 'values' in the Drupal variable table are supposed to be stored as serialized php variables).

My script looked a lot like this:

echo mysql_escape_string(serialize(array('http', 'https', 'ftp', 'news', 'nntp', 'telnet', 'mailto', 'irc', 'ssh', 'sftp', 'webcal', 'git')))."\n";

Finally, I stuck the results of that back in the database:

UPDATE variable SET value='a:12:{i:0;s:4:\"http\";i:1;s:5:\"https\";i:2;s:3:\"ftp\";i:3;s:4:\"news\";i:4;s:4:\"nntp\";i:5;s:6:\"telnet\";i:6;s:6:\"mailto\";i:7;s:3:\"irc\";i:8;s:3:\"ssh\";i:9;s:4:\"sftp\";i:10;s:6:\"webcal\";i:11;s:3:\"git\";}'
WHERE name='filter_allowed_protocols';

And now, I can post my git repositories and you can clone them.  Horray!

So, I just set up this website to keep track of all the open-source software things that I think about and do. Of course, I would never dream of setting up a blog site using software other than Drupal. At my work, and as favors or volunteer work, I've set up a number of webpages using Drupal. It provides the best of a content-management system, and a "web application framework". A website running Drupal can be made into almost anything. There's user-contributed modules for a staggering number of purposes, and it is very easy to build upon work that's out there, to create new modules for your special purposes. Therefore, I think that the Drupal project is significant as a place to collect all the work that is done in the area of web applications.
But in all the work I've done with Drupal in the past, I've always been using version 5.x. Drupal 5 was the one that was out when the popularity of Drupal really exploded. From the legends I've been hearing, this is in part due to the increased flexibility that it offered over previous versions.
Of course, we can't stay with Drupal 5 forever. Module-writers found that the Drupal 5 API lacked some of the features they wanted (one example I've run into: Drupal 5 doesn't allow us to write modules that affect people's access to individual menu items). So, of course, development of the core of Drupal has continued, and Drupal 6 is now out, and has been since February.
What happened, though, is that a large portion of this staggering array of user-contributed modules was written to interface with Drupal 5. Now that the API has changed, the community is faced with the task of adding Drupal 6 support to all the cool, useful, or indispensable modules that they've come to depend on. And this is happening much too slowly, in my opinion.
Of course, how could this not be the case? All these cool, useful, or indispensable modules are written by a highly heterogeneous group of people, each with different goals and requirements. They don't need your stinkin' release schedule.
It's also a chicken-and-egg problem. Lots of modules are set up to depend on one another, and so it's difficult to motivate people to add Drupal 6 support to theirs before all the other modules do it too.
So I just set up my blog to use Drupal 6. I did this not because I thought it was the best choice for me. Rather, I did it for two reasons:

1. I wanted to evaluate Drupal 6. I often find myself in the position of recommending software to people, so I want to stay informed.
2. I want to help 'em out. I find that when I use open-source software, the open-source software I use tends to improve. If I'm being driven crazy by a missing feature or a bug, I sometimes pitch in and write a patch. And the times that I don't do this, I want to. I'm hoping that by my using Drupal 6, I can help speed us along, because I will update the modules I want to use.

So here's what I've found so far.

The State Of Things

So, almost all the modules I used were in "release candidate", alpha, beta, or "dev" (without an official release) state for Drupal 6. What I would think would be embarassingly, this includes some of the essential modules without which it does not make sense to run Drupal. This includes Views, CCK, Date, Image, and TinyMCE Integration (TinyMCE for Drupal 6 doesn't support the uploading of Images through the Image module. See http://drupal.org/node/245799). In fact, some of these thing demand that you use the latest cvs snapshot of other modules, or of Drupal core itself.
Also, I'm sure there are many cool modules that I'd like to use on my site that don't yet have Drupal 6 support. Since I haven't spent a lot of time customizing this site yet, I'm not exactly sure what I want it to do. But one that I've come up on already is Autosave.
Hopefully, some of these things will make it into my issue queue.

And another thing

I just realized another reason that this transition is happening so slowly: almost all these module maintainers decided that, rather than straightforwardly port their modules to Drupal 6, this would be the best time to implement all those "wildest-fantasy" features that they've been wanting. Like, "Man, if I had it to do over again, I would've made Views like this."
So we have the conflation of two upgrades here: Drupal 6 compatibility, and enormous rewrites for new features. There's no inherent reason that these things have to block on each other, but the maintainers decided to do it anyway. That's why we have to wait so long for Drupal 6 to become stable.
If it was me, I would've simply ported forward the old module, and then later made all the changes that I'd ever wanted to make. | So, I just set up this website to keep track of all the open-source software things that I think about and do. Of course, I would never dream of setting up a blog site using software other than Drupal. At my work, and as favors or volunteer work, I've set up a number of webpages using Drupal. It provides the best of a content-management system, and a "web application framework". A website running Drupal can be made into almost anything.

Update - I couldn't take it

I couldn't take it. I did my site in Drupal 5 instead. I would love to contribute to all this Drupal 6 business, but you can't really run a Drupal 6 website yet. So if I'm going to help out these modules, it means that I have to go out of my way to develop for them, which means it's probably not going to happen. That makes me sad. Maybe in a few months or so, things will have stabilized enough that I can jump over and start to help out. We'll see.

I use Sound Juicer to rip music. I use it quite a bit to rip music, seeing as how I'm a DJ at WCBN. Also, I'm often ripping pretty obscure stuff, which doesn't have metadata listed online. This means that I have to enter the data myself.
The problem I have is that Sound Juicer isn't very data-entry friendly. When entering the names of several tracks, I have to use the mouse to click between those tracks. I wish that I could use spreadsheet-like keys -- tab or enter to move between columns and rows. I am not a fan of using my mouse. One day, I'll get a headband that I can wear so that I can move the mouse around with my mind, but until then, I want applications to be keyboard-friendly.
It's true, I should be entering my tracks into MusicBrainz. I would do that if it were easier to do. See my next post about Sound Juicer.

Update

It turns out that there are some standard keyboard shortcuts that I just didn't know about. It's not exactly as intuitive as I was hoping, and it's a little bit more cumbersome than ideal, but it works. It turns out that you push enter, and you'll be able to edit one column. When you're done, push enter again and you'll be back in "navigation mode", where you can use the arrow keys to move around and push enter again to start editing another column.
In my opinion, arrow keys are almost as bad as the mouse, but not quite. It would be ideal if the straight-up spreadsheet-style key bindings worked. It would probably mean subclassing some or other widget. But the existence of these key bindings makes it so that this is no longer important enough for me to worry about, I think. I'll be posting again if I find that it still annoys me.

You may have noticed from some of my previous posts that I'm the kind of guy who likes to use the command-line, even when there's a perfectly good gui solution. In fact, I almost regard a gui-only solution as a non-solution to many problems.

And one rather shocking probelm that I haven't seen a non-gui solution for is this one: PHP Debugging.

Since PHP is the one of the hotter programming languages for web applications nowadays, I think we're long overdue to have a good debugger for it. It gets in the way an awful lot, to not have one.

Of course, the problem of PHP debugging is being looked into. Just not the way I like it. XDebug provides us with a remote-debugging protocol for PHP. The remote-debugging protocol has its own name - dbgp. The authors gave it a name in the hopes that other programming languages could also implement the same interface. Then, we could have one debugger that could work on any programming language. That's a pretty admirable goal, in my opinion.

The problem is that we don't yet have a good client for dbgp. By "good", I mean one that has a command-line that uses gnu readline.

Here's what we do have.

We have a dbgp plugin for eclipse. Of course, eclipse is a programmer's IDE. I prefer to use the older and much more mature programmer's IDE: Unix.

Closer to home is the dbgp plugin for vim. This is actually what I use at work, and I find its workings to be adequate.  There are things I don't like about it.  For one, that when I print out values to the screen, I want to see them in a format like that of var_dump or print_r.  Instead, I get a weird format that doesn't allow me to see keys and values at the same time, and also truncates output to some arbitrary length. Furthermore, it partitions my vim windows up all weird, making it impossible to copy/paste anything out of there.  Also, because it doesn't have the command-line metaphor, I can't easily repeat evaluations I've made or anything like that.  Finally, it doesn't seem to allow me to define watchpoints.  That's just my list of grievances off the top of my head.

Most of those could be fixed within the context of the vim plugin, but there's one thing that can't be fixed in there:  Aesthetics.  I want a command-line debugger like gdb or winpdb, for Python.

Well, I tell ya.  I started work on that a little while ago.  I started from the source code of the vim plugin, and I'm trying to use the functionality of that while providing a different, command-line, interface.   I'd like to modularize it enough that the two interfaces can coexist in the same file, but behave as a vim plugin if executed in vim context or a cli program otherwise.

If I do it this way, both sides can benefit from the development of each other.

I would make one change, though:  The original is MIT licenced.  I would like to re-licence it as GPL. That's either so that I can distribute it with gnu readline support, or just because I don't want to work in my spare time on software that some huge corporation can steal from me.

If you'd like to help, feel free to grab what I've got so far from my git repository.

I often find myself ripping CDs that don't have metadata on the web yet. Of course, I want to help out the community by adding this data, but sometimes I'm too lazy. To me, this sounds like a situation where the data entry should be made easier.
Sound Juicer has a menu item that says "Submit Track Names", but all this does is take me to the Music Brainz website, looking up the TOC for the CD. Then, the Music Brainz submission process is a little complicated.
I wish that it worked where I could enter the data in Sound Juicer and then hit "Submit Track Names" and it would submit the data I just entered into Music Brainz for me, perhaps giving me some confirmation things to click on.
It seems that the main barrier to that right now is that Music Brainz has to data-submission web service API. They expect you to enter everything through the website.
I will be making a post to their mailing list as soon as I get a chance. http://musicbrainz.org/doc/NewFeatureSuggestions.

Imagine how convenient it would be if you could convert between different document formats from the command-line. You could take that word document and turn it into HTML. You could print out some HTML and have a link on your page saying "Download this as a word document". You could have your email program automatically convert Word documents into OpenOffice documents.

One application you could see is an open-source replacement of Google Docs. Right now, our rich-text editors like TinyMCE and FCKEditor do a pretty good job of doing wysywig editing of documents. The only problem with them is that they can only generate HTML. So if you want to download your document as a Word file or an OpenOffice file, then you'll have to get the HTML, fire up your heavy-duty OpenOffice application, then do "Open" and "Save As". Very labor intensive. Websites can't even count on people having this application around. Indeed, if they did, they might be using that instead of an online document manager.

So then I heard about something called eyeOS, which provides a webpage that acts like a computer desktop, with a TinyMCE-based word processor. Their pages indicated that you would be able to save your documents as Word docs.

"Oh boy," I thought. "Someone has finally solved the problem of bulk-converting between different document formats."

But I looked at it, and was disappointed. You know what it's doing? It is opening up OpenOffice and clicking on "Open" and "Save As". Seriously! It uses Xvfb to open up OpenOffice behind the scenes, then communicates with it, possibly using DCOP, to open your file and then save it.

You could not have a less efficient process unless you tried.

The thing that drives me crazy about all this -- and especially eyeOS's solution, is that we have this code, people. The secret to converting between these different document formats is not a secret at all. It is part of OpenOffice, which is under the LGPL.

So all it would take is somebody ripping out the conversion code from OpenOffice, and the internal model of documents, and jettisoning all the UI stuff that we don't need. I'm imagining a package like netpbm -- a bunch of little tools that convert from anything to OpenOffice format, and then from OpenOffice format to anything.

It'll be great. We need this. I hope to do it soon.