KNotificationItem class name is confusing

[Aurélien Gâteau]

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?

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.

>>> 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,
> 
> there is nothing in the class or the dbus specification that says that this is 
> going to be represented in the workspace. that complete lack of "this is how 
> or where this data is going to be shown" is absolutely intentional.

My idea on this was to imply that the application developer does not
control how it is going to be represented: it's up to the workspace to
place it and represent it.

> as a general philosophy, i think we ought to stop thinking about how things 
> will be presented visually to the user unless we are working on the actual 
> visualization itself. instead, we should concentrate a lot more on the data 
> being published and how that is accomplished. it can prevent assumptions that 
> are often incorrect from being made in the first place and makes it easier for 
> us to design systems that are able to be re-purposed in the future in ways we 
> haven't even thought of yet.

I agree. This is something we already do for icons (naming them
according to the concept they represent rather than the visual metaphor
they use to represent it).

Aurélien