KNotificationItem class name is confusing

[Aaron J. Seigo]

On October 29, 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.

ok, here's an "executive summary":

* to most people, notifications are messages they get from "the system" about 
things that are going on. any more precise differentiation beyond that is 
vague to them (e.g. whether the notice happens because kmix puts a message or 
tooltip on its system tray icon or because kded emits a knotification about 
the audio hardware changing is not visible, let alone obvious, to them)

* status notifiers exhibit useful information such as "i am now actively 
indexing your files" or "the wifi signal is 90% max strength" or  "your volume 
is muted". given that these items are changing in a visible area of the 
workspace, they are as much "notification of things happening" as our textual 
notifications that pop up in little bubbles or windows are.

* we have patches being worked on that allow a KNotification to be associated 
with a given status notifier; this way if the audio device changes a 
visualization for the audio system (e.g. the systemtray showing kmix's 
KStatusNotifier) could elect to show that notification as part of or 
associated with the audio system status notifier. this way, all "audio stuff" 
happens in one place as far the user is concerned.


(and yes, we all recognize that the previous implementation of the system tray 
icons made this a much less clear issue and much more confusing to figure out.  
:)

> > 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), 

as Marco noted, there's no reason that there couldn't be more than one for an 
application. maybe akonadi hosts all of them for us, even. this is a detail, 
however, that the workspace component should not worry about. it just knows 
that there is a collection of KStatusNotifiers that are all tagged as being of 
type "Messaging". awesomeness.

> and each indicator would be represented by a
> KNotification? 

no; each indicator would be represented by the KStatusNotifier. by convention 
or by explicit design (up to us how formal we would want to make it) 
information associated with the KStatusNotifier, such as the tooltip perhaps?, 
combined with information such as KStatusNotifier::state() & Active (or 
whatever that code actually looks like) would be used to show the current 
status (if any) of things.

> This would mean a KNotificationItem contains
> KNotification instances?

the current draft we have just allows you to point a KNotification to a 
KStatusNotifier which then results in an association.

> How would you assign a KNotification to a particular KNotificationItem?

there would be a reference in the KNotification information published on the 
bus to the KStatusNotifier it should be (optionally) associated with.

> How would you represent concepts such as indicator count or indicator time?

the time is implicit isn't it? e.g. when the notification is sent or received? 
(i'd personally like to see timestamping added to notifications in general; 
gives us more options in other areas as well)

as for total count (versus just counting the # of outstanding notifications), 
that could possibly be left up to the individual app to figure that out, but 
that doesn't help if you want show an aggregate number. though i'm not overly 
sure how useful "180 messages" would be if 2 are emails and 178 are facebook 
IMs ;) at first thought, though, i think a numeric quantity indicator could 
make a reasonable addition to the KStatusNotifier dbus interface. would have 
to think a bit on how to best represent/expose that.

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

it can't be done only as long as we don't do it.

the irony is that it couldn't be done before, either! someone first had to 
design and then write that message indicator library with its dbus interface 
and generate all those application patches and write the server side too. only 
after all that work was it possible, and yet after that work upstreams said 
"no thanks" and the MI stuff is completely non-interoperable with anything 
else. so here we are, yet again, at "it can't be done" because someone didn't 
think in terms of whole platform design from the start.

so let's "just do it", this time from the understanding that we're creating a 
whole product here (f/oss desktop) rather than a random arrangement of add on 
features.

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

yes, which is good. but we can go further and remove even the assumption that 
there is a workspace out there (and all the images we might have in our heads 
about what that looks like). we're just publishing information that would be 
useful to know about our app. how that gets displayed (on a web page? on a 
bilboar full of lights? in a aystem tray?) is something we can safely ignore 
as an application developer.

there will be a workspace, of course, but until application developers are no 
longer thinking about what the workspace is we will continue to have our hands 
tied on both the applications and the workspace sides regarding what we can 
do.

a minor but interesting example is the "take a snapshot of the system tray 
icon and show it to the user" feature of some applications. neat idea, but why 
is it in the application? and lo!, it breaks almost instantly whenever 
something changes outside the application. :/

-- 
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/20091029/08b1c49f/attachment.sig>