(putting back plasma-devel on CC, since the discussion is quite relevant) 2012/9/17 Sune Vuorela <nos...@vuorela.dk>: >> 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 the org.freedesktop.notification api > wrap growl on mac
OT: you don't want to wrap growl but probably the new native notification system. > wrap QSystemTrayIcon on windows > 2) do something similar for audio notifications > 3) retrofit knotification on top of those > > and the more I have investigated, 1) should actually be put into Qt and > QPA. > That should also make it possible for e.g. webkit to use it to show web > notifications. > Unfortunately, I'm currently a bit busy with stuff :/ > >> My personal idea is to have a new (tier1) framework consisting of a >> way for building handlers, a client API and a server API (so that the > > Really? I_think we should get rid of a daemon and just let the workspace > shell handle it. 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 we need a centralized logic for dispatching, grouping and more. As Marco also said (framework wasn't CC'ed tho), the applet is already gearing towards being a dull observer. > I have a hard time figuring out why the above quite simple steps don't > solve the problems you're specifying (and even ensures that you keep all > existing applications working with their notifications) Well :D. There is no way you can group notification, no way you can tie them to activities, no way you can dispatch notifications to different handlers than the workspace, and more. So I guess it's rather safe to assume that the current design just won't cut it, and as I already said applications will still be able to work with the existing API, they just won't be able to expose the full experience - and in some cases where they just shoot out a transient bubble, they won't even notice the change. I guess the real question is whether we want to continue with the old paradigm we have or try to bet on something more modern. Also, what I am proposing can still be adapted to interact with other platforms - as I said, the client API should be as minimal as possible and not tied to the complexity of the server. > > > /Sune > > _______________________________________________ > Kde-frameworks-devel mailing list > Kde-frameworks-devel@kde.org > https://mail.kde.org/mailman/listinfo/kde-frameworks-devel _______________________________________________ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel