KNotificationItem class name is confusing

[Aaron J. Seigo]

On October 28, 2009, Aurélien Gâteau wrote:
> 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.

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.

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. that's not accidental, 
btw, that's one of the specific use cases we talked about at Tokamak II in 
Porto when designing this thing in January of '09.

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.

> > 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.

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.

-- 
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA  EE75 D6B7 2EB1 A7F1 DB43

KDE core developer sponsored by Qt Development Frameworks
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20091028/782d275a/attachment.sig>