rendezvous

useful things that rendezvous should be able to do:

  • detect an SMTP server and set Mail.app or whatever client you’re using to send through it
  • Detect the equivalent of a Domain Server, and add a ‘log onto local server’ option in the login screen that will pull down a profile from a server, so you get workgroup functionality merely by being on a local network with a workgroup server
  • I want iCommune back, but in a way that works.

I also really want these things to work from non-apple machines as well – I want the server at home to advertise the house music collection and SMTP server, despite the fact that it’s a linux box. But that’s harder to whinge about.

from a conversation with blech.

sharpreader

sharpreader – a windows RSS feed reader. Uses .NET, which is all the rage nowadays, apparently.

It’s beautiful, easily the best RSS reader I’ve ever seen, and that includes the one I wrote :-). Proper OPML export / import (It’s amazing how meny readers get this wrong), the interface, although slightly hard to figure out makes a lot of sense once you get the hang of it, and frankly usability and learning curves can go hang once I can use the thing.

The nicest feature, though, is the threading. I’ll notice which other blogs you read have linked to this one, and will do the litte ‘+’ symbol thing so you can expand them and see all the interlinks. It’s niiiiiiiice. I’m suddenly tempted to go back to “lectern”:/programming/lectern and hack this in somehow, though it’ll be hard. Maybe I’ll write a mac one and steal the niche of NNW. Maybe I’ll write a bad alpha and get distracted by some other project. Yes, that seems to be the best idea.

Software interfaces evolve like this, it’s wonderful to watch. Web browsers are another fairly immature tech that grow “tabs” and other interface things, and that’s nice to watch too, even if they’re stupid. Genuinely new types of apps are rare, I can’t think of many off the top of my head, although obviously once they’re pointed out, it’s obvious…

string.pl

blech has been on at me recently to finish my half of our evil ‘Wire and string’ project – it’s a cunning, cunning plan which we really should put more effort into. Anyway, here’s a heap of self-congratulation that I’m done, and he should get off his butt and implement the other half.

Essentially, the problem is as follows: We have a computer in the lounge that can play music, hooked into the network and the stereo system. But there’s a complete lack of decent software to control the thing. We searched and searched, and all the interfaces we could find sucked.

Now, the best music control interface we know of is iTunes. We want iTunes to control what is being played on the lounge machine. But it’s not a mac. Hence the goal – have iTunes on a mac locally, pick up what song is selected/playing, and send that to the lounge computer, which will then play it through the amp. blech took the iTunes half (the Wire), I got the server half (the string).

Now, there are no non-awful MP3 playing interfaces for perl. None. Almost everything that I could get to compile at all (and didn’t need non-free libraries you can’t download any more) wrapped either mpg123 (now that’s a pretty web page) or xmms. The mpg123 wrappers seemed to be the best bet, and for the most part they work, but there are… issues. I didn’t get proper events for songs ending or stopping, it was quite easy to wedge the thing to the point where you couldn’t control it any more, etc, etc. | believe these are limitations of the command line mpg123 interface, and I can work round them, but I don’t want to have to patch the source code just to get a working system, and it makes distributing things a complete pain. I also need the server to be absolutely robust, it’s no good having to SSH in every 5 mins to fix the server – the whole point is to avoid having to think about it.

Wrapping xmms isn’t much of an improvement. It’s got a much nicer interface to control it, but, of course, it’s controlling xmms, which is a seperate app that needs to be running, and it needs to be running on a machine with an X server. Hard, given this is a headless server.

But, in the end, that’s what I used. I was saved by Xvfb – I can run an X server on the machine without having to worry about graphics cards, and launching xmms from the cgi is possible, so it will run as the right user and everything. After a lot of messing with annoying permissions, I have a CGI that will make noise.

The other problem is that the Mac only knows where the music is on the machine locally. Rather than having the iTunes end convert the local path into something the server knows about, I take anything that might possibly be a path to some music, and trim things off the left of it till the right hand side matches something in the ‘locate’ database. Disadvantages – you need an up-to-date locate database. Advantages – you can pass just about anything that is music, and the server will have a shot at playing it. In practice it works really quite well.

So, yeah, code . w00t.

the broken desktop metaphor

There was a throw-away comment by Dan Hill in an article on Elite about the desktop metaphor and the workarounds we have to use to make it work. Now, I don’t think exposé is a work-around. I think it’s the most sophisticated window-management system I’ve ever used, it’s lovely. But it does hilight something that’s need nagging at me for a while. The Desktop.

Now, essentially, the desktop metaphor is broken. It’s not a desktop at all. It’s far too small, for a start, I’ve heard it described as the airplane seat metaphor. But the most important distinction is what’s underneath all your bits of paper. Suppose you have a real desk. Pick up all the things on it and look underneath them. What do you see? You’ve got a completely blank desk. Ok, now hide all your windows and things from your computer ‘desktop’. Got a blank desk? No? Didn’t think so.

Eventually, everyone needs a hack in their windowing system so that they can get at the desktop. Windows has ‘Minimize All’, or in extreme cases, ‘Show desktop’ (there’s a difference between these two. Try explaining the difference to a non-geek). For me, Windows always seems neatest with all windows either maximized or minimized. The fact that the only graphical way of getting at your hard disk is the ‘My Computer’ icon on the desktop means that you need to be able to get at it easily. Mac OS X 10.2 and before never had a really good solution to get at the desktop. There are various third party hacks but the only decent way I ever used was to Command-Option-Click on the desktop, or Command-Option-H with the Finder focussed. This hides everything except Finder windows. Of course, if there are Finder windows blocking your desktop, you’re stuffed. Ah, well.

Exposé solves this – one button and all your windows get out the way. Yay! Finally they’ve solved a problem Windows solved 5 years ago. (Or whenever, I don’t care).

I’m tired of working round this. I can shuffle through all of my windows with Command-Tab, but I can’t get to the desktop without moving all the windows out the way? This is an annoying special case, and I don’t like it.

New philosophy. Nothing will go on the desktop. Nothing at all. I won’t display drives on it, I won’t save files on it. I’m going to change it’s permissions so that I can’t write to it. My default download folder will be a folder in my home directory. We’ll see how long I last before I go insane.

Update – I follow this up here

The Finder Toolbar

The Mac OS X Finder has an interesting toolbar. blech will happily rant about it for hours, and I agree with him, toolbars do not belong on Finder windows. Or at least, not in the icon view Finder windows, and neither of us like the Browse view at all. But that’s missing the point. I’m convinced the toolbar on Finder windows is a vestigal shelf, although I can’t find anything on the web that backs this up, and I’ve never used NeXTStep, where the shelf was originally seen. You can drag things onto it from finder windows, and they’ll stay there and you can run / open them by clicking on them.

The way it fails in this is that you can’t drag files off the toolbar into another folder and move the original – dragging things off removes them from the toolbar. Arguably better from a least-surprise point of view, but it removes one of the nicest things about the shelf, it’s use as a scratch area. Oooh, thought, this is exactly how the right hand side of the dock behaves, except you can’t drag apps onto the right hand side of the dock.

Oh, and there aren’t any tooltips, so if you have ‘icons only’ toolbars, you can’t tell where things point. That’s annoying.

Web browser features

blech and I have been talking recently about things that web browsers really should do. We both get annoyed when browsers won’t save the state of opened windows (pith helps here for our web browser of choice, but that’s not the point. It should be app-level – Galeon was superb in this respect.), but there’s other, smaller, things that browsers could do to help people.

For a start, they need to understand the concept of a ‘dirty’ (changed/unsaved state) window, and prompt the user if they try to close it, in the same way that you can’t just close a changed document. Changing data in a form makes a window dirty. A page that’s the result of a POST request is dirty. In short, if I’m looking at state that can’t be retrieved from a bookmark of the current page, the window is dirty.

Form field contents should be remembered completely. Safari is very good about this already, and does some clever tricks somewhere to figure out which forms expect, say, my email address, and fill it in automatically. IE does this too, and it’s a good start. But I’d prefer every form I ever fill in to have it’s state remembered by the browser. I want to bookmark a page with filled-in forms, and have them stored in the bookmark. And I want to hit ‘back’ and have the forms still filled in with whatever I left in them. The number of times I’ve put something long and complicated into a webmail client, hit ‘send’, seen a timeout error, and lost what I was writing forever… I have the habit of putting the contents of big Textareas into the clipboard before hitting the submit button. This isn’t the habit of a man with working technology.

2lmc , as always, have an opinion on this, which is what sparked this ramble off.

AudioFile::Identify::MusicBrainz

After much muttering back and forth between blech and I, I have written and released AudioFile::Identify::MusicBrainz. The old MusicBrainz client relied on the C library they distribute, which was silly for something that sent and recieved pure RDF, so a pure-perl implementation was just begging to be written.

So, upsides, it works, there’s exactly one sort of query you can send it, but that’s fine, it’s the important one – you can say ‘I know this about a track, tell me more’. The next step is to give the user a nice choice, and then let them write the updated information back into the ID3 tag.

Downsides, I’m not using ‘real’ RDF parsers, I’m using XML::DOM. This worries me, frankly, I’d much rather do the right thing, but I get a headache trying to make the perl RDF stuff work. There’s an RDF::Simple out there now, though, so maybe I’ll try that…

I’m going to get a reputation here for stupidly long module names, you know.

Blog-Mail convergence

Muttley caused this train of thought. Blame him.

Thoughts for a blogging toy

Here’s something I might do. Every time I post a blog entry, people on a list could get a mail with the subject, contents, etc, just like I actually just sent the thing to a mailing list. People can reply to the mail, and their replies get put as comments on the blog entry, as well as mailed to the rest of the list. People posting comments from the web page, their comments go out to the list. So if you ignore the mail aspect, it’s a traditional blog, and if you ignore the blog aspect, it’s a traditional mailing list, albeit with the caveat that only the owner of the blog can start a thread. And hell, that’s optional, you could allow free posting…

Once you do that, of course, the blog could be viewed as merely a web based archive for the mailing list, just with a much nicer web interface than most mailing list archives. Blogging software has put a lot of effort into managing date-based information archives, much more than mailing lists. On the other hand, mailing lists have put much more effort into managing threaded conversations than blogs have.

This blurs the line about what it is, of course. I’d probably initially implement it as a blog, with a bit of mail glue attached, but I suspect the more elegant way would be to have a mailing list with a very sophisticated web archive attached to it, one that handles threads as entries, and that allows you to post to the mailing list through the archive page. The distinction between the two rapidly becomes moot, of course.

Hmmm. Must play with siesta

(later) More Rambling

So, muttley has rambled as well. Interesting. He has some ideas about multiple blogs tying together somehow that I’m not seeing a way of making work in my head, and I hate talking about things I can’t construct a nice working mental model of, but he’s right, it would be nice to have a system of mutliple blogs tied together. Like this.

You get thread ownership problems, though. As things stand, I control a conversation on my blog completely. (well, if I had comments working yet…). That’s ok if the blog is also a mailing list, because I’d control the mailing list server completely as well. But if, say, threads I started were hosts on my blog, and threads paul started were hosted on paul’s blog, we get issues of potential censorship, and people picking the thread to comment on based on who’s blog the start thread was on.

That issue asside, it’s quite easy to adapt the first model espoused above to this sort of thing. All the participating blogs would send stuff to the same mailing list, and the mail reciever would use some smarts to determine which mails were replies to which blogs, and post comments appropriately. All doable. For the second, more elegant, solution, where the blog is merely one way of representing the ‘message’ objects that the back-end understands, we’d either need to host all the blogs in one place, or have a distributed server, or something. Not sure.

Tell you what. I’ll actually implement something at some point, and we’ll see how easy the collaborative stuff is then.