The D-BUS idea was a good one ([i]Chris[/i]). A generic notification mech. could be implemented. That way, the KDE guys could have their own notification “listener” if they want it, and the XFCE guys could have their own… etc. Or the user could install whatever notification “listener” they prefer.

[i]Fantastic work, tigert![/i]

Don’t get me wrong, I am a Mozilla user. But some people aren’t

I’m not quite sure HTML is a good idea either. I’m not sure, but I think that some XML templates can serve better here. I feel that HTML is bloated in a way, when used here. There’s not need for HTML. CSS, though, can be nice, but I think it should be part of the template, not the content.

Agree fully on this. From my position in the stands (currently a spectator at the moment), I think because you already have Epiphany and a movement by Mozilla/Firefox to move towards Gnome (not excluding KDE, of course, also), why not have a backend for Gecko? Already it’s pretty well optimized, at least to me, and can always be improved and optimized more. And then it’s just ready.

While on that point, has anyone thought of creating a “branch” of Gecko so we just have a Gecko library, like what Apple has with the WebKit library (independent of Safari), that applications (e.g. Epiphany, Yelp (future?), the notification stuff, etc…) could easily incorporate? Even though Gecko makes up most of the Mozilla/Firefox package, at least it would theoretically just strip the frontend and allow for extensions without the added weight of the frontend. Maybe that’s something more to be done with Mozilla, rather than Gnome, but it’s something I’ve wondered about for a little.

Good luck on getting things going with notifications. That’s DEFINITELY going to be awesome.

Vivek: Yeah, I would love to integrate the “person” stuff from dashboard etc so that for example:

I define a rule in Evolution that I want a notification when I receive an email from a certain person

When the mail arrives and Evo processes the filter, the notify “thing” would query something for relevant status information about the person

The result is a popup: “Hey, new mail from Nat!” with a subject and a snippet of message body, plus a nice “Nat is online!” indicator with links for aim://, mailto:// and whatever ways there are to contact the person..

Sure, it could be done in different ways, but I fear it we want to design something “the right way” there is danger we never get anything for people to play with - and we dont know what we will do with this stuff in the future anyway. It takes other folks to bring new ideas into the thing - and so that existing software projects can add notifications. That’s why I think it needs to be flexible - to encourage new ideas. We just keep the good ideas after the dust settles

Sorry if did not express clearly. I do understand this is a generic framework (and I do plan to read your spec about it). My comment was only to express a desire to see a mockup of a ‘fictional’ dashboard information shown in the popup. In simpler words, Tuomas, can you update your mockup, if possible, to show how a simple dashboard integration ‘could’ look like ?

Cheers and keep up the excellent work.
Vivek

There are going to be a lot of cases when we wouldn’t want to embed dashboard (etc) stuff in the notification. That’s okay, though. We could have a separate API call in a library somewhere that gathers related info using dashboard and friends and puts that in the notification. No problem.

I think the HTML idea is good, as long as we make sure it’s not a requirement. I don’t know what the KDE people can handle, or console, etc. My real concern with the HTML idea is the speed, but we’ll see how well it works in real tests. If things work fine, I’m for it.

Christian: Sure, stuff could be abused, but then again, sane apps can always conform to rules - I mean, you have gcc, you can always abuse specs and guidelines - For this reason I think the content of the message should be separate from the “transport” mechanism in a way - it would be nice if somehow we could embed the dashboard etc stuff there - for starters I think HTML is suitable since it will not be a too big limiting factor. The goal is to not abuse, but to have enough freedom in the implementation that we can try out new things, not limit our imagination here. It’ll settle down when we learn what can be done and such.

Another cool thing would be to have some fields in the Planet RSS feeds that show vcard info with IM accounts or names or whatever. Then that could be used to query Galago, and other stuff. Mmmm, the possibilities for cool and useful integration.