Banshee in Summer of Code (Not)

Banshee was rejected from the Summer of Code, as was GStreamer. I’ll just echo that having GStreamer rejected came as a bit of a surprise, and it would be nice to have some kind of justification. Some of the projects approved are rather “interesting” to say the least. I’m just curious as to what the selection criteria is, how selections are made, etc. Or maybe it’s not my place to wonder or care.

However, I have put a few of the more high-profile Banshee SoC ideas under Mono, and maybe one or two could go under GNOME as well – perhaps the more GStreamer related ones? Maybe there are already too many under GNOME? Maybe we’re not cool enough? I was hoping to put one or two under GStreamer’s SoC if Banshee was rejected – but we both lose! A little sad only because there were lots of existing Banshee contributor-students looking to hack on it with dedicated time this summer. I only applied because of their eagerness and community involvement.

If you have any exciting ideas not listed, we’re open to them, but the number of applications we can accept for Banshee under Mono will be limited compared to what we could have accepted if we were not rejected as our own organization.

Notification theme love

I recently switched from SLED 10 to openSUSE 10.2 on my primary work system. For the most part it’s an absolutely fantastic distribution, but in a few areas it does lack some of the polish that can be found in SLED. We make a very strong effort to move polish from the enterprise cycles into STABLE (the bleeding edge version of openSUSE), but sometimes things have to skip a cycle due to timing.

One such thing that has really been irritating me was the default theming of the notification daemon popup bubbles. We have a patch in SLED to provide bolder colors and borders that makes it look more appealing, and I wanted that back – especially because I am addicted to the notification support in Banshee, so seeing an ugly bubble every 5 minutes is not fun. Also there seems to be a bug in the 10.2 version that does not display pixbufs in the bubbles, which is really sad because I like to see my cover art.

So on the heels of Christian’s post about the latest notification-daemon release, I decided to start poking. Originally I was going to just bring in our SLED patch, but started thinking a little “broader.” Why do we even have a patch to change something like the color of the stripe? That doesn’t make sense. Does every distribution patch code to change the branding?

Anyway, I decided to start patching with upstream and the greater good in mind and added GConf support for changing some of the common elements in the standard theme. Opacity, urgency color, background color, a toggle to use gradients, and a toggle for showing/hiding the close button (we remove it in SLED for whatever reason). Along the way I also fixed a number of Cairo rendering and calculation issues that I ran into. The stripe gradient is also now a bit more subtle and is enabled by default in the build. It can be turned off in GConf.

Finally, because I couldn’t find such a thing in GTK+ (if it exists, please let me know!), I wrote a simple style color parser so distributions can specify color strings like bg[selected], base[active], or dark[normal], which end up resolving to colors defined in the current GTK+ theme.

Here is an obligatory screenshot and screencast. Click the screenshot below to download and watch the screencast.

Standard Theme Love (3.3 MB, Ogg Theora)

So the whole idea behind this is basically twofold:

  • I wanted more polish and bling – I like nice colors and subtle gradients
  • I don’t think distributions should have to patch the theme code to change simple things like colors, enable/disable gradients, etc.

If this patch goes in upstream, all distributions will have to do to brand the notifications in the standard theme is ship a different GConf schema. The branding/color support can parse relative theme/style colors and anything else that gdk_color_parse can, so it’s a win for blending in with the current environment if you’re anit-hard-coded-colors.

I’ve filed a ticket in Galago’s Trac with the attached patch and I look forward to working with Christian and others involved upstream with moving this forward. No more pointless distro patches for changing colors! What started this morning as scratching an itch I hope can actually become something useful for the masses.

I also need to say that notifications are oh so slick and I can’t imagine a distro without them these days. I can’t wait for more applications to start taking advantage of the support either the daemon (over DBus) or the libnotify library can provide. Awesome release Christian!