KNotificationItem class name is confusing

[Marco Martin]

On Thursday 29 October 2009, Aurélien Gâteau wrote:
> Aaron J. Seigo a écrit :
> > well, it is an item in a collection (on the session bus). it just isn't
> > in a collection called a KNotification (which is perhaps a slightly
> > unfortunate choice of names in itself). in any case, the relationship
> > between KNotificationItem and notifications is actually a lot stronger,
> > at least potentially, than you seem to recognize.
> 
> I have no problem with having "Item" in the name (my favorite is
> KWorkspaceStatusItem), I am concerned with the "Notification" part.
> But yes, I confess I do not see the relation between the two, and I am
> afraid I am not alone.
> 
> > 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

a similar integration that could be cool is with the job progress 

> 
> I believe MI could be implemented using KNotificationItem if the
> protocol gets extended (and I even believe it should be eventually
> implemented this way rather than the way we did), but it can't be done
> right now.
> 
> > so i'd personally like to keep the idea of "notification" in the name,
> > otherwise this whole misunderstanding about what a complete notification
> > system entails will just continue on and on, aided even by the names of
> > our own classes!
> >
> > in that light, KStatusNotifier is my current favourite for any of the
> > suggested alternative namings offered so far.
> 
> Not my favorite, but it is not confusing, so I think it's better.

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

Cheers, 
Marco Martin