Plasma queued notifications

[Marco Martin]

On Tuesday 12 January 2010, Charly Ghislain wrote:
> Hi all,
> 
> As an excuse to get used to the c++ and the kde api, i thought of
> implementing queued notifications as there are issues with the current
> system. I'd like to hear your thought about how such feature should be
> implemented.
> 
> I forward here the mail i sent to aseigo and normart so that everyone can
> get involved.
> 
> Thank you,
> 
> Charly (cghislai)
> 
> 
> == forwarded message
> 
> Hi,
> 
> I'm getting into kde api slowly and thought it could be interesting to
> implements queued notifications (be it jobs or whatever). With the current
> implementation, a badly designed application might start a lot of jobs in
> parallel pulluting the desktop with lots of extenders.
> 
> I was told that you, notmart, should know that code and i saw that you,
> aseigo, planned this feature in the release Schedule. Its stated as 'IN
> PROGRESS', maybe you are handling this already.
> 
> If you're not, i'd like to know how you think this should be implemented.
> The easy way seems to restrict a number of notifications to be showed
> simultaneously, yet im not really sure which class should be in charge, it
> seems the ExtenderTask's ExtenderBusyWidget does. It might be interesting
> to think if jobs should be queued or run simultaneously.

they are already kinda limited to an hardcoded 10, but it has to get better.

> 
> Another possibility is to create another widget, which could then be any
> kind of applet. the ExtenderTask (which should then be renamed) will
> create either a ExtenderBusyWidget orthis another one with respect to user
> preferences.
> 
> IMHO, the proper way to do this with modularity in mind is using the
> following classes:
> - The task with its help-about icon, and a notificationPresenter
> - A NotificationWidget, in charge of showing notifications to the user. It
> should be abstract and the current extenders implementation a subclass of
> it. - A NotificationsQueue, keeping track of waiting, running or finished
> notifications /jobs. This could be the Manager.
> - A NotificationPresenter, which hold the behaviour of notifications, like
> what to do when whatever event happened. This behaviour shoud be common
> amongst the different widgets (extenders / queued popups), so it might be
> useful to put it into his own class. the presenter should create its own
> NotificationWidget
> 
> This is my MVP design, it might not be suitable or not fit in the plasma

well, it already has a quite mvp design, due to the searation of 
Notification/NotificationWidget and Job/Jobidget

Wht's is needed is a better visualization of the notification/job widgets.
i was planning about the following:
-merge the concets of completed jobs and notifications, so visible for a 
while, then going in the pool of old notifications
-make the popup a scrollview, it will be always exactly big enough to show 
exactly the curent notification/jobs, but no more than a certain ratio of the 
screen.

to access the old notifications just scroll the view down, without having to 
press strane button or whatever, there will be some "page" semantics.

this way it would be the less annoying, because it won't never take too much 
screen without sacrificing important bits of information.

the challenge is to do it without it looking total crap, i had a semi working 
patch but had some issues

Cheers, 
Marco Martin