Notifications-future, a recap

[Dario Freddi]

2012/9/20 Sune Vuorela <nospam at vuorela.dk>:
> On 2012-09-17, Dario Freddi <drf54321 at gmail.com> wrote:
>> It really depends on what you want to achieve. If your goal is just
>> cleaning up the API and implementing the existing standard it might
>> work out, but for sure it won't just cut it for what I proposed, where
>
> Why won't the existing (as in the fdo/galago spec) api cut it to ensure
> we also play well with others (in both directions) ?

Wait. Noone ever said we wouldn't be compatible with the existing spec
back and forth, quite the opposite. I just said I'd try to push our
changes upstream, this doesn't mean we wouldn't be compatible with
fdo, it would be a suicide. The current API simply WON'T ALLOW
applications with specific requirements to take advantage of a more
fine-grained system. More below.

> Really. All I read is complexity for teh sake of complexity, trying
> to build walled gardens for the sake of building walled gardens and
> complicating deployment for the sake of complicating deployment.
> And I don't think that's neither modern, slick nor futureproof.

I am sorry, but no. If you read my second post it is blatant clear
we're lagging behind every possible modern concept of notifications.
Example: has Akonadi or any other data-intensive application ever
failed on you? It does to me quite often, and I get 30 error spam
bubbles my system simply can't handle and drive me mad every time. And
what about losing track of incoming mails/messages? Thank god Kubuntu
kind of implements support for persistent notifications, otherwise I'd
lose every single time people ping me on IRC.

If we want to pretend what we have is already enough, we can live in
our own small world. But looking outside of our bubble should tell us
something, and making us realize we have to try to walk a step
forward. Complexity in the server code leads to simplicity to the user
and to developers - most of the features I have disclosed won't be
exposed through the API - as I explained, most of the grouping can be
done with the current means we have. On the client (applet) side,
everything would be much easier since the applet would just receive a
model. It really can't get simpler than that.

A more complex API will be provided to those application which have
specific needs, such as contact list. Your average (80%) application
will just benefit from SC and won't even notice. You don't want to
make your application a handler? Fine, still works. You don't need to
associate a specific event to an activity? Fine, still works, and
moreover the API will figure this out for you. I really cannot see how
this would get more complex to users and developers. Of course it is
more complicated than what we have now INTERNALLY, but again you
should look at the benefits.

If the majority doesn't want this, I won't be the one pushing it, but
stating that such a change isn't a step towards being more modern is
willingfully ignoring everything outside KDE - I didn't write 3 blog
posts for anything, and my first two ones were exactly aimed at
answering concerns like yours. Seriously, the only "new" thing in that
concept, in complete honesty, is the activity integration - everything
else can be found in any modern interface, be it phone, desktop or
web.

>
> /Sune
>
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel