BenHollis.net

In August, 2011, a major change to how Xbox.com works broke XBList. This sort of occurrence isn’t uncommon since XBList simply screenscrapes Xbox.com, leaving it vulnerable to even minor changes in how friend data is displayed on the site. The changes in August were more major, preventing me from just making a quick fix, though. I added fixing XBList to my pile of pending projects, and expected to get to it in the next few weeks. That didn’t happen.

What has happened?

I haven’t really had the will to work on XBList very much in the last few years. For starters, XBList isn’t a very interesting project – it’s a constant game of keeping up with Xbox.com, it’s a pretty boring app, and it sees the least usage of any of my software projects. I’ve also moved to using Mac OS X and Linux almost exclusively, meaning I wasn’t even running XBList myself. Not that it’d matter to me much, since I also haven’t been playing Xbox games. In the last few years I’ve shifted my interests away from sitting on a couch to going outside and enjoying the Pacific Northwest through parkour, scuba diving, biking, etc. My indoors time has been spent more on other projects and other creative endeavors than gaming. I’m no longer playing nightly matches of Halo with my East Coast friends who also have less time than they used to. Thus, my drive to devote time to XBList has dropped sharply.

I’ve also become increasingly embarrassed by XBList. It was my first desktop application, built in college as my first C#/.NET project as well. I barely knew how to program, let alone build anything wonderful (or maintainable). Combined with the ugly inflexibility of Windows Forms, XBList could never be something I was proud of as it was.

All this is to explain why, when XBList broke last August, I decided to throw away everything I had and start over. I chose to develop a new XBList 4 using Titanium Desktop, a cross-platform application framework that uses web technologies like HTML and JavaScript. In theory, this would allow me to build a new XBList that looked better, borrowing heavily from Microsoft’s new Metro styling and their iPhone Xbox Live app. It would allow me to ship versions of XBList for OS X and Linux, which is especially important since I predicted, correctly, that Microsoft would ship their own Xbox Live integration with Windows 8. As an aside, when I built XBList originally I thought it’d be a temporary solution until Microsoft made their own Windows Xbox Live app. It’s amazing that it’s taken them 11 years, and that they even launched on iOS before Windows. Anyway, working in Titanium would let me develop on OS X, play around with CoffeeScript and Knockout, and use my CSS (er, SASS/Compass) skills to do what I never could with Windows Forms.

However, after getting the basics working, the project stalled out. I didn’t have the interest to finish up all the little pieces that turned XBList into a finished project. Xbox.com continued to change, rendering one weekends’ work null by the time I picked it up again the next week. Bugs in Titanium and frustration with CoffeeScript slowed down my progress. And most recently, Titanium Desktop was abandoned by Appcelerator to focus on their more-popular mobile framework. They didn’t even finish releasing the beta version I was having to use. I had suspected this would happen even when I started using it, but it was still disappointing to have the rug pulled out from under me.

What happens now?

I haven’t decided. Right now, I’m pretty much on the fence between trying to finish what I’ve got and put it out there, warts and all, and just discontinuing XBList entirely. Even if I do finish it, I’m not sure it’ll be up to my standards, I’ll have to support it for three platforms, and with Titanium Desktop’s future looking bad, I don’t know what the experience of installing and running XBList would be. I’m almost certain that Titanium Desktop won’t be kept working with developments like Apple’s Gatekeeper or Windows 8. Perhaps XBList 4 will be released someday, but I can’t say when that’ll be or even if it’ll happen. And just to head off the inevitable question, no, I will not be open-sourcing XBList or giving it over to another developer. If you’d like to make your own friends list viewer, it’s probably easier to just start from scratch.

I was hoping PNGGauntlet 3.1.0 would be the last release I’d need to do for a while, but it looks like there were still a few bugs that needed to be fixed. 3.1.1 is out and fixes all the bugs that were reported to me. The most important was a bug where you could add a non-PNG image to PNGGauntlet, and after compressing the image would convert to PNG, but still have its old file extension. Now, the file extension will be changed to .png as you’d expect. Besides that, I’ve made it so that PNGGauntlet will run on the smaller .NET 4.0 Client profile, and I’ve fixed the “Cancel Optimize” button so it’ll cancel immediately, killing any in-progress compressors, rather than waiting for the current compressor to finish. That’s particularly helpful since some images can take minutes to compress. Please grab 3.1.1 if you haven’t already, and feel free to email me if you notice anything still broken.

It’s been less than a week since PNGGauntlet 3 was released, and now PNGGauntlet 3.1 is out! It turns out that when I found PNGGauntlet 3, forgotten and incomplete, I hadn’t realized exactly how incomplete it was. Most everything worked, but the options dialog was only half-implemented, not allowing you to change OptiPNG and DeflOpt options. Worse, I’d broken the ability to launch PNGGauntlet with command-line options, which also broke the “Open With…” feature introduced in 2.0.1. I wanted to fix those bugs, but I know that I personally hate it when I update a program only to have another update right away. I knew I needed some neat feature to add to make it more palatable to update, and the only thing I could think of was the feature that everybody asks me for every time I release PNGGauntlet. So I did it – PNGGauntlet will now use all of your processor cores to compress files in parallel. You can turn it off if you don’t want it, but in my tests on an older dual-core machine, it halved the time to compress a batch of images. Hopefully that will make this update go down a bit smoother.

Update: OK, so it looks like there are still a few bugs, introduced by adding the parallel compression and the new compressors. Non-PNG files are being converted to PNG but keeping their original file names, and errors are popping up while parallel-compressing files. Sorry, I’ll have a 3.1.1 version out soon that addresses these. No, I didn’t “remove features” in favor of nonsensical behavior, these are all just bugs.

This weekend I released a major update to PNGGauntlet, my PNG compression utility for Windows. A lot has changed, including a lot of bug fixes, but the biggest news is that PNGGauntlet now produces even smaller PNGs! I did a bunch of research, and I found that combining the powerful PNGOUT utility that PNGGauntlet has always used with OptiPNG and DeflOpt, even more bytes could be shaved off of your PNG images. The contributions from OptiPNG and DeflOpt are often small compared to what PNGOUT does, but if every byte counts, you’ll be happy with the new arrangement. The new compressors do slow down the process a bit, though, so you can turn them off if you don’t want them.

That’s not all that’s changed, however. The UI has been streamlined, leaving only the most essential options. Drop files on the app, hit Optimize, and don’t worry about the rest. However, if you want to tweak the compressors, there’s an all-new options panel that exposes every possible setting for each compressor. The PNGGauntlet website has also been overhauled with a much more modern look.

Before you ask, no, the new PNGGauntlet will not compress multiple images at once to make use of multicore processors. I cover this in the FAQ, but since Ken Silverman, PNGOUT’s author, provides a professional PNGOUT for Windows that’s multicore-optimized for only $15, I don’t want to compete by matching PNGOUTWin’s feature set. It’s absolutely not a matter of not knowing how to do it. And anyway, the individual compressors do a good job of using multiple cores on their own.

One question that deserves an answer is why there was no PNGGauntlet release in the last year and a half. The answer is essentially that I forgot about PNGGauntlet. The last release, 2.1.3, was in May of 2010. That December, I did some work on a new version of PNGGauntlet, incorporating the new compressors and slimming down the UI. After I’d done that, I decided that I wanted to overhaul the UI completely – it’s built with the old Windows Forms technology and a pretty rickety open source data table library, and I’ve always been embarrassed by how crude it looks. My plan was to use Windows Presentation Foundation (WPF), which was supposed to be the new way of developing UIs for .NET apps. However, I soon discovered that Microsoft’s WPF libraries don’t really give you a native-looking UI. Applications developed with WPF look kinda like Windows apps, but they’re off in a bunch of subtle ways that really bothered me. So I ended up starting to draw my own controls to match Windows 7 more closely. And after a while down that rathole, I sorta gave up and shelved the whole project in disgust.

Since then, I’ve actually switched to using my Macbook Air, in OS X, almost exclusively, and I almost never use my Windows machines. The prospect of developing Windows apps no longer interests me much, and I don’t really use PNGGauntlet anymore myself (I use the very nice Mac analogue ImageOptim). PNGGauntlet still worked, so it stayed out of my mind until @drewfreyling messaged me on Twitter asking about incorporating the latest version of PNGOUT into PNGGauntlet. I figured it would be pretty simple to do a minor update, but when I booted up my old desktop and took a look at the code, I found my mostly-completed update just waiting to be released. So, no new slick modern UI, but I was able to spend an hour finishing up what I had and release it as PNGGauntlet 3. Hopefully it’ll be a useful and welcome upgrade to both new and existing PNGGauntlet users.

A few months ago I finally gave in and bought a MacBook Air, and I haven’t looked back. At this point I’m using my Mac for most of my day-to-day computing, and I’m very happy with it. It’s certainly much friendlier to the predominantly Ruby-based web development I like to do. As a first dip of the toes into Mac programming, I decided to try to make a couple Dashboard Widgets. Dashboard is the Mac widget platform, sorta like Windows Sidebar only it came first and it’s a much better platform. Dashboard widgets are relatively full-featured, built on Webkit using HTML and JavaScript, and can be authored with the free DashCode IDE. I found working with Dashboard to be a little frustrating, and it’s clear that Apple isn’t investing much in that space anymore, but it’s still miles ahead of the excruciating experience of developing Windows Sidebar gadgets.

My first widget was an ultra-simple Xbox Live Gamertag widget, which was basically a straight port from the Windows version. Aside from the preferences, which are now on the “back side” of the widget instead of a fly-out panel, not much is different.

The second widget is a bit more complex – it shows the current challenges available in Halo: Reach. Every day (and week) there are new challenges players can meet in order to get credits to buy in-game armor. This widget helps keep that info a keypress away.

Anyway, if you have a Mac, please head on over to my Dashboard Widgets page and give them a shot!