Re: Plasma queued notifications
On Mon, Jan 18, 2010 at 3:26 PM, Charly Ghislain wrote: > Hi, > > Actually I won't have time for some weeks for this as I need to meet a short > deadline elsewhere, but I won't let it die. > > Marco: is a scrollview, like what the current devicenotifer uses, something > that could be used ? The items there seems to have all the features of yes, devicenotifier use that one scrollview we have in plasma > extenders (i guess there are in fact), but looks more pretty and lightweight, > and may fit nicely in a otifications list. no they aren't extenders, you can't detach them infact (and is it important for notifications? probably yes) > A second thought : is all the informations of the current jobs really wanted > in the widgets, or should a dialog be opened when job details are asked? It > looks a bit too clustered now on my desktop, and not at all useful since the > strings are truncated, it might be worse on netbook. no, no dialogs, ever. :p > Regards, > > Charly > > On Wednesday 13 January 2010 13:06:14 Marco Martin wrote: >> 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 >> ___ >> Plasma-devel mailing list >> Plasma-devel@kde.org >> https://mail.kde.org/mailman/listinfo/plasma-devel > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel > ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma queued notifications
Hi, Actually I won't have time for some weeks for this as I need to meet a short deadline elsewhere, but I won't let it die. Marco: is a scrollview, like what the current devicenotifer uses, something that could be used ? The items there seems to have all the features of extenders (i guess there are in fact), but looks more pretty and lightweight, and may fit nicely in a otifications list. A second thought : is all the informations of the current jobs really wanted in the widgets, or should a dialog be opened when job details are asked? It looks a bit too clustered now on my desktop, and not at all useful since the strings are truncated, it might be worse on netbook. Regards, Charly On Wednesday 13 January 2010 13:06:14 Marco Martin wrote: > 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 > ___ > Plasma-devel mailing list > Plasma-devel@kde.org > https://mail.kde.org/mailman/listinfo/plasma-devel ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Re: Plasma queued notifications
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 ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
Plasma queued notifications
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. 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 code. I'd like to hear from you if you had another design in mind, if you think it's not necessary, if you think something's wrong with my proposal, if you have already something you're working on, whatever. One thing to keep in mind is im somewhat new to c++, im usually coding in java and i tend to use interfaces a lot and i like type-safety and i don't like passing new Strings as identifiers. Thank you! Charly ___ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
