Called Paint, the idea is to have four main colors at the edge of the screens. By the phone's tilt, those colors will bleed into the screen itself, causing the animation, and interactivity with the phone regardless of whether or not you're actually accessing an app. The LWP actually becomes as fun to use as anything else on the phone.

The basic setup is contained in this Gist.  There's more to add, but I made my quota for the day, and I want something to work on tomorrow.

I'm giving myself a challenge, and having my blog (Corner of Seven, for those of you reading this via Facebook) become the record of my success or failure of this challenge.

Starting today, my goal is to write *at least* 50 (fifty) lines of code per day.

This idea came about through the previously mentioned "Don't Break the Chain" post on this blog (which worked oh so very well...),  and a recent experience that I had at work.

Most of my work duties are currently system configuration and setup, and less actual development on said systems.  With that, my ability to get code written has diminished.  I was asked recently to create a component in our software that renamed a file going out, based off of metadata contained within that file.  After sitting blankly at the computer screen, with my brain screaming, "I know what to do!!!!" and my hands frozen, unable to regain the muscle memory of the common actions of Java, I looked inside, and realized this had to change.

In a sense of betterment, I want to complete at least a small project daily.  Maybe it's a coding kata. Maybe I work on stuff in Android.  Maybe I continue work on RBEQ.  Maybe I add new things to Corner of Seven.  Maybe it's something I haven't even thought of yet. All I know is that new code needs to come out of me, before I can't do it any more.

Fortunately, I have tools at my disposal.  The afforementioned projects can keep me busy for a while, but what do I have to show the work that I've put in? Enter the Gist system at GitHub. This allows you to put small snippets of code out, configurable by language; it gets your code available on the internet, and embedded into a blog or webpage.

So there you have it.  Look to see some Gists from me shortly.

Cheers!

1.4 of the RBEQ, the Rhythmbox Equalizer, is out and ready for download. The big change here is a switch from storing presets in a flat file to using the GStreamer Preset system. As always, downloads are at RBEQ Google Code.

A big thanks to Stefan Kost, who left this gem of a comment on the 1.3 release posting:

Any reason, you are not using the presets shipped with the gstreamer plugin?
Look at /usr/share/gstreamer-0.10/presets/GstIirEqualizer10Bands.prs and the GstPreset interface.
Users can install own presets to $HOME/.gstreamer-0.10/presets/

Since I didn't know anything about them, after looking at the aforementioned docs, I've gotten things so that they use the GStreamer Preset interface, and it is more well-behaved.

Also a big thanks to Hicham HAOUARI, whose awesome work has gotten RBEQ into Fedora! That's awesome; I was nearly flabbergasted when I saw that. Thank you for the support!

Comments and bug issues are always welcome; please let me know what you find while using it.

The previous statement isn't much of a surprise in this day in age, but I think I should qualify what I mean.

I've been having a lot of fun playing with the software internals of my new phone.

The Motorola Droid has been quite the versatile little device.  I've thrown nearly all I can think of at the thing, and it handles it smoothly and without issue.  In the past 4 weeks, I've rooted, flashed, reflashed (I'm indecisive), cleared, recovered, flashed again, and customized to my heart's content. Currently, it looks like this:

That's right... Shiny.

There's a fantastic community of people who create and contribute to these modifications over at alldroid.org, particularly in the forums.  I've met some good people out there, who really know what they're doing.

I recently dual-booted my desktop, so I could get back in and do some fun playing around.  Unfortunately, I chose a 64-bit operating system, and they're not supported for the android source tree and utilities. (A poor excuse, I want to see what I can do to fix that.) So I've been debating the past couple days, whether or not to clear my new install, and put on Ubuntu 32-bit edition when it comes out, so that I can tear into the source and help contribute to the site.  Most likely I'll wait until 10.04 (Lucid Lynx) comes out; I've loved what I've seen and played around with so far, so it'll be good to get in there and play around with my phone's internals.

One of the big requests on the alldroid forums is the ability to hot-swap phone ROMS without the need for a full reboot.  I think I have an idea on how to accomplish that.  In the same way that the Xen environment handles virtualization, we need to create a custom kernel that handles virtual ROM running. There would obviously be a performance hit, but with people overclocking their droids to 800MHz up to 1.3 GHz, I don't think there would be much complaining.  Basically, we need to let the ROM handle hardware switching from one ROM to the next, and let the internals provide the rom connection.

Just having ideas.  Others include a complete revamp of the Web, and a new OS.  I'll get to those at another time.

Other phone screenshots:

A new version of RBEQ, the Rhythmbox Equalizer plugin that I've been hacking away at, is out for public availability.  Of course, this means that I have to go update all of my previous links to point to the new download.  For ease of accessibility, you can find it at http://rbeq.googlecode.com, as the featured download. Installation instructions are the same: download the file, open a terminal, and type:

tar -xvzf rbeq-1.3.tar.gz -C ~/.gnome2

New in this release:

• The ability to save and load presets.  This has been a big request, and I finally found a decent way of handling it.
• Layout cleanup and arranging to add in the new preset functions.
• Backend code cleanup, so that it behaves more python-y.  I'm not a python programmer, so this has been a neat experiment in trying it out.

Thanks to all out there who have used and enjoy the past versions of this plugin.  Hope that the new one is to your liking.

Little did I know that it was going to become a rather taxing endeavor.

The first step has been figuring out the best way to generate heats.  Given m entrants and n lanes, there must be m/n, rounded up, 'heats' in order to make sure everyone has raced the same number of times.  Some of these heats would be less than the number of lanes, but should be set up to be not only most fair to racers, but keep the scoring as even as possible.

I started out to see if, given m entrants and n lanes, if it was possible to have a true round-robin tournament; that is, make every racer have a race against every other entrant, and have each racer have the same number of races.  That would make the calculations for the winner the simplest.  Unfortunately, while easy on paper, it becomes impractical in real life.

For example, say we had 8 racers on 4 lanes.  In order to achieve a true round-robin state, we need to have ₈C₄ races, or 70 heats, in order to satisfy the above conditions.  Now, in practicality, do you think it's possible to have 8 elementary school students sit patiently enough through seventy races?  I didn't think so either.

My current goal is to make a heat generator out of some form of predictive system.  Using a map of entrants to see how many times one has competed against another, the generator picks the least raced candidates, in order to keep fairness at a maximum.  There are some other things to take into account for the day, like damage, re-races, and run-offs for ties, but those become part of the operation logic.  The true core of this is creating the heats for each level, and keep track of the points received for those races.

Found on http://www.makinggoodsoftware.com/