Notifications system discussion

[Maciej Katafiasz]

Dnia 10-08-2004, wto o godzinie 15:32 +0200, Lubos Lunak napisał(a):

>  This somehow brings up the question why do you need a spec at all just for 
> passive popups. If you want just that, and want to do everything else in the 
> client, why don't you do this in the client as well? Or the other way around: 
> If you want to have passive popups in the server, why don't you do the rest 
> in the server as well?

To make them consistent. And having very simple and small spec is
perfectly aligned with Unix philosophy - do one thing, but do it well.
You don't loose by anything having for example sound theme factored out
into separate spec, as it's pretty much independent of the rest of
presentation bits. Additionally, since we have very similar spec (for
icons) already done and agreed, writing one for sounds is matter of week
or less.

> > > >-Nothing will change in KDE applications.  And others application
> > > >(gtk,...) can call the notifier.
> > >
> > > This makes sense, and sounds like a good plan. What do others think?
> > > Lubos? Christian?
> >
> > That looks great. I don't think there are any major issues with that.
> 
>  Hmm ... that looks a bit like legacy support for future technologies to 
> me :-/ (sorry).

Hmm, can't parse this sentence. What do you mean?

>  Technically, I don't think KDE would need yet another daemon just for this. 
> KNotify could handle that as well itself if needed (serve as the server for 
> the spec if running in KDE or forward to the server if running outside of 
> KDE). That'd of course need something like "There are non-KDE applications 
> which can also notify you centrally about events, but unfortunately the 
> configuration is limited. How would you like _all_ those events to be 
> represented? <list of presentations>".

As you said, it's technical detail who exactly will implement that bit
inside KDE. And for "There are non-KDE applications which can also
notify you centrally about events, but unfortunately the configuration
is limited" part, that's where list of event IDs comes into play, see
below

>  It would be a possibility if we can't find any better solution. But I still 
> hope we can find something better.

Given that KDE apps will (as I understand) get compliance for free, by
only changing KNotify daemon, and rest of apps will simply implement the
spec, I don't see anything bad with that approach. I don't really see
what is suboptimal here.

> > 2) I'd also like applications to send along a notification detail ID.
> >    The spec would define a number of standard notifications (which
> >    we'll no doubt be adding to quickly), and non-standard ones would
> >    use x-foo. This would allow the daemon to be more intelligent when
> >    it comes to filtering. Like, if you get a email notification from
> >    two apps within a very short time, only process one of them.
> >
> > If we have an application name and type ID, we could do per-type
> > customization. The one thing, though, is that you'd only be able to
> > customize notifications that have already been seen, but
> > (theoretically, depending on the daemon, again) a global customization
> > would suffice normally anyway. So you could set all mail notifications
> > to just play a sound, and all buddy notifications from a specific IM
> > client to appear in a bubble. Or whatever.
> 
>  Isn't this exactly what Mike doesn't like about KNotify? Because this looks 
> like KNotify to me, maybe except for how the presentation defaults are 
> specificed (knotify per-app config file vs whatever you mean).

The difference is that ID is somewhat optional, and serves only as a
hint, and not as the only way to get notification done. In KNotify, as I
understand, you can't get away with app not configured and installed
earlier sending notification (since the only parameter that app can
change is preconfigured event ID, right?). In Chris' proposal, IDs will
be akin to MIME type - divided into "well known" and custom (or unknown)
ones, and similarly, you can still manipulate file even though its MIME
type isn't specified. Also, since list of "well known" IDs will be
public, and not app-specific, apps like shell scripts can still properly
hint their notifications despite not being configured beforehand

Cheers,
Maciej

-- 
"Tautologizm to coś tautologicznego"
   Maciej Katafiasz <mnews2 at wp.pl>
       http://mathrick.blog.pl