KNotificationItem class name is confusing

[Aurélien Gâteau]

Aaron J. Seigo a écrit :
> as for its relationship to notification, Davide Bettio has a patch that allows 
> one to associate KNotifications with a KNotificationItem as well as set a 
> KNotificationItem as the default for all KNotifications from a given 
> application. add to this that everything the DBus spec does is advertise 
> information and push updates about the status of application. so it's not 
> completely unrelated to what we currently define as "notification".

The fact that they can be associated does not mean they should have
similar names. Using the "Item" prefix is all the more confusing that
it's widely used within Qt to denote an element inside a container
(QListWidget and QListWidgetItem, QGraphicsScene and QGraphicsItem,
QStandardItemModel and QStandardItem). It implies a KNotificationItem is
part of the KNotification container.

> concerns around the fact that it can also be for interaction purposes is a 
> non-issue in my opinion. the interaction features are there because it is 
> convenient and sensible to interact with the item that tells you about 
> something; the interaction feature should not be the primary reason for using 
> this class however.

Agreed.

> i do like the names with "Status" in them more than the other alternative 
> suggestions. possible names that would be both accurate and meaningful might 
> include KApplicationStatusNotifier, KStatusNotifier, KStatusNotificationItem 
> ... ? i'm not sure using the term "Workspace" in there makes much sense, and 
> saying -what- status is being communicated might be useful, though probably 
> not critical.

I thought Workspace was a nice way to imply that this item would be
represented on the workspace rather than inside the application itself,
but my only concern is to avoid confusion within the kdelibs API. I
think any of the suggestion you provided are fine for me.

Aurélien