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!

19 Replies to “Notification theme love”

  1. Greetings Aaron! Sweet style love applied there. You should try that running under upstream compiz (with DavidR’s new blur plugin). The opacity-dependent blur would make this look even slicker.

  2. Thanks for the patch! It would be very nice if distros didn’t have to always patch the theme.

    There’s a few bugs introduced by this that I’m looking into (the strip is too long on themes with X, Y hints, and sometimes the “low” urgency color is black for the first low urgency notification), but I plan to get this into the next release. However, I have to admit I don’t like the border colors and I wasn’t really ready for anybody to see the gradient code yet (I’m still tweaking the look), so I’ll probably end up adding a new key for the border colors and disabling some things by default for now. Before long, I hope to add a control panel applet for selecting the theme and options for the theme, so maybe some of this can be exposed.

    Thanks again for your work in this. I’ll probably have it in in a day or two.

  3. Btw: Christan, the control center crew is working hard on reducing the number of capplets. I also thing a capplet just for the looks of the notification bubbles is overkill. Perhaps it can be integrated into the Theme capplet?

  4. Looks good!
    I wonder if it would be easier to read of the translucency gradient was inverted – so that the centre of the bubble (containing the text) was most opaque.
    Currently, the translucency is such that writing behind the bubble shows up behind the bubble text, causing a little interference.

  5. Am I the only one who absolutely hates notifications? (unless it’s a critical notification).

    Seriously, all that cute little bubble does is steal your attention from what you were doing, to give you some (usually) useless message.

    Theming bubbles is just a crazy idea. It should inherit the look of the gtk theme, and any extra tweaking can be done by the theme designer on the gtkrc file (like slab, for example).

    Sorry if I sound trollish, but these things really do annoy me. Your shot looks very nice though. :)

  6. @thebluesgnr:

    Banshees notifications are optional. I very much like them. Other notifications I get are a) network manager releated (wlan disconnected etc, very helpful) and when unmounting mass storage devices which need data to be written (VERY helpful)

  7. > Theming bubbles is just a crazy idea. It should inherit the look of the gtk theme, and any extra tweaking can be done by the theme designer on the gtkrc file (like slab, for example).

    I agree, just put the theming options in the theme file, adding this extra configurability just degrades usability in my opinion, i guess if its hidden away in gconf its not a big deal tho.

    But anyway, I think this looks absolutely awesome, i was thinking only a couple of days ago someone needs to add something cool to the notification-daemon like this and in the last two days we’ve had two very cool improvements to it, well done!

  8. Very nice work! Keep on trying to get patches like this upstream. This kind of subtle polish is what will make the Open Source Desktop really shine.

  9. GConf is really the wrong approach to this. You should just use the existing GTK
    theme infrastructure. That saves you from having to reinvent color parsing, too.
    Plus you can use symbolic colors. Everybody wins.

  10. how can I apply this patch? I used patch in notification-daemon source then I installed it as usual and re-logged/restarted x
    it seems to have the gradient and all, but I don’t have the options in gconf-editor : just theme and location at root of the key “notification-daemon”… even when I edited notification-daemon.schemas in /usr/share/gconf/schemas…
    Also just a question that is not really related but anyways : can there be a “false” transparence using cairo if I don’t have beryl/compix nor aiglx/agl (just metacity) ?
    thanks, can’t wait to see the patch work here :)

Comments are closed.