What's it all about, Alfie?

This morning I saw that Camino 2.0.2 is out with a few security fixes. Sounds about right, but since I don't use it that much, I'm not really that concerned about the threats. Still, no need to be silly and not get the update.

I've been working with the Google Visualization AnnotatedTimeLine widget, and it's nice - no doubt about it, but it's still a Flash-based widget. It's nice to know that the Table widget is now all CSS - it was originally a Flash component, but the AnnotatedTimeLine is still Flash, and it's not as snappy as it could be.

Sure, the AnnotatedTimeLine might not be meant to do the kind of graphing that I'm doing, but it's close. I've been missing the level of completeness that VantagePoint had in Java, but that's not really an answer, either - I can't go back to Java plugins and all the problems we had with that back at my old place. But still... there needs to be something better.

Normally, I'd say "Google will get there - eventually", but this is really something that needs to be done. The HTML 5 Canvas object has allowed quite a few implementations of nice graphing packages, but they aren't focused on the scientific plotting that I'm looking for. They are really focused at the business presentation graphing. Nice backgrounds, fewer data points.

What I need is something completely new and original. I need to have something that doesn't force me to reload all the data from the source - that's my first real killer problem. If I could send incremental updates, then I could stop sending these enormous JSON strings to the client for parsing. I'm not positive, but I'll bet that the memory problems I'm having now are a direct result of that.

Still, there's nothing I can really do - save start to write one on my own. If I want to leverage the work Google has started, then I just need to sit tight and hope that I'm not the only one that has this same set of issues. I'm probably not, but then again, if this is a Google "20% Project", it's unlikely that the developers will think what I need is really what they need to write. And there's no way I'm getting the source code, that's for certain.

VantagePoint is orphaned now, and that's a tragedy as they might have been one to move into this space, but alas, that's not to be.

It's just frustrating to know what needs to be done to make this a really stellar package, and not be able to get in there and fix it. But we all need to learn to live with disappointment.

Today I was checking on the latest Google Chrome for Mac and noticed that WordPress 2.9.2 was out and so I definitely needed to upgrade all my journals at HostMonster to the latest version. It's one of the most popular blog software packages, and as such, it's the target for a lot of malicious code. Better safe than sorry.

Today Gruber pointed out a link to an Open Source alternative to VLC. Given that VLC is hurting for the Mac developers, and that it's not able to even get a 64-bit version out the door, it seems likely that it might be heading out. If that's the case, then ripping DVDs is going to get very hard.

Movist seems to be nice, small, clean, and it works. Can't ask a lot more than that. I'll see if I need it, but it doesn't have the libdvdcss.2.dylib that HandBrake et. al. need to function. That's not a good sign.

Like a lot of the Mac Faithful, I've been watching the discussions about Flash on the iPhone, and now the iPad, with interest and a little bit of a foot in both camps. There's a strictly technical viewpoint to think about, and then there's the reality when multi-billion dollar companies get involved.

From a technical standpoint, Wil Shipley said it best in this series of tweets:

Honestly, I don't understand Flash-haters. It's a content type. It's prevalent. The iPhone and iPad should understand it.

Want to know what we did at Omni when there wasn't a flash player for Rhapsody? WE WROTE OUR OWN FLASH PLAYER. It's not that hard.

Apple: Get off your ass and write a minimal Flash player. Everyone else: Stop acting like not being able to see video is cool.

And yet, the counter argument is valid as well: that anything controlled by one company (Adobe) can't be a real "standard" for the web as it's possible that it could be modified/licensed/changed by the company for their own commercial goals, and that's not something that should be supported and encouraged.

Wil is right - Apple could solve all this by putting in a Flash player into QuickTime. But then is that really in Apple's best (commercial) interests? Probably not. Then when Adobe changes, Apple has to change to keep "compatible". That is putting Apple in a constant game of catch-up. Not a great place to be. And then there's the legal angle. Say they did this, and then Adobe came after them. It's Adobe's property, after all, and while there's an open source Flex compiler, there's a lot that's missing from that project as well.

It's a battle of Titans, and we're pawns in this game. They are far more interested in control than they are in the customers. If Apple really wanted to make folks happy they'd work with Adobe to make Flash supported in QuickTime. Easy. But that means someone has to "flinch" first. Apple? Not likely. Adobe? Can't see that, either. But it would be pretty easy to clear this up.

On the other hand, it wouldn't bother me a bit of Flash became a niche player. Sure, there will be folks that will use it, but again, if it's below 80%, then it's just another plugin system. There will have to be others supported by the developers. Like YouTube's HTML5 video. Things like this will move in to create open alternatives to Flash.

So it wouldn't be horrible if the stand-off continued and HTML5, and it's successors, made Flash something less than a defacto standard. But then again, it's just a content type, after all... just support it, Apple... Or Perian... Someone.

Well... VLC 1.0.5 is out and because of a lack of Mac developers, there's no 64-bit version of it available. This means that HandBrake - which now sees itself as a media converter and not a DVD ripper, running in 64-bit mode can't load the libdvdcss.2.dylib that's in VLC, to decode the DVD. Sure, there's FairMount - again in 32-bit mode, but that's just the same problem. It looks to /Applications/VLC.app/ for the file, and if it can't load it, then it, too, bails.

So it seems that no matter what I do, the version and build of VLC is the key. If it's 64-bits, then it's OK for HandBrake and FairMount. If it's not, I can still use FairMount 32-bit to unlock the DVD, and the 64-bit version of HandBrake to convert it, but we're still dependent on the build of VLC. And as long as it's 32-bit, there's really no reason to use the 64-bit HandBrake. I don't rip that many DVDs, and when I do, I just want something that runs.

It's disappointing that they create HandBrake the way they do... removing the critical file, but that's life. It's their choice. For now, I'm running HandBrake 32-bit with VLC 32-bit because that's all they have. And it works.

Maybe someday there will be a 64-bit VLC, and then I can move to 64-bit HandBrake.

Still a EE geek at heart, it does my heart good to see that MacSpice 2.10.23 is out, and still kicking. It's not going to win any Apple Design Awards for the UI, but the graphs work, and are clear, clean, and legible. The numbers are SPICE and spot-on. It's hard to complain about the app. It's something that could use a nice face-lift, but it's still great to see that they're working on the engine, and making it better. Fantastic!

Over the weekend, I stopped by the Apple Store in Naperville to pick up two of their small aluminum keyboards to use with two machines at work that used to share a keyboard/mouse with a switch-box, but last week were "split" so that I needed two keyboards in a pretty small desk.

For this desk, I need to get rid of the numeric keyboards to save the space. Just have to.

So the question is "How do I make it work with linux?"

Thankfully, xmodmap is going to do everything we need, and all I need to do is to get the keycodes from the keyboard and put them into the .Xmodmap file that I've already got to swap CapsLock and Ctrl.

Open up a terminal and type:

  $ xev

What you'll see is a new window with every X event getting printed to the standard out. Lots of information there, but in addition, you'll see every key press and release - and therein you can find the keycodes.

What I found was the following:

From this I was able to create the .Xmodmap that made the "Apple" keys act as "Alt" keys (their default appears to be to act as "Windows" keys) so it's easier to do what I need:

  !
  ! Swap Caps_Lock and Control_L
  !
  remove Lock = Caps_Lock
  remove Control = Control_L
  keysym Control_L = Caps_Lock
  keysym Caps_Lock = Control_L
  add Lock = Caps_Lock
  add Control = Control_L

  !
  ! Make the Apple keys Alt keys
  !
  keycode 115 = Alt_L Meta_L
  keycode 116 = Alt_R Meta_R
  add mod1 = Alt_L Meta_L Alt_R Meta_R

I may try to map some of the function keys to PgUp and PgDn keys, as those would be nice, but for now, it's enough this morning to get the Alt keys working on the new keyboards as that's how I switch between workspaces - which is essential.

I really like the additional desk space... that's a real plus. Just a little more fiddling with the location of things, and I should be settled in with the new hardware.

This afternoon I ran into a problem between Java's URLEncoder and JavaScript's unescape() funtion. Ideally, I'd be able to create a URL in a Java servlet and ship it to the client and use JavaScript's unescape() function to parse the GET variables for the page. And it almost works. Almost.

The problem is the space character. The URLEncoder encodes the space into a plus sign ('+') and not the hex code (%20). The JavaScript unescape() function doesn't convert the plus sign into a space. So I have to do the following in my code:

  function parseGETVars() {
    var retval = [];
    var urlChunks = String(document.location).split('?');
    if (urlChunks[1]) {
      var pairs = urlChunks[1].split('&');
      for (var i = 0; i < pairs.length; ++i) {
        if (pairs[i]) {
          var parts = pairs[i].split('=');
          retval[parts[0]] = unescape(parts[1]).replace(/\+/,' ');
        }
      }
    }
  }

With the little change, I can use the Java URLEncoder and still get things working. Not too bad, but why on earth are these guys not doing the same conversions?

This morning I noticed that CoRD 0.5.2 was out, and with it, a hope that I may never have to have another Windows box again. This is an incredible app - works every bit as well as Windows' own Remote Desktop client for everything I need: get to a machine, run what I need, fiddle with files and settings, and get out. It's amazing.

With the update it's running in 64-bit on Snow Leopard, and several crashes have been fixed. It's also got the self-install/on-disk-location checks which have been talked about a lot in the web lately for Mac apps. I'm encouraged when I see this kind of thing picked up by really nice open source projects. Clearly, these guys are good, and that's great news.

I'll keep using this as long as it's available because I never want to have another Windows box, and there's no way business is going to give them up.