Notifications again..
Christian: I think we really should define the notification “body” be HTML in the spec.. HTML is familiar and works okay for layout and it would give more possibilities for the application writer or a user writing scripts with notification support.
Also, we do not have many real-world examples of this stuff yet. Well, there is MSN Messenger and a few other things, and we know battery alerts could be useful, sure. New mail notifications, stock alerts, maybe. But when we talk about something really different, perhaps something we havent thought about yet, how do we know what is needed in the spec? If the spec is very liberal in terms of the layout and message content, it will not be the limiting factor later.
Why dont we just make the spec define that the message content can be HTML, according to some suitable w3c dtd. The notification implementations then should just strip off stuff they dont understand, thus making the currently proposed bold, italic etc work just fine, but without limiting the use to more interesting content. Also if we used Gecko, one could do the layout with CSS and it would be easy to theme the look. That would be very nice in my opinion.
So lets go for rich content.. 
September 20th, 2004 at 14:30
[…] nice mockups of a little notification baloon on his website. Today, he is suggesting that rich content via HTML is the way to go. I agree. Those things look awesome. Using HTML for the con […]
September 20th, 2004 at 14:44
How about using Jabber for passing notifications around over the network? It’s very easy to embed xhtml in jabber messages, as well as svg, for example.
September 20th, 2004 at 17:03
My geek sense is all a tingle a the though of XMPP being used in the notification system.
September 20th, 2004 at 18:38
Again, looks very nice.
To the other commentators on this thread, I believe D-BUS is the future for the passing/broadcast of notifications.
Also related, I’m not sure how specifically this fits in with applet notifications in GNOME, but freedesktop.org also has a spec for system tray notifications.
September 20th, 2004 at 19:12
I like the idea, Tuomas. I’m afraid it’ll end up being abused, but then we’ll just have to yell and scream to those projects. I’ll talk to Mike and see if he has any feelings one way or the other, but, man.. your mockups are absolutely beautiful
I still think actions should be separate from the content. In your mockup, there are actions above the “25 minutes …” line, which wouldn’t be doable in this case. I think making the actions separate are better for a11y reasons, and gives the particular notification server implementation the flexibility to do what they want there.
I hope to get 0.4 of the spec out this week. It depends on how much I have to do at work and how often I can get in touch with Mike, but hopefully soon.
September 20th, 2004 at 20:20
Hello Tuomas
Great mockup. What do you think about dashboard integration with the popup ? Taking your example, when Jeff comes online, the popup could show his communication status (IM, video email address, chat log), most recent blog entry and any other related info that may be available through dashboard (customizable hopefully. Don’t want sensitive information shown in the popup when the boss is around)
Cheers
Vivek
September 20th, 2004 at 21:11
vivek: That would be something some program could definitely do. The idea is to have a generic, desktop-neutral way of doing passive popup notifications, which is what Mike Hearn and I are working on. Anything, even a little bash script, would be able to pop up a notification. So, a program could work with Galago for presence and Dashboard for everything else (or just Dashboard, once Dashboard has Galago support) and send a notification popup using the information gathered there. It’s a cool idea, though not something we’d want to do in the notification implementation itself
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.
September 20th, 2004 at 21:19
Vivek: I’m all about integration, that’s the ultimate dream of mine. Mesh everything together. Like Christian explains.
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.
September 20th, 2004 at 21:53
Yeah, integration is great, when done intelligently. Fortunately, I think we’re in the right direction with this stuff.
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.
September 21st, 2004 at 07:05
Tuomas, Christian
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
September 21st, 2004 at 14:49
I think this is an excellent idea, however would speed not be an issue using mozilla/khtml libraries to display the content? Perhaps a custom simple css / xml / xhtml parser would be more beneficial - it would be tailored to only support the necessary layout functions. Or what about an extension to glade, but with more “graphical” components?
September 21st, 2004 at 15:42
Well. If gecko is heavy, would re-inventing gecko be any leaner?
Vivek: Yeah, I would love to integrate the “person” stuff from dashboard etc so that for example:
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
September 21st, 2004 at 20:13
I think that using gecko as the backend would really be nice, that way the notification area could use xul and also svg (when it’s turned on on gecko…).
This is really a place were gecko would be perfect.
September 21st, 2004 at 21:57
[Anonymous George says…]
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.
September 25th, 2004 at 23:27
Gekco is known to be pretty slow, so I don’t think it’s good to use it here. Besides, why force the user to use Mozilla?
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.
October 5th, 2004 at 01:52
The Gecko engine does seem like a bit of a bloat for this sort of thing. What about GtkHTML? (I personally love the idea of using CSS to style them, but can GtkHTML do this?) Are there any recent benchmarks on Gecko and/or GtkHTML?
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]