notifications, again :D

Chani chanika at gmail.com
Mon Jan 25 22:15:25 CET 2010


On January 25, 2010 12:23:29 Marco Martin wrote:
> On Monday 25 January 2010, Chani wrote:
> > On January 25, 2010 04:20:56 Marco Martin wrote:
> > > howdy all,
> > > so, based on both ersonal experience and feedbacks i'm of course stilkl
> > > not happy on how notifications work, that's the pretty hard question of
> > > being informative enough, vs not entirely cover the screen.
> > > last thing i was thinking about was something that resembles rssnow:
> > > http://imagebin.ca/view/fiFONCc.html
> > > this would resemble the pattern of the appletbrowser, search and launch
> > > and possibly other stuff in the future.
> > > 
> > > -only one notification is shown at a time
> > > -still valid notifications scrolls automatically or after arrows press,
> > > like rssnow
> > > bottom arrow would switch from valid to recent expired notifications
> > 
> > ebbeh... three arrows?
> > my first impression is "eek! different! scrolling! scary!" ;)
> > I kinda feel like this is just hiding the problems instead of really
> > solving them.
> 
> yes, 3 arrows is defnitely too much
> 
> > so.. stepping back for a minute, here's what actually causes me trouble
> > with the current notifications:
> > 
> > -they cover a rather useful chunk of my screen.
> > I guess I could solve that myself by putting my systray in a less
> > convenient place.
> 
> is that chunk way more mportant than the others? i guess so since tends to
> be where kmail message bodies are...
> they could popup in a different are of the screen when they are automatic
> and still pop up there when explicitly open... fear would be even more
> confusing tough

my systray is on a hidden panel at the top center of my screen. it's a great 
place for kmix and klipper (right beside my taskbar and battery plasmoid) but 
not so great for notifications if I'm reading a web page or something.
works well for konsole, though, since the important stuff is at the bottom 
there. :)

there's really no perfect way to solve that, I suppose. it's just slightly 
inconvenient sometimes that systray and notifications are bound together. 
probably not worth doing anything about until we're free of the old systray 
stuff.

> 
> > -they cover too much of my screen.
> > I think there's a lot that could be done to save space before showing
> > only one at a time. those two extenders for completed vs. incomplete
> > take a big chunk all by themselves, even when they have nothing under
> > them.
> 
> yes. some of those should be removed, maybe i have half an idea how to do
> that will explain later...
> but i think i'm still thinking about scrolling...
> 
> > -they're not easy to dismiss.
> > I did try to hit the little X last time, but the stack of notifications
> > went away just as I was clicking the mouse and I hit something in kmail
> > instead. I really really miss the "click anywhere (other than a button)
> > to dismiss" behaviour.
> 
> probably would be easy to do... is what we want? maybe one wants to click a
> button misses it, the notification goes away and thinks having actually
> managed to press that button

I'm not sure. I haven't heard anything from anyone else about this behaviour. 
but if you miss a button you're probably going to notice that whatever the 
button was supposed to do didn't happen... the only case where it'd suck would 
be when you're trying to hit the "don't shut down my computer yet!" button.

I almost wish there was a global keyboard shortcut for "dismiss all 
notifications". but that seems like overkill.

> 
> > -they cover it for too long.
> > something that especially bugs me is that when the latest notification
> > itself goes away, the rest of the stack (even if it's just those two
> > category headers) hangs around for an extra few seconds, and because of
> > that my panel is also staying visible for those extra few seconds. I just
> > want the darn thing to go *away*.
> 
> yes, they should have a max, right now a notification can ask to be
> immortal, kopete ones are iirc (that's in the ugly spec)

that too, although that's not what I was talking about. the notifications go 
away and the notification-area is still there taking up screen space. it drives 
me nuts.

> 
> > -a lot of notifications shouldn't be there to begin with.
> > I really don't care that ksnapshot is downloading my last screenshot over
> > sftp when I run it. I don't need that completed "download" hanging around
> > for minutes adding to the size of my notification area. perhaps this is
> > ksnapshot's fault, but still, improvements could be made in what not to
> > show. or at least what not to keep around once it's done. the same sort
> > of thing happens if I open a link in gwenview or okular or something. on
> > the one hand it's nice to know that something is happening; on the other
> > hand if it's just a little 20k image it'll be done in under a second and
> > then I'll have that completed "download" clogging up the notification
> > area for much longer.
> 
> yes, many are useless but not much we can do about it.

there must be something *someone* can do about it.  educate developers on how 
to make internal jobs not show up, perhaps? I assume there is a way that jobs 
can be marked as "not important enough for a notification", because I don't get 
pages of notifications when I open a website in konq.

> for jobs the problem is totally different, in that case we exclude ones
> that last less than 2 seconds, but even this way useless one go in.
> 
> i aso think completed ones should become the same widget of notification,
> so living in the same extender with the same lifespan and go in the same
> old notifications pool.
> 
> > so... showing only one at a time would solve the "covers too much of my
> > screen" problem, which in turn would make me not care so much about the
> > rest of the problems... it might introduce other potential issues too
> > though. like the (probably small) chance of a low-battery warning being
> > missed because something starts downloading a file half a second later.
> 
> job progress would still be in a different zone...
> or shouldn't they? hmmm
> i think jobs should remain the more visible as possible, we have already
> bug reports about people thingking jobs are done because the popup auto
> hidden...

the big problem i see here is there are two kinds of jobs: 
1) proper user-initiated downloads (eg. save-as from konq), the kind I might 
want to check up on, then open when they're done. these are almost always 
useful.
2) automatic downloads that some app will use when the file is done, in which 
case the only useful part of their being there is to show me that the app is 
still doing work; once those ones finish, the notiication becomes 100% useless 
and really should not hang around.

how can we tell the difference between these jobs and treat them appropriately?

> 
> > hmm. it could make sense to show only the most recent in the popup (and
> > have a minimum display time of a couple of seconds perhaps?).
> > I don't like the idea of clicking arrows to show them one by one, though.
> > I feel half-blind when I can only see the current item in a list and
> > don't know how many items there are or where I am.
> > 
> > I'd suggest rethinking how all the other notifications are shown.
> > show the one most recent, yes, but perhaps have a button to expand and
> > show all the recent/in-progress notifications. and another small button
> > somewhere to show a log of old/completed notiiciations, in a separate
> > window. more like a log viewer - yes, we haven't actually implemented
> > logging of the notifications yet, but it'd be a place to put them when
> > we do. and some things, like those ksnapshot and gwenview downloads,
> > maybe they shouldn't be logged... but if they immediately went to that
> > log viewer when they're done instead of hanging around on screen then I
> > wouldn't care so much.
> 
> I'm not sure about an external window that would act as a log browser, also
> because logging notifications indefinitely wouldn't be that useful, just
> produce megs  of an useless file..
> the idea of expired notifications was about notifications you missed say 3
> minutes before that could still be useful, knoing that 3 months ago the
> battery was critical not really...

yes, you wouldn't want to log everything forever. however, right now some 
notifications are permanently gone after a minute when I might not really want 
that. keeping a log of at least the last few hours could make sense.

also, knowing that 3 months ago I downloaded a certain file from somewhere 
could actually be useful... although it seems more like something nepomuk 
should track.

> 
> what i'm toying with at the moment is:
> * display notifications mostly as they are now until there are 2 or 3
> * if there are more than that, standard vertical scrollbar, maybe not
> uberpretty but should be obvious enough those days
> *keep expired notifications, but will always be necessary to scroll to view
> them, so no annoying, even the tabbar would still be visible but scrolled
> away 

tabbar?

> *recently completed jobs are drown in the normal notifications, so an
> extendergroup less

parse error.
are you saying you'll put recently completed jobs in the same area as normal 
notifications?

> *running jobs still a different thing

I wasn't aware they were different, honestly.

> 
> i have now a patch that does it very -badly- (can publish it just to make
> people test but the code kills kittens) but  work-ish
> if seems a good approach i can start to implement it properly
> 
> Cheers,
> Marco Martin
> _______________________________________________
> Plasma-devel mailing list
> Plasma-devel at kde.org
> https://mail.kde.org/mailman/listinfo/plasma-devel

-- 
This message brought to you by eevil bananas and the number 3.
www.chani3.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
Url : http://mail.kde.org/pipermail/plasma-devel/attachments/20100125/288b2ca7/attachment-0001.sig 


More information about the Plasma-devel mailing list