Hey all, Now that all the work done on Activities is really coming to fruition, I've been giving thoughts to how this could work with Notifications. I see four immediate considerations:
0) Spurious notifications detract from one of the key use-cases for activities: separation of real-world tasks for the purpose of focus or organization. 1) If hidden somehow, missed notifications shouldn't be fatal in theory, but could easily be frustrating in some cases. (Probably enough that people would be divided over it.) 2) A UI to configure this at a high level of granularity would likely be a nightmare for users. 3) The notification plasmoid is already fairly "busy" visually, so internal grouping by activity or similar might well be undesirable. I can't think of any way around (2), and in any case I don't believe it is the Right Way to do things; even someone who could understand such a myriad of options probably would be too lazy to make use of it. To be honest, I think (0) is not enough of any issue to warrant doing this until it can be done the Right Way. (3) is probably beside the point anyway, since if we want to provide clear separation, that could be counterproductive, apart from adding UI complexity. Here's a bit of braindump. Feel free to pick it apart. (Without going into the original debate...) Shuttleworth's comments on notification ephemerality coupled with Plasma's current "auto-hide, but log" behaviour suggest to me that perhaps an appropriate approach would be to continue as-is for notifications from applications in the current activity, but to provide a more subtle - and generic - signal for applications on other activities. This could be done, for example, by adding another one of those sexy Notification icon "pulse" animations with an icon indicating events not shown. One could perhaps assume that transient notifications from another activity are not sufficient to warrant switching activities to see them, and thus merely perform this action for persistent/action-requiring notifications. The notification history could then be per-activity, with cross-activity applications being shown on all relevant activities. This would provide comparable functionality to what is currently available, but would avoid unnecessary (mental) context-switches for trivial things (if I could have missed it by glancing away for a moment, then it's probably not all that important), and would provide a less distracting way to be notified of events that would require a context-switch to deal with. Obviously, there are some holes in this scenario, and it also makes certain design assumptions that are likely not universally agreed on. In particular, there is the question of what to do about separate instances of applications in different applications; can KNotify differentiate between different processes in that way? What about applications that run in one process with multiple windows? Anyway, hopefully this can start some discussion on the topic. Cheers, - Jeffery MacEachern P.S. What about Job notifications? :) >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
