Month: December 2008

Some notifications updates

I did get a few details wrong, and people have came to me and told me, and I am very glad that I did get them wrong.

First, the legal problems were copyright disclaimers, so they’re no big deal here, typical stuff, which is a HUGE load off my mind. Thank goodness for that.

Secondly, the code is still in very bad shape and was mainly for demonstration purposes with the development team and the UI team, which is also okay; the demo actually made it look more complete than it turns out to be, which is also a good thing because it will mean lots of chances for people in the GNOME community to get involved. I am so enthused to here this!

Thanks for everyone for clearing up details for me; always feel free to reply to me and make sure that what I’m saying is correct. (I’m factually wrong all the time, just don’t sue me ;).

Edit: Also, I was told that this code may go under GPLv3, which very much excites me so this code will be truly free. This really does make me feel a whole lot better about the whole situation. Thanks again everyone.

New Notifications for Jaunty

The big innovation (and controversy) coming out of the Desktop Experience team here at UDS seems to be the new notifications work going on. This is a big concern of mine, as I’ve worked on that code locally, and have definitely wanted to see some progress here for ages. Unfortunately, the upstream is more or less dead or limping due to conflicting time constraints on the lead developer, Christian Hammond.

Weighing in, I think that Canonical’s work here is looking really good, and has a wonderful design, but I do worry about some of the edge cases. The biggest other concern is that no effort until recently was put into contacting Christian Hammond at all, so it’s essentially a fork/reimplementation, even if it is one that makes sense due to upstream’s stagnation (until recent developments). Now that Libnotify and Notification-Daemon are up for proposal for GNOME 2.26, it’s only now that we’re looking into replacing it… It’s both unfortunate and opportunistic of Canonical to pull this out of their hat at UDS.

For those that are not here at UDS Jaunty at Google, it is important to understand some of the changes that we have discussed here. The first of which is the removal of “Actions” from notifications. This means that there will be no more buttons inside the notifications at all. The way that applications currently use libnotify is somewhat abusive to the original spec, where they should query for capabilities and then use an action if the daemon supports it, but changing the daemon now to simply never show actions will likely leave you with notifications that say “Please click the button below”, and there is no button to press. Bugs to be filed, users to scream at us…

Notifications now are simply there to show you the data about what’s happening on your machine. This can happen in two ways; Synchronously, as you press a button like the volume or brightness controls, the notification comes up and shows you the change, and “normally”, how instant messengers like Pidgin with the libnotify plugin currently work.

Instead of having “Actions” inside of the notification window, they will be moved to a panel applet, which will allow you to get to the application in question by clicking it. There have been a lot of discussions on what this panel applet will be like, but it is probably the biggest missing component in the discussion so far, since we haven’t seen any prototypes on it, or what it’s interface will look like. The Design team that’s working on this seems to be doing so behind closed doors and beyond all contact by mere mortals like myself.

So, despite the conflict of the Bazaar vs the Cathedral in the situation we’re in, I’m feeling pretty good about the general work being done. I’m really hoping that I can be a part of it and it won’t be this cabal-like situation where I have to bring patches to Canonical’s door and sacrifice a goat in offering to the Gods of the New Notification Daemon. Or, you know, I could always get off my bum and send my resume in ;).

*: I had planned to insert all kinds of wonderful pictures and a link to the wiki here, but unfortunately Google has outright outlawed the usage of cameras inside the buildings on their campus, and Canonical has to wait for some more design work before the wiki is up. GNOME community developer 0, Enormous Global Companies 2.

Buzzer Beater

I have been rather quiet on the code frontier lately. It’s not a result of anything more than working on my own personal projects and spending entirely too much time away from my computer. (That and getting everything in order for UDS.) So I decided I’d share a teensy, tiny bit of what I’ve been working on, since I’m excited about it…

Some time ago on the Nautilus mailing list, the discussion came up about so called “Miller Columns“; Apple calls this “NSBrowser”, and it has a ton of history as far as tree visualizations go, dating back to the Smalltalk guys in the 70s. I managed to bang together a little demonstration that took only a few hundred lines of C (I had some weird problem with Vala that it didn’t want to work back then). It looked like this.

I coded that up, and promptly forgot about it. I thought that actually implementing it correctly over GtkTreeViews and GtkTreeViewColumns was going to be an absolute nightmare, and I thought nothing more of it.

Until my pet project needed a way to visualize a tree of items. Sigh.

The basics of the beast work fine, but there are still a ton of details to work out before it’s up to snuff for my project (and who knows, maybe Nautilus next?) The TreeView itself is an HBox, which has a new TreeView packed in every time the selection changes and any views further down the widget are destroyed. Each TreeView has a model that is set from a filter model of the previous model, so that we’re only seeing the section of the tree we want in each cascaded tree.

The columns were actually the biggest problem I hit, as you can’t add a GtkTreeViewColumn into multiple GtkTreeViews; instead, I created a class that has almost the same interface as GtkTreeViewColumn (with some details needingly removed, and some details left to be reimplemented under the new class), but creates a new column every time a new GtkTreeView is packed into the parent TreeView. All of the new columns properties are linked to the central column, such that when someone changes the TreeViewColumn in any way, all of the created TreeViewColumns are also automatically updated with the same details.

It’s still very much a work in progress, and it needs a good cleanup before I go any further on it. But it was interesting enough for me to want to share it. If you’re interested in any more details, you can email me about it or find me on IRC. For now it’s shelved so that I can go back to work on hating GooCanvas’s silly canvas API and my pet project (and yes, I’ll announce more details when it’s actually more than fairy dust and graphite on sheets of tree).