(1 attachment)

This is a feature tracking bug for showing mail notification in KDE kbiff. Dunno
if we'll get to this, but we should certainly document our decision.
Seth,
Alecf suggested you might be interested in this. Or you can reassign to
nobody@mozilla.org to solicit outside help if you want.

it would be great to integration with KBiff, xbiff, and other such things.
we had some integration with xbiff / kbiff in 4.5, but it was pretty crude.
(notification through a file)
marking m20.
adding alecf and kurt granroth to the cc list.
see http://home.sprintmail.com/~granroth/kbiff/

it would be great to integration with KBiff, xbiff, and other such things.
we had some integration with xbiff / kbiff in 4.5, but it was pretty crude.
(notification through a file)
marking m20.
adding alecf and kurt granroth to the cc list.
see http://home.sprintmail.com/~granroth/kbiff/

It is now possible to remotely 'talk' with KBiff. It uses the new KDE standard
IPC/RPC protocol DCOP so the *ideal* way for mozilla to handle it would be to
know about DCOP. This would be swell for more then just kbiff, too, as darn
near every KDE app/object has or will have a DCOP interface.
HOWEVER, it's possible to remotely access all KDE apps even if you don't
implement DCOP. You can do so using our XmlRpc to DCOP gateway. I assume that
mozilla will be integrating XmlRpc one of these days (or maybe it's cousin --
SOAP) as even IE has it built-in.
Anyway, I'd be willing to work with the mozilla team on this issue...

adding kurt to the cc list.
how about something like this:
we come up with a biff / alert listener interface (this may already exist, as
putterman added biff to the sidebar.)
we allow more than component to supply an implementation for the "biff" listener
prog id.
when mail-news starts up, it gets all the biff listeners.
when the biff event fires, it calls the right method on each of the listeners.
the KDE biff listener would know about DCOP (or, if other things will use DCOP,
we may have a DCOP service in another component) and it would do the right
thing.
this way, all you need to do support KDE or GNOME, is implement that interface
and drop it in to the components directory. once overlays full work, we'd have
a generic preference overlay for the "mail biff listener" to implement, so you
could configure it.
comments?

Suggestion: use categories so that we can enumerate all biff listeners.... (i.e.
each biff listener registers as a member of a particular category with XPCOM)
In order to do this, we should add category support to Generic Factories...

marking this one blocking 11056 (the GNOME bug suggesting the same is already
there), so it's easier to find this bug.
Comment #4 here sounds really, really good for the whole effort. Is there anyone
who has plans to work on that?