[00:03] crimsun: downgrading those packages to -ubuntu1 and then reinstalling the nvidia driver "fixed" it here [01:35] <_Groo_> hi/2 all [03:11] I'm using the lucid alpha. Mostly everything works great, but when use the volume control keys on my laptop, it controls the pulse audio volume, not the master track volume, what happens is once I get a little below halfway pulseaudio brings the master track down to 0 so I don't hear anything. I resolved this same issue in Karmic by editing some file, I just can't remember which one. Does anybody know what file I need to edit to [03:11] fix this? [03:46] is there a GUI to configure notifications behavior? [03:47] For notify-osd? No. [03:47] There is no configuration for notify-osd notifications. [03:49] RAOF, that's bad I guess [03:49] DanaG has also complained about that [03:49] notifications won't show on top of a full screen Firefox window for example [03:50] I'd like to have a saying on that behavior [03:50] DanaG: did you reported it as bug? [03:51] alex_mayorga: Urgent notifications should show on top of everything, but full-screen firefox should trigger the “disable non-urgent notifications when in a presentation” mode. [03:51] So, that'd be expected & intended behaviour. [03:52] what is an urgent notification? [03:52] Something that's been tagged urgent :) [03:52] For example, the your-battery-is-about-to-die notification is tagged urgent. [03:52] But song change notifications aren't. [03:53] restart required because of a kernel update? [03:53] IIRC there are 3 priorities for notifications, but I think we only use urgent/not-urgent. [03:53] I don't think that should be urgent. [03:54] RAOF, it would be cool if I get a saying on "urgency" [03:54] You'll notice that Lucid's notify-osd has all sorts of debugging displayed? The blue bar at the top says “low - report incorrect urgency” for most notifications; that's what this is. [03:55] alex_mayorga: Possibly? What would you actually like to do with it? [03:55] mail or twitter might be "urgent" for me, but powers that be decided they're "low" [03:55] or I might have to want to see everything even with a full-screen app [03:56] At the moment, that means you don't want to use notify-osd. [03:56] I bet there are many more valid user cases [03:57] so configuration is out of the question? [03:57] At the moment, yes. [03:57] RAOF, I'll take it as it is then [03:57] alex_mayorga: Bring up your use-cases on the atayana list; maybe they'll be able to work something out. [03:57] is the're a config file somewhere? [03:58] Notify-osd is deliberately unconfigurable at the moment to make it more likely that people will make the default behaviour right. [03:58] But it my case, it instead makes things really bad. [03:58] Guess how long it takes me to read the following notification... and how long it leaves it on the screen... [03:58] Ambient Light Sensor: [03:58] ON [03:59] Takes me, oh, 1/8 to 1/4 second to read.... but it stays on the screen for 10 seconds! [04:00] they can certainly code in a correlation between length of message and length of display time [04:00] even if it's something simple like 1 second per word [04:01] The default minimum-time is also way too long. [04:01] It doesn't take 10 seconds to read a track-change notification (example: quodlibet). [04:01] Skip 6 tracks... and it'll take a full minute before it shows the track you're actually on! [04:03] ah, i see why that doesn't apply to me. banshee doesn't support libnotify [04:03] yet [04:03] Yes it does. [04:04] Is yours not displaying track change notifications? [04:04] negative [04:04] but i'm on karmic [04:05] it's not in the extensions list [04:05] Works on my Karmic install. [04:06] It's in the “Notification area” extension; it's not an extension of its own. [04:06] I think is plainly arrogant to decide for users, what's important or not or how fast they should read and such [04:06] It perhaps should be. [04:06] is it an extension or is it a feature? [04:06] ok, that explains it. i disable all notification area icons [04:06] Yeah, arrogant is a good word. [04:08] alex_mayorga: So, how would you set the importance? Would you have each application that raises a notification have an option to set its importance? [04:08] The importance has to come from _somewhere_ [04:08] DanaG: that's how I felt the moment I discovered I didn't have any for of saying on the "feature" logic [04:09] but you don't want to expose things to users that let them screw up the system without being able to easily fix it, ie. the kde approach [04:09] RAOF, ask me the first time an app wants to notify [04:09] What if the app has multiple different types of notifications? [04:09] I do see the overly-configurable bit... check out the qtcurve settings. At the very least, they should have the presets more easily accessible instead of buried with the oodles of settings being the main thing. [04:09] let me say OK I want to see these notifications, or I don't care at all [04:10] “New email arrived” and “Sending email failed” and ... [04:10] DanaG, isn't everything in kde buried in oodles of options? [04:10] alex_mayorga: And if you now want to turn those notifications back on? Where's the option hidden? [04:11] probably in a giant page full of incomprehensible options [04:11] RAOF: System > Preferences > Notifications is what I was looking for [04:11] are the wifi notifications changes at all? I haven't started testing yet... [04:11] alex_mayorga: And that would list every application that has ever sent at least one notification? [04:11] it would have to, to be consistent [04:12] RAOF: how about all the ones that are running at the moment? [04:12] it would also violate gnome's rules on these things [04:12] alex_mayorga: There's no way to work that out. [04:13] Apps don't register with the notification daemon, they just say “hey, display this now”. [04:14] it's tricky business I know, but not having any kind of saying is baffling IMHO [04:14] I don't find it particularly baffling; I don't want to have to mess around with this stuff. It should just work, and not get in the way. [04:14] it all started to copy growl if I'm not mistaken, and I believe growl is configurable [04:15] No, notify-osd wasn't intended to copy growl. [04:15] RAOF, what works for one person might be intolerable to another [04:15] Indeed. But that's surprisingly uncommon. [04:16] For something as basically insignificant as notifications it *should* be possible to get something that works well for 99% of users. [04:17] if you let me pick what notifications to receive it would work for a 100% DanaG and me might be the 1% that do want to fiddle with the details [04:17] The 1% not covered can either install upstream notification-daemon or notify-osd can grow some configuration, but the goal is to get to 99% first, so people complain. [04:17] My problem is that their minimum time is way too **** long! [04:18] DanaG: Is there a bug report for that? [04:18] 10 seconds to glance at 3 words. Reasoning fail there. [04:18] Or have you brought it up on the atayana list? I haven't noticed, but I may have missed it. [04:18] yup, digging it up now. [04:18] https://bugs.launchpad.net/debian/+bug/423314 [04:19] Launchpad bug 423314 in notify-osd "Unable to lower notification's expiry time than ten seconds" [Wishlist,Invalid] [04:19] Not sure why it's in Debian, and not in Ubuntu. [04:19] how about if the user is a kid learning to read? 10 sec for 1 word might be too little [04:19] Would a little kid be using notify-send? [04:20] Or are you just playing devil's advocate, or such? [04:20] =þ [04:20] Or whatever the term is. Taking arguments to the extreme. [04:20] I participate on a foundation that tries to get Edubuntu for 1st to 6th graders, so yes [04:21] hopefully they will [04:21] hmm, then they should make it NOT ignore the time specified! [04:21] That'd fix things. [04:21] There's already a solution... that they chose to throw away. [04:22] So I should bug every app that uses notifications for controls? [04:22] No, I mean more just for notify-send, specifically. [04:23] Many apps that use notifications for controls are currently broken, yes. They should get bugs. [04:24] while (true); do notify-send this sucks;done; [04:24] And watch it take 15 minutes for them all to go away. [04:24] That's a part of the specification that's yet to been implemented, yes. [04:25] also the fact that the notification dissipate when I mouse over it is counter intuitive, but I guess SABFL knew better [04:25] You have different intuition to me, clearly :) [04:25] oh, and now try moving your cursor over that stream of notifications. [04:25] It stops blurring. [04:26] Even if you jiggle the mouse. [04:26] So, that's a bug. [04:26] oh, and notify-osd is reeeeeeeeeeally really tiny for me, since I use half-integer font size 8.5. [04:27] Instead of 8 or 9 points, it looks more like I get, oh, 3 points. [04:27] Or 4. [04:27] when a human is alerted to something the natural reaction is to try to respond if I'm not mistaken [04:27] Wheras one of the goals of notify-osd is to not distract people. [04:28] I'd say it fails at that, too. =þ [04:28] It's not so bad; maybe it could be better. [04:29] again, if I don't get to pick how often or with what do I get distracted, then don't bother [04:29] And gnome-shell takes things to an extreme. [04:29] You can engage the don't bother me mode, and then you'll only get high priority notifications :) [04:30] http://users.csc.calpoly.edu/~dgoyette/Screenshot.png [04:30] gdm on another computer I have around here: http://users.csc.calpoly.edu/~dgoyette/GDM-Screenshot.png [04:31] RAOF, I meant don't bother trying ;) [04:31] heh, notify-osd is like the energizer rabbit. It just keeps going and going and , ,