Beryl: Oh, the hypocrisy!

<BeforeYouFlameMe>Yes, I understand that one person does not represent the full Slashdot groupthink</BeforeYouFlameMe>

A common battlecry of Slashdotters is ‘you’re wasting my CPU cycles/GPU cycles/RAM/whatever; turn off the eye candy and give me a product that actually works.’ I think this is a bit silly; I’m a far happier user when I use an attractive-looking piece of software, but to each their own. Vive la difference and all that. However, I get insanely frustrated when I read things like the following:

Don’t conflate Beryl with the silly effects like wobbly windows and raindrops making your desktop splash and windows catching fire when you minimise them and so forth. Those are neat for a few minutes and then quickly turned off. But Beryl can bring things to the table that are of real value, and it’s unwise to dismiss the whole think just because the parts that get exposure on YouTube are silly.

For example, when I hover my mouse over an entry in my panel’s window list, a live preview of that window pops up, so I can instantly tell (for example) whether a long compile process has finished without actually having to switch away from whatever I’m doing. Similarly, when I alt-tab to switch windows, what appears isn’t just the icon for each application, it also includes an actual scaled-down representation of each window, so I can tell which picture each graphics editor window is editing far more easily than just going by filenames. The ability to zoom in smoothly on a window is very handy when trying to debug graphics output, and conversely if I want the big picture I can zoom out and see all my desktops at once. (Forget the cube, I’m talking straightforward tiling – but it’s just as dependent on Beryl.)

What rubs me the wrong way, here, is that you can substitute Windows Vista in for every instance of the word Beryl above, and little will have changed. Live previews? Check. Alt-Tab? Check. The features present in this piece of software (which currently stands at version 0.2, let me point out) are shameless copies of Vista. This, of course, flies in the face of the countless posts I’ve seen mercilessly flaming Vista over the past couple years about its ’scads and scads of useless, GPU-sucking eye candy.’ Sigh. I just don’t understand the hypocrisy of this crowd at times. I’ll admit that Vista lacks the desktop-switching features built in to Beryl (which sounds neat, by the way).

Also, take a minute and look at the most popular themes available for Beryl today. I was shocked and amazed by what I found:

  • Community – looks fuzzier than Vista, but it’s the same damned thing
  • Melone – Umm, it’s Vista, but orange.
  • Nack XP – Hmm, it’s supposed to be XP. That’s just creepy.

Possibly Related Posts:


April 23, 2007

More on iRooster 3.0

I seem to have settled into a routine of working on iRooster for about 90 minutes every day. Unfortunately, I don’t have more time than that with my day job taking 11 or 12 hours every day (plus a few more hours on the weekend). Even still, I’m making great progress.

I intentionally broke the way that Snooze works three nights ago, and I finally repaired it last night around 1am. This was such a relief. The day before, I just turned off my alarm and almost missed a 9am meeting at work :)

Everything’s coming together smoothly, and I really only need to focus on polishing iRooster. For example, I need to add a timer to one feature so that it can automatically update itself every 15 minutes; another feature needs to check whether a network connection is available and just chill for a little while if it’s not; a third feature needs more polish on its custom drawing.

Of course, there’s a saying in software development: the first 90% of your product takes 90% of the time. The last 10% takes the other 90% of the time. I have some hope that I can curtail this to a certain extent. iRooster 3.0 is already looking great, and will really redefine what you might think an alarm clock can and should do for you, without getting bloated.

I’ll publish a post-mortem on the release once I’ve finished so you can learn something about what went right, and what went wrong (there are a few things that I find quite interesting, here).

Possibly Related Posts:


April 3, 2007

iRooster and Murphy’s Law

Even though it may not seem like it, I’ve been working feverishly on iRooster here in Chimp Software Headquarters (aka the Starbucks down the street, my couch, and Helen’s couch) ever since I released v2.4 back in January.

The Sad story of 2.4.3 – unintended consequences and all that

Last week started off with a trickle and then a flood of complaints about how iRooster was no longer working. It took me a while to figure out what was going on; everything was working just fine on my development machine. Finally, it dawned on me: a teeny-tiny update had been published for iTunes. Version 7.1.1, to be exact. This update, it turns out, had hosed every single user of iRooster who woke up to their Library. I wasn’t the only developer affected by this obnoxious issue. It’s a pity that app compat testing in Apple’s iTunes product group didn’t catch this, or that an errata wasn’t published somewhere really obvious to alert us to this sort of thing. Anyway, I promptly released iRooster 2.4.3 to compensate for this issue, and relaxed a bit.

Wham! Friday morning greeted me with a whole slew of crash reports for iRooster…Actually I was greeted by a host of crash reports for (null). Welcome to the land of unintended consequences, population: me. It didn’t take me very long to figure out what happened, but I never anticipated the issue that cropped up. This issue affected every user of iRooster, including those who were still using Panther.

I made a decision with the release of iRooster 2.4.1 at the beginning of March to EOL support for Panther, Apple’s 4+ year old OS. I support the current version of the OS and the one just past, and Leopard should be out any day now (I hope). Furthermore, some of the new features I’m working on absolutely require OS X 10.4 or above, I didn’t have a machine to test iRooster on Panther, and cutting support for 10.3 gave me the ability to use other handy-dandy bits of functionality, like NSDatePicker, whose introduction let me cut 2000 lines of code from my product (less code == less bugs and more time to make cool features).

Of course, it seems like really bad form to suddenly say to every user of iRooster still on Panther that “you’re gonna have to go buy a new OS in order to keep using your shiny $10 alarm clock.” Yeah, that’d fly. So, I did the only thing I could: I backported all of the bug fixes I made for 2.4.2 to 2.4.1, fixed the iTunes issues in both codebases, checked them into my source control tree as 2.4.3-Panther and 2.4.3-Tiger and released both as a single Apple Disk Image file (DMG). This DMG even had a snazzy-looking background and stuff. It’s pretty fancy.

I published the update to my website and updated my appcast file, so that my awesome Sparkle auto-updater framework (created by Andy Matuschak) would inform all of my users that a fix is available for their problem. Of course, Sparkle wasn’t quite sure what to do when it encountered an archive with two applications in it, so it crashed. This resulted in a flurry of crash reports for my application, (null). Good times.

After mulling over a number of solutions, I finally decided to repackage the Panther version of 2.4.3 as a zip file and publish it through my appcast mechanism. There’s no easy way for me to get any sort of differentiation between OSs to work, which means that I couldn’t selectively tell Tiger-hosted versions of iRooster to download one version, while asking Panther-hosted versions to download a different one. :( I investigated a few alternatives, such as detecting which version of the CFNetwork class was hitting the appcast.xml file, except that Apple doesn’t seem to publish the version numbers of these things anywhere, so I have no clue which version of CFNetwork corresponds to which version of the OS.

Version 3.0 – Featuring 25% more shiny stuff

Anyway, so that was Thursday and Friday of last week. Busy busy busy. I’ve also been hard at work on iRooster 3.0. I believe I’ve finally settled on a final list of features for the release. Some of them are obvious things that everyone using iRooster is clamoring for (see the forums for more on that), and some are features that you’ve never seen on any alarm clock before. I’ll give you a hint, though. iRooster is all about web services and flashy stuff introduced in 10.4. What kind of web services? I’m not going to say yet, but I think you’ll be pretty excited :) I sure am!

Here are the two features I’m willing to reveal:

  • Streamlined alarm editor – the old one has been around in pretty much the same state since version 1.0 shipped in 2003. Kinda lame. A reimagining of this UI is long overdue.
  • A resizable clock, and the removal of the mini window (or as they’d say in a bad 80s movie: two clocks enter, one clock leaves!)

Here are the features I’m not willing to reveal yet:

  • Cool thing involving a web service
  • Another cool thing involving a web service
  • Cool thing not involving a web service

;-)

I’m not really prepared to discuss the timeline for iRooster 3.0, yet, but I can assure you it won’t take nearly as long as 2.2 did. I’ve been working on v3.0 since February in fits and spurts, and it’s getting pretty close to Beta quality. I will certainly release a Beta version as soon as I believe it’s ready. I hope to publish the final release before the end of the month, but I have a lot of work in my day job that has to take precedence over iRooster (on a related note: let me know if you’ll be in Vegas for Mix’07 at the end of the month).

Possibly Related Posts:


April 2, 2007