Bug 108076

I have known knotify for a while :) but instead of popups, couldnt we have the notifications of applications like the amsn user has logged in notification (probably at the taskbar area instead of the obtrusive popup.) The notification area on the corner of taskbar to me seems ideal for program notifications like the amsn user logged in or xyz says:....

An example would also be the windows xp/2k identification when a usb or external device is connected but at a much higher level.

The colour of the popup on the corner of the taskbar would indicate the severity of the progam requiring the users attention.

It can be flexible and allow embedding of images, text, buttons and other items so as to make it flexible.

It could also provide notification of new usb images disconnected/connected and syslogs etc.

There also needs to be a cleanup of the ui (knotify) for creating such an application.

Probably could also use superkaramba for notification

Any comments

The current framework lacks features in many areas so that developers began to invent their own solutions. Examples are the OSD of amaroK, bubble tray popups of kopete and the OSD of kmilo, just to name a few.

A new framework should make visual notifications themeable and should solve a usability issue which seems to be very under underrated: Notifications disappear within a very short period of time and you have no chance to see them again. Think of people with bad eyes who can't read that fast or the average Joe User who doesn't look at the screen for a couple of seconds. One should be able to see the last few notifications again. Consider a flashing button in the tray or maybe a section of the sidebar, where the last few notifications are displayed (just an example).

What I like best at KDE are the powerful frameworks (and therefore code reduction, fewer bugs and consistency), but knotify is definitly the one that needs a lot of work. I hope, someone picks up the work on it for KDE4.

Configuration option per application and/or popup (visual notification) type: PERSISTENT (=remaining on screen, until dismissed).

In my vision of configurable visual notifications, I imagine the ability of applications to register to the notification backend with their name and types of popups (notifications). If the user wants, he can select certain (or all) notifications for an application to remain on the screen, until they're dismissed manually.

*** This bug has been confirmed by popular vote. ***

How flexible should this be? Looking at the Growl screenshots, there were several different modes offered. I do not know how these modes are invoked (if they are user-set, or forced onto the user), but I think having a nice, pretty notification that is uniform looking would be great.

Currently, KDE (3.4+) has a nice, universally changeable-by-theme, notification box for mouse-overs in Kicker. This even includes a graphic, easy-to-read heading, and an easy-to-read description. This is already about as pleasing as the amaroK OSD (though the amaroK OSD, I believe, lacks a heading-text concept). This is worlds better than the tooltip-like mouse overs kmix and amaroK use in Kicker.

Can code from this Kicker mouse-over feature be adapted to make a general pretty notification display? What does the mouse-over feature lack visually that applications might need? (I've only used Kopete, amaroK, and Kaffeine, and can personally only draw from them.)

More info/mockups and discussion here: http://www.kde-artists.org/main/component/option,com_smf/Itemid,48/expv,0/topic,141.0

Q: How flexible should this be? Looking at the Growl screenshots, there were several different modes offered. I do not know how these modes are invoked (if they are user-set, or forced onto the user), but I think having a nice, pretty notification that is uniform looking would be great. 

A: It has been been brought to my attention that the application is only responsible for asking for popups. The drawing is by no means influenced by the application. Growl allows, in its configuration, to set the "theme" for each application notifications.

This brings up a quite interesting aspect. In order to get a consistent desktop, the applications should not be allowed to alter the popup (notification) besides:
* text (note that the text could contain some kind of hyperlinks, sending back signals/calls to the client application using some API)
* popup title
* icon (picture)
* time until the notification expires (as I've said before, it should also have the possibility to never expire) - this setting could be overridden by the knofy cofiguration (per application, or globally).

Everything else (theme, position etc.) should be left for knotify do deal with.

I like having a standard notification place, and I like the idea of colors for "severity". I.e.:  Gree = Informative -- Blue = Informative and user interaction needed --  Red = Error


I'm voting for this. Perhaps that notification would be cool if it would gets some plasma love.  Aseigo... here it comes!!

>> Everything else (theme, position etc.) should be left for knotify do deal with.

I think it would be good if each application could set position. Maybe I want to separate Kopete's  popup with the rest, so set the position to top right corner instead of bottom right, where all the other popups appear.

Otherwise, I agree with you.

>> I think it would be good if each application could set position. Maybe I want to separate Kopete's  popup with the rest, so set the position to top right corner instead of bottom right, where all the other popups appear. 

If knotify will deal with themes (like setting a global theme, and a different theme for a specific application), then I think it would be more logical to set the notify position of that application in knotify too.

This shouldn't be difficult with Plasma, similar to Device Notifier Plasmoid.

However, correct me if I'm wrong, couldn't just knotify communicate with Plasma, maybe with it's own containment, nor the Panel, nor the Desktop. Or you could simple add a non-visible plasmoid that have a pop-up, just like Device Notifier.

*** Bug 159038 has been marked as a duplicate of this bug. ***

*** Bug 170136 has been marked as a duplicate of this bug. ***

It is now possible thanks to the new notify dialog :-)