> On April 25, 2013, 2:02 p.m., Aaron J. Seigo wrote: > > plasma/generic/applets/notifications/contents/ui/LastNotificationPopup.qml, > > line 52 > > <http://git.reviewboard.kde.org/r/110122/diff/1/?file=140373#file140373line52> > > > > no minimum is set here as there was in the prior code. there should > > probably be some sensible minimum applied. > > James Pike wrote: > The minimum is set on line 45. > > James Pike wrote: > I did however remove the 60 second maximum as I believe this is too low, > many people in my office have expressed a desire for higher notification > timeouts. I mark notifications from my boss with a timeout of several > thousand seconds to ensure I never miss them. Else he'll get angry. > > James Pike wrote: > Please feel free to re-instate the 60 second maximum though, it just > means I'll never be able to use KDE and have a non-angry boss at the same > time :P > > Thomas Pfeiffer wrote: > If an information is so important that you must not miss it, it should > not be displayed as a notification (or at least not only). Notifications > should only be used for information that may be interesting, but not critical. > If you have to set timeouts to basically "forever", that's a sign that > you're using a notification for the wrong purpose. > > James Pike wrote: > And sure, I have audio notifications on top. Yet I still think, it's not > up to you to decide purpose, to decide the notification period. To decide on > behalf of everyone else. I didn't think that was the KDE philosophy at all, I > thought the philosophy was on user configuration. So IMO to decide on a > blanket 60 second maximum for everyone and enforce that is wrong. > > Do you really wanna be the kinda person who tells an entire community > about what purpose "should be"? > > James Pike wrote: > Essentially I'm asking, why do you feel you have a mandate, as a WM, to > override hints given by user applications? Why do you assume a user > application cannot have a timeout above 60 seconds? Way too authoritarian for > my likings... > > James Pike wrote: > The number of applications that would set long notifications maliciously > VS the number of people who may want notifications longer than 60 seconds... > that's an argument I'd bet large amounts of money on winning. > > Thomas Pfeiffer wrote: > I agree that if the API excepts any value for the timeout, values should > not be overridden at a later point. If a developer or user is allowed to set > a timeout of 1000s, than it should show for 1000s. > > What this situation clearly shows me, though, is a mismatch between the > mental model of the developers of the notification system and its users. A > timeout of 1000s is a workaround for "I don't want my notification to go > away". And whenever people work around something which is done by design, > there is a gap between designer and user. > Therefore it seems to me that we have to rethink what purpose the popup > notifications are designed for and make it work well for that purpose without > the need for workarounds. And if users need a kinf of notification for which > the popup notifications were not made, we need a new kind of notification, > not a workaround. > > Thomas Pfeiffer wrote: > And I apologize for at first not acknowledging your - justified - > argument that a program should not accept a value at first and then override > it later. My argument that a timeout of 1000s means that something is wrong > dominated my mind at that point.
since the notification timeout comes from the shared dbus api to do notifications we don't have much degrees of freedom api-wise (it has also to support gtk apps, or old apps). one thing that may indeed happen is the ui that has to work a bit around the api to achieve the design that was in mind for that particular piece. the small notification that automatically pops up is quite a "dangerous" thing ui wise, it should be as less invasive as possible, that's why we forbidden notifications to stay there for 1000 seconds. And for ones that are valid/important for a long time, that's why the notifications history exists - Marco ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: http://git.reviewboard.kde.org/r/110122/#review31563 ----------------------------------------------------------- On April 25, 2013, 1:58 p.m., James Pike wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > http://git.reviewboard.kde.org/r/110122/ > ----------------------------------------------------------- > > (Updated April 25, 2013, 1:58 p.m.) > > > Review request for Plasma. > > > Description > ------- > > Currently the timeout of the last notification to arrive is used as a basis > for hiding the notification display. This means that a notification with a > high timeout can get hidden by a new notification arriving with a much lower > timeout. > > This patch simply changes the behaviour to, when expiring a timer, go back > through the stack and display the most recent unexpired timer. If all timers > are expired the notification is closed as before. > > > This addresses bug 318295. > http://bugs.kde.org/show_bug.cgi?id=318295 > > > Diffs > ----- > > plasma/generic/applets/notifications/contents/ui/LastNotificationPopup.qml > 2fa1b11 > > Diff: http://git.reviewboard.kde.org/r/110122/diff/ > > > Testing > ------- > > Test script in https://bugs.kde.org/show_bug.cgi?id=318295 > > > Thanks, > > James Pike > >
_______________________________________________ Plasma-devel mailing list Plasma-devel@kde.org https://mail.kde.org/mailman/listinfo/plasma-devel
