Kubuntu: Ayatana has arrived

Unless you’ve been living under a rock for the last half year, you’ve almost certainly heard of Canonical’s Ayatana Project. At UDS Karmic in Barcelona we spent quite some time working out the best was for Kubuntu, KDE, and Ayatana to work together. We came up with a plan.
This plan gives Ayatana room to innovate and explore new concepts, preserves Kubuntu’s position as a very upstream KDE focused distribution, and makes it easy for Ayatana’s good work to benefit upstream.
We didn’t agree on everything, but we did agree on the idea that a user’s notifications should be consistent. From a Kubuntu perspective this meant that if a user was using a non-KDE application in a KDE session, then notifications should look and feel KDE like.
I gather it took quite some discussion on the XDG list to get agreement on how to achieve this, but Aurélien Gâteau has now landed patches in KDE svn (for KDE 4.4) and in the Ubuntu archive for Karmic (KDE 4.3) to enable this [1] [2] [3] [4].
I think this is a great first step for Ayatana, Kubuntu, and KDE. I look forward to more.
[1] href=”https://launchpad.net/ubuntu/karmic/+source/kde4libs/4:4.2.96-0ubuntu5
[2] https://launchpad.net/ubuntu/karmic/+source/kdebase/4:4.2.96-0ubuntu2
[3] https://launchpad.net/ubuntu/karmic/+source/kdebase-runtime/4:4.2.96-0ubuntu2
[4] https://launchpad.net/ubuntu/karmic/+source/kdebase-workspace/4:4.2.96-0ubuntu4


6 Responses to “Kubuntu: Ayatana has arrived”

  1. 1 MrS July 17, 2009 at 16:34

    Does the Kubuntu team plan to implement the actionless notifications adopted by the Gnome half of Canonical?

  2. 2 ScottK July 17, 2009 at 17:09

    That’s a controversial point. Part of the plan for Kubuntu and Ayatana linked above is to have a special set of ‘Ayatana options’ or a ‘Ayatana session’ where non-standard things like this can be available for users that want to try them.
    I suppose it’s possible we’d adopt them if it got good user feedback, but it’s certainly not a given.

  3. 3 Jim July 17, 2009 at 17:15

    Yes, that’s the question. If they do and it’s not optional, then I may have to consider switching to another distro. I haven’t tried it yet, maybe it won’t bother me as much as I think it will.
    The whole idea seems odd to me. Notify me of something, but don’t let me interact with it? I like the fact that KDE’s notifications can be clicked on to bring up the related application or dialog.

  4. 4 ScottK July 17, 2009 at 17:19

    I agree it’s an odd approach. The design point they are trying to achieve, that the user shouldn’t feel rushed to react to notifications is, I think, a good one.
    There is, however, more than one way to solve that problem and hopefully in the KDE side of things we can do better.

  5. 5 Bugsbane July 17, 2009 at 23:13

    But as long as you have an easily accessible list of what notifications have been shown, I don’t see why anyone would ever be “rushed” into taking action on a notification.
    Something happens while you’re away. You get back and notice something like a flag where the (i) systray icon currently is. You click on it and see the recent notifications. No pressure at all.

  6. 6 sebas July 18, 2009 at 21:38

    Whether or not notifications should have actions is something that needs to be sorted out cross-desktop. In that regard, it’s of course less likely for KDE to adopt it as GNOME and XFCE upstream has basically rejected the idea so far.
    The problem is that if some environment support actions and others don’t, application developers have way more complexity to deal with, which is not what we want. Sending out notifications should be as easy as possible and reliable for app developers. Just stripping out actions won’t work either as the text of the notification might refer to an available action. If this action is not there, the application is simply broken by stripping it. So you cannot solve this problem just from a renderer, which is the role of Plasma in this play.
    Most of the work of removing actions from notifications would be reviewing apps and find good ways for the apps to do their stuff. I surely think there are applications that would benefit from a streamlining of their notifications. Just slaughtering those out won’t work. Likewise, there are probably notifications that could well *use* an action on a notification that doesn’t have one yet.
    From a design point of view, it’s largely moot. A lot boils down to “how do we display notifications”, and I surely think we can improve this. Also, the mock-ups that propose ways how to do “notifications when you *really* need an action” would look a lot more plasma-ish in KDE, at which point the visual appearance might not be so different.
    Improvements on making those visual notifications slicker are more than welcome of course.
    On top of all that, KNotify is much more than Visual Notifications alone. It’s an interface to all kinds of notifications and events. A notification as an information bubble is only one way to “render” the notification, it could also play a sound, log it, or execute something when the notification is triggered. All of that is configurable per notification event. It’s built with flexibility and accessibility in mind — which is much more than the Ayatana vision of visual notifications.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s


%d bloggers like this: