Re: About KPassivePopup

On Wednesday 28 March 2007 20:31 +0100, Krzysztof Lichota
wrote:
> Kevin Krammer napisał(a):
> > On Thursday 22 March 2007 07:03 +0100, Kelly
wrote:
> >> I was somewhat curious; I was reading about
the project related to
> >> KPassivePopup, and the first thing I wondered
is, wouldn't it be better
> >> off as a DBus-registered daemon?  Or am I
totally off base?
> >
> > My guess is that KNotify has (or will have) a
D-Bus interface just like
> > it had a DCOP interface.
>
> Will this interface be compatible with libnotify
interface used in
> Gnome? This would make writing interoperable apps
easier 

It can register this D-Bus name and object/interface as well
if needed.

The philosphy behind both ideas is a bit different though.
libnotify 
(currently) only supports one kind of presentation, KNotify
has this 
configurable, libnotify assumes the client passes all
presentation hints, 
KNotify assumes it can look them up in the configuration
infrastructure.

But, as I said above, it is possible to implement both

Cheers,
Kevin

-- 
Kevin Krammer, KDE developer, xdg-utils developer
KDE user support, developer mentoring

 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On Wednesday, March 28, 2007 4:04 pm Kevin Krammer wrote:
> On Wednesday 28 March 2007 20:31 +0100, Krzysztof
Lichota wrote:
> > Kevin Krammer napisał(a):
> > > On Thursday 22 March 2007 07:03 +0100, Kelly
wrote:
> > >> I was somewhat curious; I was reading
about the project related to
> > >> KPassivePopup, and the first thing I
wondered is, wouldn't it be
> > >> better off as a DBus-registered daemon? 
Or am I totally off base?
> > >
> > > My guess is that KNotify has (or will have) a
D-Bus interface just like
> > > it had a DCOP interface.
> >
> > Will this interface be compatible with libnotify
interface used in
> > Gnome? This would make writing interoperable apps
easier 
>
> It can register this D-Bus name and object/interface as
well if needed.
>
> The philosphy behind both ideas is a bit different
though. libnotify
> (currently) only supports one kind of presentation,
KNotify has this
> configurable, libnotify assumes the client passes all
presentation hints,
> KNotify assumes it can look them up in the
configuration infrastructure.
>
> But, as I said above, it is possible to implement both
>
> Cheers,
> Kevin

Actually, I was thinking the same thing myself; that if the
KDE and GNOME 
notify systems exposed the same interface, then programs can
simply use 
whichever one the desktop starts up.

-- 
http://www.m
ozilla.org/products/firefox/ - Get Firefox!
http://w
ww.mozilla.org/products/thunderbird/ - Reclaim Your
Inbox!

Please avoid sending me Word or PowerPoint attachments.
See http://www.gnu.org/philosophy/no-word-attachments.html
 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<

On Wednesday 28 March 2007, Kevin Krammer wrote:
> The philosphy behind both ideas is a bit different
though. libnotify
> (currently) only supports one kind of presentation,
KNotify has this
> configurable, libnotify assumes the client passes all
presentation hints,
> KNotify assumes it can look them up in the
configuration infrastructure.
>
> But, as I said above, it is possible to implement both

last time i looked at the galago spec[1], it occurred to me
that it was simply 
a sub-set of the functionality we provide. it does indeed
provide for only 
one kind of presentation, and it is fairly limited in some
ways.

implementing the dbus interfaces (they call them
"protocols") in knotify 
should be enough to allow non-KDE apps that use galago to
work properly in 
kde, using kde's services. d-bus should provide the
contention resolution 
between apps trying to register the
org.freedesktop.Notifications.* services 

this won't cover the issue of kde apps running elsewhere, as
we'll still have 
a superset of capabilities and i think that's valuable to
keep.

[1] htt
p://www.galago-project.org/specs/notification/

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

Full time KDE developer sponsored by Trolltech (http://www.trolltech.com
)

 
>> Visit 
http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
unsubscribe <<