2012/9/20 Sune Vuorela <nos...@vuorela.dk>: > On 2012-09-17, Dario Freddi <drf54...@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-de...@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel