[Bug 390508] Re: notifyOSD ignores the expire timeout parameter

2013-12-23 Thread Heather Van Wilde
@vanessax Buried in the comments is a patch that is supposed to restore full functionality. But that, for one, doesn't address the core issue, and secondly, does nothing to prevent the next change done to notify-osd by Ubuntu devs to rebreak the system down the road. -- You received this bug no

[Bug 390508] Re: notifyOSD ignores the expire timeout parameter

2013-12-22 Thread Heather Van Wilde
It's amazing. Three and a half years, almost to the day, since this 'bug' was first commented on. I use bug very loosely, because all it is is poor programming that the developer would rather defend than make the few small changes required to resolve this. There have been dozens of case uses ide

[Bug 390508] Re: notifyOSD ignores the expire timeout parameter

2013-05-13 Thread Heather Van Wilde
+4 on this insanity At this point to me it 's not even about the broken function anymore, it's the fact that this bug is coming up on it's 4th birthday and the maintainers still haven't gotten around to editing the two lines of code or updating the man page. In a commercial enterprise, a person w

[Bug 390508] Re: notifyOSD ignores the expire timeout parameter

2011-06-07 Thread Heather Van Wilde
@Holger - one of the points that had been brought up before is that yes, an individual can change the daemon or use the PPA, but what about those who make programs for redistribution (i.e. through Canonical). If you use the standard prerequisite of notify-osd than a new user will have a broken pro

[Bug 390508] Re: notify-send ignores the expire timeout parameter

2010-07-07 Thread Heather Van Wilde
@nstenz ... while i hate to back up the Ubuntu developer side in this issue, let me point out a flaw that has been brought up before: "The first sentence of the design spec for notify-osd clearly says it should implement the Desktop Notifications Specification." Unfortunately, should != must Ubu

[Bug 390508] Re: notify-send ignores the expire timeout parameter

2010-06-16 Thread Heather Van Wilde
@mindoms I've confirmed this with my copy of Lucid ... seems like a good enough workaround for the use that i had at least. -- notify-send ignores the expire timeout parameter https://bugs.launchpad.net/bugs/390508 You received this bug notification because you are a member of Ubuntu Bugs, which

Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter

2010-06-14 Thread Heather Van Wilde
The short answer from what i've understood of this whole thing is "Ubuntu dev team creates whatever is allowed to use instant-confirmation bubbles" and us private developers are out of luck. I still want to see if the patch put out will work on Lucid and if so, maybe it can be packaged downstream

[Bug 390508] Re: notify-send ignores the expire timeout parameter

2010-05-05 Thread Heather Van Wilde
> One could say that the bug is indeed upstream: It's in the man page, which should make it clear that some daemons might ignore the timeout setting. Coming back full circle to the question of why the developers are refusing to have the daemon make proper use, which ends up breaking other programs

[Bug 390508] Re: notify-send ignores the expire timeout parameter

2010-05-04 Thread Heather Van Wilde
@Holger Berndt That still comes back to the original problem. a) To do what you recommend, any application would have to create their own notification system to do exactly what notify-osd does, but is unable to interact with it. b) While your app (and any other app that has it's own notification

[Bug 390508] Re: notify-send ignores the expire timeout parameter

2010-04-03 Thread Heather Van Wilde
I ended up coming here because I want to enhance a python script that i have to operate a non-standard remote (Asus AI remote, not supported in Lirc). I want to use on screen notifications to display the status of the remote (I plan to program two different key maps depending on what mode I progra

[Bug 255678] Re: GSPCA webcam no longer working: no /dev/video0

2010-02-20 Thread Heather Van Wilde
oh, and on another note, it appears the commands need to be run every time you plug in the camera (and likely everyime you turn on the computer) -- GSPCA webcam no longer working: no /dev/video0 https://bugs.launchpad.net/bugs/255678 You received this bug notification because you are a member of

[Bug 255678] Re: GSPCA webcam no longer working: no /dev/video0

2010-02-20 Thread Heather Van Wilde
Oh, thank you, thank you, thank you ... i had the same errors as you did, but this command does work for me: sudo rmmod gspca_spca500 sudo rmmod gspca_main sudo modprobe gspca_spca500 after plugging in the camera ... got the same dmesg output. haven't tries skype yet though -- GSPCA webcam no

[Bug 255678] Re: GSPCA webcam no longer working: no /dev/video0

2010-01-30 Thread Heather Van Wilde
Tried dusoft's compat workaround, still not connecting to webcam. Camera: Intel CS630 Linux lumiere 2.6.28-14-generic #47-Ubuntu SMP Sat Jul 25 00:28:35 UTC 2009 i686 GNU/Linux (Jaunty) lsusb: Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 005 Device 001: ID 1d6b:0001 Linux F

[Bug 81170] Re: [feisty] etodo conduit times out when syncing with a palm device

2007-08-25 Thread Heather Van Wilde
Same problem as before, but with a different twist: Using Handspring Visor All current updates to Feisty, Evo and gnome-pilot With the eToDo conduit enabled to synchronize, it locks up just like everyone else's does. However, I have no items in either the Evo database or the Visor's, so it shou