KNotificationItem class name is confusing

Marco Martin notmart at gmail.com
Thu Oct 29 18:08:07 GMT 2009


On Thursday 29 October 2009, Aurélien Gâteau wrote:
> Marco Martin a écrit :
> > On Thursday 29 October 2009, Aurélien Gâteau wrote:
> >> Aaron J. Seigo a écrit :
> >>> for instance, the whole message indicator plasmoid you wrote could be
> >>> completely, 100% implemented using KNotificationItems with associated
> >>> KNotifications used for the sporadic/temporal events.
> >>
> >> This is a bit off-topic, but I would like to ensure I get it correctly.
> >>
> >> There would be one KNotificationItem per app (== server in Message
> >> Indicator (MI) speak), and each indicator would be represented by a
> >> KNotification? This would mean a KNotificationItem contains
> >> KNotification instances?
> >> How would you assign a KNotification to a particular KNotificationItem?
> >> How would you represent concepts such as indicator count or indicator
> >> time?
> >
> > an application in theory can have more than one notificationitem, but the
> > usual case is one, yes
> > the idea is to associate globally to the KNotifications of an app a
> > KNotificationItem (that can be the only one, usually), then when a
> > notification of an app pops up it can automatically set the status of the
> > notificationitem to requestingattention
> > a next step can be making the notificationitem to know all the
> > notifications in this way it will be possible to show only notifications
> > associated to a particular app, for instance instant messaging, so here
> > we have also the knowledge about how many messages there are and when.
> >
> > A way, perhaps, once KNotification has a default knotificationitem set
> > globally a KNotification could add itself to that kni upon creation. then
> > what would be need is a way to display -only- those notifications
> 
> OK, so Message Indicator could be implemented using KNotificationItem,
> but it would require significant changes.

well, yeah adapting a system to another usually turns out  to be a bit 
painful, a bonus we could have from this however is to not require extra api 
from the applications to learn

> > since a name of the main thing implies also the names of the two other
> > components, the set could be:
> > -KStatusItem, with StatusItem dbus interface
> > -StatusHost
> > -StatusWatcher
> >
> > StatusHost and StatusWatcher could even become StatusItemWatcher and
> > StatusItemHost, to make clear they are part of the same thing
> 
> Sounds good to me. As I said, I would like to help making the necessary
> changes. I should have some time tomorrow to help if you are available.

deal :D

-- 
Marco Martin




More information about the kde-core-devel mailing list