Re: Notifications-future, a recap

2012-09-21 Thread Dario Freddi
2012/9/21 Mark : > On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi wrote: >> (putting back plasma-devel on CC, since the discussion is quite relevant) >> >> 2012/9/17 Sune Vuorela : I know Sune already had some plans for the notification stack and I think that's one of the best times for

Re: Notifications-future, a recap

2012-09-21 Thread Mark
On Fri, Sep 21, 2012 at 4:42 PM, Mark wrote: > On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi wrote: >> (putting back plasma-devel on CC, since the discussion is quite relevant) >> >> 2012/9/17 Sune Vuorela : I know Sune already had some plans for the notification stack and I think that

Re: Notifications-future, a recap

2012-09-21 Thread Mark
On Tue, Sep 18, 2012 at 12:17 AM, Dario Freddi wrote: > (putting back plasma-devel on CC, since the discussion is quite relevant) > > 2012/9/17 Sune Vuorela : >>> I know Sune already had some plans for the notification stack and I >>> think that's one of the best times for discussing what's going

Re: Notifications-future, a recap

2012-09-21 Thread Dario Freddi
2012/9/21 Aaron J. Seigo : > if the "new" can be achieved by extending or building on galago, that would > seem to me to be a much better thing. > > and no, galago is not perfect. it's not even "great", but it is passable and > widely used and that gives it a lot of value. > > if it turns out that

Re: Notifications-future, a recap

2012-09-20 Thread Dario Freddi
2012/9/20 Sune Vuorela : > On 2012-09-17, Dario Freddi 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 ex

Re: Notifications-future, a recap

2012-09-18 Thread Dario Freddi
(readded frameworks, the topic ping-pongs) 2012/9/18 Aaron J. Seigo : > On Monday, September 17, 2012 20:40:33 Dario Freddi wrote: >> it's pretty much on the board :) just that 90% of this will happen in >> the background (server), whereas handlers will just take care of >> showing a model and a s

Re: Notifications-future, a recap

2012-09-17 Thread Dario Freddi
(putting back plasma-devel on CC, since the discussion is quite relevant) 2012/9/17 Sune Vuorela : >> I know Sune already had some plans for the notification stack and I >> think that's one of the best times for discussing what's going to > > yep. the plan is > 1) write a small library wrapping th

Re: Notifications-future, a recap

2012-09-17 Thread Sune Vuorela
On 2012-09-17, Dario Freddi wrote: > Hello everyone, > > you might or might not know by now of my intention of revamping the > way we deal with notifications in KDE as I explained in my last blog > post > http://drfav.wordpress.com/2012/09/17/the-notifications-issue-part-3-the-possible-solution/

Re: Notifications-future, a recap

2012-09-17 Thread Dario Freddi
2012/9/17 David Faure : > On Monday 17 September 2012 17:49:23 Dario Freddi wrote: >> a server API (so that the >> server can be put into runtime rather easily) > > Just a note on that: the plan with KDE Frameworks, is that there will be no > more libs/runtime separation. A framework will come with

Re: Notifications-future, a recap

2012-09-17 Thread David Faure
On Monday 17 September 2012 17:49:23 Dario Freddi wrote: > a server API (so that the > server can be put into runtime rather easily) Just a note on that: the plan with KDE Frameworks, is that there will be no more libs/runtime separation. A framework will come with any runtime stuff it might nee

Notifications-future, a recap

2012-09-17 Thread Dario Freddi
Hello everyone, you might or might not know by now of my intention of revamping the way we deal with notifications in KDE as I explained in my last blog post http://drfav.wordpress.com/2012/09/17/the-notifications-issue-part-3-the-possible-solution/ . I have been talking about this with many of y