[Bug 390508] Re: notify-send ignores the expire timeout parameter
+1 for fixing this to respect timeouts. After reading through these comments I can't believe Ubuntu devs are being so stubborn. I always believed in Linux and being able to configure things and here I am being blocked. This sucks. Better to take this out of Ubuntu then force us to live with it. Thank you for the Leolik PPA - I'll be using that. And hoping the devs get their sights re-aligned someday. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/390508 Title: notify-send ignores the expire timeout parameter -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
same thinking as remitaylor... Change manpage or do what manpages says... Anyway, you already miss the objective of having one consolidated osd notification tool: I quit osd_notify to older tools! -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/390508 Title: notify-send ignores the expire timeout parameter -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I just wasted a lot of time trying to figure out why neither the -t nor --expire-time options were working. This bug has been around for 1.5 years. It's confirmed with nobody assigned to fix it. Ridiculous. -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/390508 Title: notify-send ignores the expire timeout parameter -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Hi! I found this bug because I saw that notifications were ignoring my expiration time too (using dbus). About the option: notify-send --hint=string:x-canonical-private-synchronous: message Has an error, try this: The terminal with 2 tabs: In time order: - Tab1: notify-send Message - Tab2 (while bubble of tab1 is showing): notify-send --hint=string:x-canonical-private-synchronous: message1 notify-send --hint=string:x-canonical-private-synchronous: message2 The error is: You will see message1 while Message persists, and you'll lost message2 notification. I think the expiration time is important for some applications. Best regards. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Well, another: notify-send --hint=string:x-canonical-private-synchronous: message1 notify-send --hint=string:x-canonical-private-synchronous: message2 in the same time, you will lost message2... -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
The current behaviour of notify-osd, ignoring the timeout option, is unacceptable. I'm not even going to bother repeating any of the arguments presented in this thread. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Add my name to the protests. I applied Red-Acid's (#126) recommendation: both PPAs. It makes all the difference between a disrespectful and a respectful user experience -- dozens of times/day. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
My two cents: I found this bug because I noticed that notifications were ignoring my timeout on a script I was writing. Since this discussion seems to be pretty abstract, I'll provide a concrete usage case. I'm a 4th grade teacher and I use a projector hooked up to a tablet pc. Normally, I have a jar with Popsicle sticks on which I've written the names of my students. I pull a Popsicle stick to ensure that I'm calling on them randomly. This year, as I gear up for a new school year, I decided to write a script that pops up a random name from a list of my students. I tied it to an application launcher icon. It works. At first I was using a zenity info box to display the name, but it's ugly and requires you to click okay to dismiss it. This seems like a good case for a notification bubble to me. Because I'm expecting it and it only contains a student's first name, it doesn't need to stay on the screen for long. Also, it's important that it doesn't, because notifications are queued and if someone is absent, I need to be able to get another name quickly, so we're not all sitting around waiting for the bubble to disappear. I ended up using the: codenotify-send --hint=string:x-canonical-private-synchronous: message/code solution listed above, which is fine. But I feel like my case sort of underlines the point made by many people above. I spent twenty minutes messing around with the timeout argument, because, as a user, I expect command line arguments to work (I wasn't really aware that notify-send was a separate component from the notification system itself). Then I found this thread. Then I had to read through most of it to find an undocumented solution to my problem. I wish that it just respected the timeout argument. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Ok, I've read through this whole thread and I've got to side with the pro-custom-timeout people. This is friggin ridiculous. Here's another use case at the opposite end of the spectrum from most of the above: I have a perfectly good script built around notify-send I was using on Gentoo. It worked fine there with whatever DNS-compatible notification daemon I had installed (obviously not NotifyOSD). It's short and simple - it just watches the log file for a local application server and notifies me when it has stopped or started. Build, deploy and server restart cycles can take quite a long time - often 10-20 minutes plus. During that time I might wander away, or start doing something in another window, but I absolutely do not want to miss that notification. If I leave for 5 minutes and the server finishes restarting while I'm gone I want that notification to still be visible when I get back. So my notify-send call specified a pretty long duration (around 10 minutes). This was practical because whichever (superior) notification system was installed also allowed the user to close notifications early after they'd been read. I switched over to Ubuntu a couple weeks ago because I've been running it on my wife's machines for months and it's grown on me. I've been pretty happy with it overall - definitely some annoyances but Googling and liberal use of gconf have generally been enough to work around them. But I'm trying to get back up to functional parity with what I had in Gentoo, particularly work-related stuff like this monitor, and I've been banging my head against this bug/deliberate gimping for hours. I've installed the patched version of NotifyOSD from the PPA mentioned above, and it did take care of the timeout issue. But there appears to be no way for me to kill the notifications before they naturally expire. So I either run a very good chance of missing the notifications, or I see them and then they're stuck in the corner of my screen for ten minutes with no way to clear them. Not going to work. Several times in this thread it's been suggested that if you don't like the way NotifyOSD works you should install something else. That's a pretty ridiculous thing to suggest to developers planning to distribute their code, but since this is just for my personal use, fine. There seems to be a problem with that approach though - Synaptic won't let me uninstall notify-osd without also removing ubuntu-desktop, which seems like a pretty significant package. It seems like only one of these notification daemons can run at a time (which makes sense if they're all reading the same D-Bus messages). I tried installing notification-daemon without removing notify-osd and the system just keeps on using the latter. So I'm very confused as to what I'm expected to do at this point. If the Ubuntu devs truly think their alternate interpretation of the DNS spec is actually in line with the spec, then why wouldn't I be able to swap out their daemon for any other compatible daemon and still have ubuntu-desktop work? If ubuntu-desktop is transmitting proper messages based on the spec then anything else should be able to display them, right? Otherwise I don't see how Ubuntu isn't violating the same don't assume stuff about the notification server principle that others in this thread have used to criticize people complaining about the ignored -t parameter. Does anyone know if: - there's something I can manually edit to remove this dependency so I can switch to notification-daemon and still keep ubuntu desktop? - there is a way to run both NotifyOSD for ubuntu-desktop and notification-daemon for notify-send at the same time? Some way of telling notify-send to use an alternate D-Bus channel to connect with notification-daemon or something? - there is some other simple command to fire simple messages that actually works in the way I want? I don't care if these notifications blend in seamlessly with Ubuntu's. I just want something that will pop up, not steal focus, expire when I decide it should, yet let me manually close it early. Bear in mind this is an extremely basic script. This whole situation is disappointing. The beauty of the notification spec combined with notify-send is that throwing a nice looking GUI notification is no harder than echoing text to the console, and is just as cross-distro. Or at least it was up until this point. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Surprisingly there's no way to go back and edit these comments after posting (that I can find, anyway) and my questions won't help me much if they're hidden behind a click-through, so here they are again: Does anyone know if: - there's something I can manually edit to remove this dependency so I can switch to notification-daemon and still keep ubuntu-desktop? - there is a way to run both NotifyOSD for ubuntu-desktop and notification-daemon for notify-send at the same time? Some way of telling notify-send to use an alternate D-Bus channel to connect with notification-daemon or something? - there is some other simple command to fire simple messages that actually works in the way I want? I don't care if these notifications blend in seamlessly with Ubuntu's. I just want something that will pop up, not steal focus, expire when I decide it should, yet let me manually close it early. Bear in mind this is an extremely basic script. This whole situation is disappointing. The beauty of the notification spec combined with notify-send is that throwing a nice looking GUI notification is no harder than echoing text to the console, and is just as cross-distro. Or at least it was up until this point. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
That's a pretty ridiculous thing to suggest to developers planning to distribute their code If you plan to distribute something, you'll have to live with the lowest-common-denominator problem, and cannot rely on implementation details. Just like everywhere else. I don't see how it's ridiculous to recommend to use the tools that suit you the best. On the other hand, I find it pretty ridiculous to actually try to force your idea of good design to every single project out there, although alternative implementation do already exist. there's something I can manually edit to remove this dependency so I can switch to notification-daemon and still keep ubuntu-desktop? You seem to misunderstand the role of the ubuntu-desktop package. It's just a meta package that does nothing more than reference other packages, and brings you a default ubuntu desktop. You don't loose anything by not having that installed, and in fact you cannot have it installed if you want to remove referenced packages. There's nothing in that package except dependancies. However, you may very well have multiple daemons installed. In that case, the choice of deamons is made by normal D-Bus activation; in this case the system wide config file is /usr/share/dbus-1/services/org.freedesktop.Notifications.service -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Question- according to the notification design guidelines (https://wiki.ubuntu.com/NotificationDesignGuidelines), those of us who want to use notify-send's timeout option should be using something like a morphing alert box. Would it be possible to spit out one of those instead of a NotifyOSD bubble when notify-send has a timeout specified? Then you wouldn't have to pollute NotifyOSD with the naughty timeout code, but at least notify-send would be able to work properly. I know notify-send just sends a message out over DBUS and I believe there can only be one notification server on the other end, so I'm guessing the answer is it's not technically possible. Could anybody be kind enough to offer up a simple command like notify-send that displays a morphing alert box instead of a notification bubble? -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Just installed the patched Notify OSD to get around the lack of options in the official build. I'm very concerned about a noticeable trend in recent releases of Ubuntu. It seems highly impactful design decisions are being made that are contrary to the philosophies of open source software. I have used Ubuntu for years and been extremely happy with it until recently. There were a number of occasions that made me consider switching away: - when I realised that the Volume and 'Me Menu' shared the same icon group and could not be removed independently; - when I realised how utterly useless the Me Menu actually was; - when I realised that bad design decisions were being made centrally against all consensus (the left-aligned window buttons); The Notify OSD issue is another decision that has no design merit and only serves to distance experienced developers. These are all starting to make me feel that the direction that Ubuntu is taking is no longer for me. Design Guidelines should be just that - guidelines, not strict rules. Guidelines can be interpreted to ensure that developers can create exciting new software whilst sticking to the ethos of the guidelines. To actively deny the ability of developers and designers to interpret guidelines by removing functionality (that's what this is) is a Closed ethos. Distrowatch, here I come. Kevin -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
The open source philosophy has nothing to do with configurability, options, or features. I wonder where that idea comes from. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I think what he was getting at is that the open source philosophy is supposed to be about the will of the people, instead of the will of a select few from some corporation who seemingly know better and change things for no reason against what the majority of users want. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
This is a drama. I get really sad reading all this. This thread more then proves that there is a bug in notify-osd. Even if it is correct by the orginal design, this is still a bug. In that case we speak of a usability bug. Please fix it and stop sending people away from Ubuntu. Just because you cannot omit to a all-in-all small mistake. The biggest mistake of all being that we are not even allowed to vote on the matter. When people are given power however small and however well intended they are they will at some point abuse that power. That's what the ubuntu- dev's are doing here. This thread really goes through my heart. It rattles and shakes my believe in the Open Source philosophy. In conclusion use the PPA... And keep a eye out for an other distribution. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Seems that this Bug report has gone quite since the last time I was here. Well, if anyone is interested, someone has come up with a work around. They re-wrote the source code for notify-osd. Feel free to try it out...it works rather well. :-) http://www.webupd8.org/2010/07/patched-notifyosd-updates-option-to.html -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Yeah. People pointed out a number of situations where the fixed timeout is counterproductive (for both users and developers), and got nothing back but the decision is final, move to another distro if you don't like it. So I think everyone gave up arguing with a brick wall and installed the patched version of notify-osd. Or moved over to Fedora. Or something. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Has anyone sorted this bug out? This bug is really bugging me and buggy software ought to be debugged. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Il 07/07/2010 23:20, Sebastien Bacher ha scritto: Could you take those discussions somewhere else as requested before? Where? You disagree on the design choices there and don't see the value in having a system working on a consistent way No, and I'm not the only one. You seem quite sure that the ubuntu team is always right and the (l)users are always wrong and, being stupid, can't comprehend the great design behind notify-osd. At the moment I've never read a word explaining what consistent way means and what it is useful for. Where is the value? In what? Where is the value when lots of people complain about it? Instead, I already explained why it is much more reasonable, useful and natural to let the client chose the right (yes, the right) timeout. The DNS suggests the same. but it's the choice Ubuntu did for its notification system, you are free to use other softwares to replace this one or other system if you decide this one doesn't fit your needs, Sure, but we are talking about notify-osd. arguing over and over using the same arguments will not bring any addition value to the discussion Are you referring at your own messages? Well, this time I agree with you. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Where The list where the design is discussed, see comment #95 No, and I'm not the only one. You seem quite sure that the ubuntu team is always right and the (l)users are always wrong and, being stupid, can't comprehend the great design behind notify-osd. Nobody said that, the Ubuntu team just decided on a design for Ubuntu without any claim of being right or not, nobody said either that users are wrong or stupid. You could respect the choice of Ubuntu to take decisions on what they are doing, nobody is forcing you to use Ubuntu if you think the decision don't fit your needs either never read a word explaining what consistent way means and what it is useful for. Where is the value? In what? Consistent means that things are not changing randomly, notifications are always displayed in the same way, for the same time rather than have a bubble displayed for 1 second, then the next one 15 seconds, then the next one 45 seconds just because the software writers don't agree on what to do Where is the value when lots of people complain about it? Lot of people will complain anyway, what you call lot of is a matter of perspective, it's some vocal users on a bug report, user testing are being made as well and not only on technical communities and some users see value in having a system not acting randomly (why was that bubble displayed 3 seconds and now this one 8 seconds?) Instead, I already explained why it is much more reasonable, useful and natural to let the client chose the right (yes, the right) timeout. The DNS suggests the same. Let's agree to disagree and stop abusing this bug report? Design discussion should be moved to the lists where the people working on notify-osd and doing the design will read it rather on a bug report where you keep arguing with Ubuntu bug triagers who are neither deciding on the design nor coding on notify-osd. Not sure what DNS have to do with that discussion but DNS have nothing to do with visual design Sure, but we are talking about notify-osd. Right, so change Ubuntu by the notify-osd writers, why don't you accept that whoever is writing code can take decisions on what the said code behaviour should be? If you don't like it don't use it, nobody forces you to use notify-osd or Ubuntu -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
If you don't like it don't use it, nobody forces you to use notify-osd or Ubuntu Awful message to put across from an open source community based OS, and not really a solution. I think the middle ground would be different types of duration. Short, Medium, Long. Given 3 options would certainly help and partially avoid developers choosing different timeout durations. I still don't fully agree though. If an app wants to specify an odd or different timeout, then users will no doubt complain, or not use just that app. Or Ubuntu doesn't have to include it in the default build. Also the reason I gather for this bug report being abused, is because people have tried to open up other avenues to talk about this and they've been shut down or cut off. This is the only place we can voice our opinion. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Il 08/07/2010 10:54, Sebastien Bacher ha scritto: The list where the design is discussed, see comment #95 Fine. No, and I'm not the only one. You seem quite sure that the ubuntu team is always right and the (l)users are always wrong and, being stupid, can't comprehend the great design behind notify-osd. Nobody said that, the Ubuntu team just decided on a design for Ubuntu without any claim of being right or not, nobody said either that users are wrong or stupid. No, not directly. Ok, so, now, we can finally say that probably the Ubuntu team is wrong and there are no problem with our comprehension capabilities. Good. You could respect the choice of Ubuntu to take decisions on what they are doing, Sure, but since the Ubuntu team ask for users/comunity support we feel free to ask and discuss about this behaviour. nobody is forcing you to use Ubuntu if you think the decision don't fit your needs either Once again, no doubt, but this is not the right answer to the question why fixed timeouts should be better than variable timeouts?. never read a word explaining what consistent way means and what it is useful for. Where is the value? In what? Consistent means that things are not changing randomly, notifications are always displayed in the same way, for the same time Thanks, that was not difficult to understand. The point is that it makes no sense, so the use of this word, IMHO, is wrong. rather than have a bubble displayed for 1 second, then the next one 15 seconds, then the next one 45 seconds just because the software Just because some software need short bubbles while some others longer timeouts? We need this, it's really useful, while having the same timeout does not significantly improve the user experience. To do an example, it's like saying that in a car we'd better have fixed front wheels because they look consistent/uniform to the rear ones, while we need them to rotate and steer. It doesn't look very brilliant and doesn't seem to have much value. But still, there are various options available to maintain a sort of order, for example three different timeouts like bealer said, configuration options within the server and/or the clients and so on. Ignoring, always and totally, these possibilities is unbelievable. Where is the value when lots of people complain about it? Lot of people will complain anyway, Sure, but there are a lot of differences between a few and a lot, between reasonable objections and stupid requests. The tone used here shows that the Ubuntu team cannot see these differences. Moreover I don't think that common users pay too much attention about duration, while some power users do it. But we have the chance to make both happy, so why not? Not sure what DNS have to do with that discussion but DNS have nothing to do with visual design I was referring to the Desktop Notifications Specification. Right, so change Ubuntu by the notify-osd writers, why don't you accept that whoever is writing code can take decisions on what the said code behaviour should be? If you don't like it don't use it, nobody forces you to use notify-osd or Ubuntu Indeed I'm migrating back to debian, I just want to see how blind the Ubuntu developers are. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
bealer, opensource based doesn't mean you can't take design decisions or choices, we could try to fix every applications and blame random softwares installed from the internet for making ubuntu bug or we can enforce some design choices we believe benefit our users and communication to software writers on our design choice and how to well integrate with our system, it's what other very people device makers do for their system as well and users don't complain so much about the limitations since in the end it leads to things working nicely together in a consistent way because people have tried to open up other avenues to talk about this and they've been shut down or cut off. This is the only place we can voice our opinion. did any of you trying the ayatana list as suggested several times now? could you point where you got turned down from posting on it? The vast majority of people out there don't care about notifications, they don't care about softwares, they don't care about configurations or computer, they want to go on the internet, chat with their friends, etc. They want a system fast, easy to use and visual appeleant. They don't want to understand why some of the messages coming are different or to configure every softwares to behave different, that should just be working on be out of their way. Some of design decision taken in that project and others the dx team is working on will limit flexibility and enforce a consistent and easy to understand interaction. That will limit possibilities for softwares to do weird things and make the system feel buggy, that will simplify code, that will simplify interfaces and that will benefits users in the end. Now some people are very much wanting to have full flexibility and use it, the softwares you used to run are still there and you can still install those if you want, why is that so much of an issue? -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
bealer, opensource based doesn't mean you can't take design decisions or choices, we could try to fix every applications and blame random softwares installed from the internet for making ubuntu bug or we can enforce some design choices we believe benefit our users and communication to software writers on our design choice and how to well integrate with our system, it's what other very people device makers do for their system as well and users don't complain so much about the limitations since in the end it leads to things working nicely together in a consistent way Of course decisions have to be made, that's what this whole argument is about. People arguing the wrong decision has been made. Being open source and community based just means people can contribute fixes/patches (as per above), and also give feedback and be involved around these decisions. That seems to be lacking in this case. Decisions should be based on feedback. In this case from developers and users in terms of experience. At the moment developers are crying out for this feature. We don't know how users will be affected, because I would guess it's not been tried. There's nothing stopping you opening it up fully, and if it becomes abused, updating notify-osd so that timeouts can no longer be specified, or as I mentioned implement a few different levels of duration. The vast majority of people out there don't care about notifications Then let us set it to whatever we want! They don't want to understand why some of the messages coming are different or to configure every softwares to behave different, that should just be working on be out of their way They're not inclined to understand in many of the examples given. People have given examples of when overriding would be beneficial and improve user experience. In the case of the screenshot example, I think the user would be more inclined to think/ understand why the notification pops up for so long, or is included in the screenshot (not understanding that the dev that wrote it had no control over it), as opposed to if it came up quickly. With a notification app, you need to think how it's going to be used. We've defined plenty of use cases above. And from example use cases define an appropriate public interface. Not define how it should work, then try to fit the use cases around it. That's awful design and will either lead to poor user experience in the examples given, or people developing the same thing twice, so that they can open it up more. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Decisions should be based on feedback. In this case from developers and users in terms of experience. At the moment developers are crying out for this feature. We don't know how users will be affected, because I would guess it's not been tried That's not true, Canonical does organize user testing sessions and watch non technical users dealing with Ubuntu. We have been using the old notification-daemon which respects timeout settings for years before notify-osd. The complain there come from some technical users or softwares writers not so much from non technical users out there. With a notification app, you need to think how it's going to be used. We've defined plenty of use cases above. And from example use cases define an appropriate public interface. No, the current design is that notifications are unintrusive and just used to get informational content displayed. They are not used to display questions. They are not used to display important informations. They are not displayed when interaction is required. You can read those wikipages to understand the design principle for those choices: https://wiki.ubuntu.com/NotificationDesignGuidelines https://wiki.ubuntu.com/NotifyOSD The first document describes what other solutions Ubuntu recommends to softwares writers that need interactivity. You might think that using notifications and tweaking the way users interact with it is the only way but it's not. You might disagree on the design described there but give some credit to those who worked on it and read those, you will see that lot of efforts, thinking and real world usecases consideration has been in action and it not a decision made in an hurry to annoy users. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
That's not true, Canonical does organize user testing sessions and watch non technical users dealing with Ubuntu. Ok cool. I meant more specifically around notify-osd and just notifications but I know there will be a degree of user testing already going on. I also meant on the wider scale. User testing is always only ever a small sample of the user base. No, the current design is that notifications are unintrusive and just used to get informational content displayed. They are not used to display questions. I understand the guidelines, and it's fairly obvious otherwise it wouldn't be a notification system if it did more than just notify. Intrusive depends on how it's used. I could fire notifications all the time. And informational, well I could just put crap in the message, or put as much text as allowed to fully expand the notification. The use cases above define a perfectly acceptable instance where it's beneficial to be able to set the timeout, or at least have some finer grained lengths of notification. You're restricting that because you're worried about how people will mis-use it, when as mentioned above, I could totally abuse the notification system anyway. What's to stop me putting questions in, and firing it frequently (there is a limit but 50 but still). Why not open it up, and like with messages, and frequency, write some guidelines for duration. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Il 08/07/2010 13:49, Sebastien Bacher ha scritto: bealer, opensource based doesn't mean you can't take design decisions or choices, Right, but it's still possible to suggest a change or feature and maybe provide a patch for it (often developers don't spend time in features they are not directly interested in, but still agree to include features useful for others). we could try to fix every applications and blame random softwares installed from the internet for making ubuntu bug Are you talking about notify-osd? Using something defined in the DNS is a bug? or we can enforce some design choices we believe benefit our users and communication to software writers on our design choice and how to well integrate with our system, You forget that Ubuntu it's just one linux distribution, not the whole world. Basically, software developers don't care about notify-osd, they just create DNS compliant messages, so there's nothing to force. The vast majority of people out there don't care about notifications, they don't care about softwares, they don't care about configurations or computer, they want to go on the internet, chat with their friends, etc. [...] why is that so much of an issue? A simple option allowing the power users to switch from the default fixed timeout to client defined timeouts is easy to implement and doesn't disturb anybody that might not care. why is that so much of an issue?. But once again you won't reply. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
option allowing the power users to switch from the default fixed timeout to client defined timeouts is easy to implement and doesn't disturb anybody that might not care. why is that so much of an issue?. But once again you won't reply. There is no strong reason to not accept such changes out of the fact that extra code means extra bugs and the notify-osd team could not be wanting to deal with those. You can as well install the modified version somebody did in a ppa if that's personal use or reinstall notification- daemon from universe. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I feel compelled to comment again. I agree that tiered timings seem like a good compromise between uniformity and flexibility for developers. The current timing has led to my disabling notifications in several applications, but really it's more than the timing. It's a coupling of timing and location: Inability to customise timing makes a potentially inconvenient placement worse. Inability to customise location makes a potentially inconvenient timing worse. I think there's general agreement that notifications are useful to people and that the present system is transient in favour of a future, better solution. Thinking well inside the box here, it seems as though customisable timing represents a less arbitrary option. That is, placement is something coders probably don't care about and something non-coders can adapt to. Timing is something that coders do care about and something which can, if used appropriately, improve a user's experience. Tiered timing (short, medium, and long-duration messages) provides a means of enforcing a degree of timing uniformity while allowing that flexibility. I'll now install that Leolik PPA. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
That leolik ppa and notifyosd config is awesome. It's this microsoft attitude of We will tell the users what they want and they will like it that turned me off of windows to begin with. I don't know why ubuntu would want to cripple their OSD notifications like they have. How hard is it to just add a gui program to control all of this stuff like the ppa has done? I have considered switching to debian, but I am not sure how close they are to ubuntu? Does debian have the ability to use proprietary hardware drivers like ubuntu does? The only extra thing I would like to see in the notify osd config is the ability to have the notifications add themselves to the screen as default rather than queue themselves behind whatever is currently on the screen. This way, if you have a bunch of apps that are sending messages at once, you won't have to wait through a long line of bubbles. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Il 08/07/2010 17:22, Sebastien Bacher ha scritto: option allowing the power users to switch from the default fixed timeout to client defined timeouts is easy to implement and doesn't disturb anybody that might not care. why is that so much of an issue?. But once again you won't reply. There is no strong reason to not accept such changes But we are still discussing... out of the fact that extra code means extra bugs and the notify-osd team could not be wanting to deal with those. Which bugs such change could hide? We are talking about few lines of code... This is the usual excuse for not doing so, otherwise we should stop software development due to possible bugs introductions or regressions. The point is that the Ubuntu team reject everything that is not coming from themselves, right or wrong it doesn't matter. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@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 Ubuntu, in this case, has decided that even though they should do this, they don't want to. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
The first line of the Desktop Notifications Specification says In my copy, the first line says that it is a draft (!) document for async event notifications. The first line of the Desktop Notifications Specification says, The following messages MUST be supported by all implementations. There is no ambiguity. Yes. Believe it or not, notify-osd does indeed support all these messages, with the same signatures (so all parameters are accepted as well). That says nothing about how it interprets the parameters. (Yes, I know, specs are hard to read.) Concerning the interpretation of the expire timeout parameter, it's funny that you, while quoting so much from the spec, omitted the central sentence (probably because you didn't like it?): The timeout time in milliseconds since the display of the notification at which the notification should automatically close. There's a should, a recommendation. The spec does not demand that the expire timeout parameter is respected. (In fact, if it did, it would be a fishy spec - an implementation could just as well chose (or offer config parameters to let the user chose) to not display any non-critical messages at all, but just log them to a file. Timeouts of a few seconds don't make any sense in a log file.) Nothing in the spec says feel free to ignore this in your implementation, or developers beware- implementations are free to ignore this and still be called compliant (i.e. don't expect this to actually work). As pointed out before, the spec gives a clear recommendation as to what clients should expect: Clients should try and avoid making assumptions about the presentation and abilities of the notification server. Obviously, you're not following that recommendation. That's your choice, and also your problem. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Il 07/07/2010 12:02, Holger Berndt ha scritto: There's a should, a recommendation. The spec does not demand that the expire timeout parameter is respected. (In fact, if it did, it would be a fishy spec - an implementation could just as well chose (or offer config parameters to let the user chose) to not display any non-critical messages at all, but just log them to a file. Timeouts of a few seconds don't make any sense in a log file.) Is this the case? Is notify-osd specifically intended for file logging? No, it isn't, so why is a good thing not to follow this recommendation? After tons of messages still lacks a good answer to this question. And no, uniformity is not a good answer. As pointed out before, the spec gives a clear recommendation as to what clients should expect: Clients should try and avoid making assumptions about the presentation and abilities of the notification server. Obviously, you're not following that recommendation. That's your choice, and also your problem. This has nothing to do with the design choices made in the server, it doesn't explain why is good not to honor the clients timeout (independently of the client expectations). -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Could you take those discussions somewhere else as requested before? You disagree on the design choices there and don't see the value in having a system working on a consistent way but it's the choice Ubuntu did for its notification system, you are free to use other softwares to replace this one or other system if you decide this one doesn't fit your needs, arguing over and over using the same arguments will not bring any addition value to the discussion -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
to reply to comments about the notify-send documentation being unclear that's a real bug indeed and there is another ticket which is dealing with this one... -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Sebastien- where? Somebody tried to create a brainstorm thread for it, and if I'm seeing things correctly, it was shut down and nobody can vote for it. Correct me if I'm wrong- I've never used the brainstorm site. There's nothing wrong with the notify-send documentation. It's doing its job- it has no idea that notify-osd is on the other end, ignoring the timeout parameter. The only documentation change that would make any sense is the addition something that says IF notify-osd is the notification agent (default since Ubuntu x.xx), the timeout parameter is ignored. But why should the documentation for one package have to warn you about deficiencies in another that it might not even be interfacing with? -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
The first sentence of the design spec for notify-osd clearly says it should implement the Desktop Notifications Specification. The first line of the Desktop Notifications Specification says, The following messages MUST be supported by all implementations. There is no ambiguity. notify-osd does not use the expire_timeout parameter of org.freedesktop.Notifications.Notify. expire_timeout INT32 ... If -1, the notification's expiration time is dependent on the notification server's settings, and may vary for the type of notification. If 0, never expire. notify-osd always acts as though expire_timeout is -1. Nothing in the spec says feel free to ignore this in your implementation, or developers beware- implementations are free to ignore this and still be called compliant (i.e. don't expect this to actually work). Clearly, this is a bug (that it's by choice is irrelevant). Apps written to be fully compliant with the Desktop Notifications Specification using the expire_timeout parameter have notifications that do not work correctly on Ubuntu. That is _unacceptable_. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Before I get scolded: You may find that I posted a very similar comment on bug #257135, regarding the lack of access to replaces_id, however this comment is regarding the behavior of --expire-time. Red_Acid++ Leolik's notify-osd + notifyosdconfig = vastly superior, and faster, messages. There's still a little funniness with the --expire-time parameter however. Case in Point: To get messages at the speed of channel surfing, temperature changes, bandwidth use, etc, etc, etc it's necessary to set an arbitrary, system-wide timeout of 1sec with notifyosdconfig (see above PPAs) and set --expire-time 1000. This makes a notification which blinks in and out of existence since an expire time of anything less than 1000 is equal to 0. I'd actually like to have messages linger for about 600~800msec, which I figure to be ample time for reading a channel number (and could also be useful for reading many kinds of things that don't need to be studied carefully). To be precise I want to do this (note the imaginary --replaces_id parameter): notify-send --replaces_id=tvchannel --icon=gtk-info --urgency=critical --expire-time=750 Channel $CHANGE `ivtv-tune -x $CHANGE` -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I don't know want is happening along the conversation in this 'thread', I'm just posting this to inform everyone who's interested in customizing notify-osd. - Sukochev Roman (Leolik) as a PPA with notify-osd which add the function of reading settings from ~/.notify-osd, and by my recommendation, now it has the patch created by Ankur Nayak, so it provides the timeout option too. If you want it, just install the PPA: https://launchpad.net/~leolik/+archive/leolik And if you want a nice way of configuring this notify-osd, install this notifyosdconfig: https://launchpad.net/~amandeepgrewal/+archive/notifyosdconfig -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
It is incredible. It is as simple as: notify-send --hint=string:x-canonical-private-synchronous: Hell Yeah This creates a bubble that is treated like Brightness, so it stays there for about 2 seconds The -t option is ignored though -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
So the argument about users and their experience, or how you think it should be used goes out the window if developers can and are starting to get around it. In which case you may as well just open it up properly for use. It's confusingly documented that way, and people have requested the change (with decent use-cases). If you want to set a global timeout across the whole OS, then it's no good having work arounds as mentioned above. Take a look at other notifiers like snarl, ruby-libnotify, jquery notifications, or even when writing Windows apps it's possible to set a timeout. Of course they all must be wrong to offer that sort of override. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@mindoms Not so easy, in fact. If you bring up one of the regular time-out broken message boxes and a synchronous box at the same time, the synchronous box lives for the duration of the broken box, at least on my machine. This is a happy advancement, though. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I just wasted some time trying to figure out why what I am doing wrong in passing the timeout parameter to notify-send. Could you please resolve this bug by updating the man page to tell users, that the timeout parameter does not work with Notify-OSD? That would save people like me from wasting time on this in the future. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
/sign
I also wasted a lot of time trying to figure out what's wrong.
Stoto
Sent from my iPhone.
On 2010.06.14., at 10:00, Otto Kekäläinen o...@sange.fi wrote:
I just wasted some time trying to figure out why what I am doing wrong
in passing the timeout parameter to notify-send.
Could you please resolve this bug by updating the man page to tell
users, that the timeout parameter does not work with Notify-OSD? That
would save people like me from wasting time on this in the future.
--
notify-send ignores the expire timeout parameter
https://bugs.launchpad.net/bugs/390508
You received this bug notification because you are a direct subscriber
of the bug.
Status in “notify-osd” package in Ubuntu: Confirmed
Bug description:
Binary package hint: libnotify-bin
adyro...@panther:~/libnotify-0.4.5/tools$ lsb_release -rd
Description:Ubuntu 9.04
Release:9.04
adyro...@panther:~/libnotify-0.4.5/tools$
adyro...@panther:~/libnotify-0.4.5/tools$ apt-cache policy libnotify-
bin
libnotify-bin:
Installed: 0.4.5-0ubuntu1
Candidate: 0.4.5-0ubuntu1
Version table:
*** 0.4.5-0ubuntu1 0
500 http://ro.archive.ubuntu.com jaunty/universe Packages
100 /var/lib/dpkg/status
adyro...@panther:~/libnotify-0.4.5/tools$
adyro...@panther:~/libnotify-0.4.5/tools$ cat notify-send.c | grep
expire_timeout
static glong expire_timeout = NOTIFY_EXPIRES_DEFAULT;
{ expire-time, 't', 0,G_OPTION_ARG_INT, expire_timeout,
notify_notification_set_timeout(notify, expire_timeout);
adyro...@panther:~/libnotify-0.4.5/tools$
To unsubscribe from this bug, go to:
https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/390508/+subscribe
--
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 is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
From back in post #19 by Matthew Paul Thomas: volume, brightness, and eject bubbles are instant confirmation (synchronous) of something you have done, whereas notification bubbles are not-necessarily-instant notifications (asynchronous) of something someone else has done. ...so, how does one create one of these instant-confirmation bubbles? Because the reason I've been complaining is because I want to pop up a quick notification in response to a keypress. And if there isn't a way to do that, then why are those three button-pressing confirmations given special treatment while mine aren't? -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
...so, how does one create one of these instant-confirmation bubbles? The design spec for notify-osd has been linked several times in the comments of this report. I'll paste the link again for your convenience, even though usage questions seem off-topic in a bug tracker: https://wiki.ubuntu.com/NotifyOSD -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
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 with my particular derivative (I use linux mint) Holger seems to get annoyed whenever someone questions the dev teams decision, that's why i didn't post this in the bug thread Heather L Van Wilde True discovery lies in seeing what everyone else sees and finding what no one else has found From: Kent deVillafranca k...@kentdev.net To: heather...@yahoo.com Sent: Mon, June 14, 2010 7:57:33 AM Subject: [Bug 390508] Re: notify-send ignores the expire timeout parameter From back in post #19 by Matthew Paul Thomas: volume, brightness, and eject bubbles are instant confirmation (synchronous) of something you have done, whereas notification bubbles are not-necessarily-instant notifications (asynchronous) of something someone else has done. ...so, how does one create one of these instant-confirmation bubbles? Because the reason I've been complaining is because I want to pop up a quick notification in response to a keypress. And if there isn't a way to do that, then why are those three button-pressing confirmations given special treatment while mine aren't? -- notify-send ignores the expire timeout parameter https://bugs.launchpad.net/bugs/390508 You received this bug notification because you are a direct subscriber of the bug. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I'll throw my own example in here: I wanted to write a quick script that would pop up a Touchpad enabled/Touchpad disabled notification. I wasted an hour trying to find out how to change the notification's duration to 1 or 2 seconds, and how to make it stop obscuring more important notifications (like if I lose my connection to the wireless network, etc.). Then I found this bug report and discovered that those annoyances were _intentional_. What the hell?! -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
you want to do this, some other for 6 seconds, some for 18 seconds, and we get a system working in a non consistant way for no real reason out of different software writters having different preferences for timing Umm, I'm the software author, how about letting ME decide what timing is appropriate for MY notifications, of which libnotify is merely a conveyor? I do believe I know best what timing to use. How is it possible that authors of a completely different lib pretend to know such things better than me, the author? Ubuntu decided to make a call for consistent system interaction and not random timing behaviour which most users are glad for I beg to differ. These notifications suck. And there's plenty of evidence on the forums and on the web, if you're willing to read it. The fact they stay up for so long, the fact you can't put more than one at a time up (the second one is reserved, really), the fact they obscure information on screen, the fact you can't customize position and transparency etc. if you don't agree with that feel free to use another notification service or distribution I'm sorry but this remark is brain-dead. The very idea behind this notification library was that everybody would use it. How can you say use something else? What good is that? I'll say this again (said it above): if you attempt to provide an unification library, you want everybody to be able to use it. If only select software can use it, it's no longer a unifying library, it's just another alternative. And you have FAILED in your attempt to offer unification. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@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 system) tries to post at the same time, they either need to use the same notify system or overwrite each other on the screen space c) A fantastic idea would be a rewrite of the notify-osd type program to better allow integration of numerous messages at once. notify-osd already has the ability built in to show two bubbles at once (for proof of concept, I changed the volume from my keyboard and immediately changed the song using my keyboard in Ryhtmbox. Attaching screen shot) d) This rebuilt program would still be incompatible with the official notify-osd package, so the official package would have to go. e) Matt Thomas @ post 29 has already threatened anyone who wants to build a distributable notify program when he said Ubuntu Software Center will issue a warning if installing it involves uninstalling anything else (such as notify-osd) f) That puts us back to the same spot we were in originally. It appears to me that Mozilla is using the specs as the notify-send man page still gives information for using a time-out when sending to it. At this point, my question would be, how far upstream is this bug? It's obvious that it affects all unpatched Ubuntu derivatives (I use Linux Mint 7 - Gloria). Was the software developed at the Ubuntu level? If so, it might be worth investing in looking for some of these libraries directly from Debian, which if I understand correctly is upstream from Ubuntu. ** Attachment added: Proof in concept for multiple notify-osd messages from stock software http://launchpadlibrarian.net/47847095/Screenshot-2.png -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@Heather Van Wilde 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. No, that's not true. You can trust me on that - as it happens, I wrote notification spec integration for another Mail User Agent myself, which works exactly as I described above. notify-osd already has the ability built in to show two bubbles at once Actually, that's another thing that notify-osd cut down on. The upstream GNOME implementation notification-daemon allows much more bubbles to be displayed at the same time. But it doesn't really solve Torres' problem either: Having hundreds of bubbles from the same application on screen at the same time is not a pleasant experience. (To be fair, I am sure the upstream implementation has a display limit and a queue, too.) [Cutting most of your points, as they are based on the wrong assumption in a)] as the notify-send man page still gives information for using a time-out when sending to it. At this point, my question would be, how far upstream is this bug? 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. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
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 (Thunderbird as explained earlier tonight) and make it so developers can't create new programs, and forcing said developers into using a tool that is unable to suit their needs. In my case, as I described before, I want to use notify-osd to display a one or two word message for a second or two. No dialog box, nothing to click, and nothing on the taskbar. I am running all my stuff through a Python script (it's basically a fancy key mapper) so i'm not about to create a whole new osd application for this. People have asked for examples of what these things are wanted for. Here's my example. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
The discussion is circling, could you take the chatting to mailing list of an another media than the bug tracker? use notify-osd to display a one or two word message for a second or two you want to do this, some other for 6 seconds, some for 18 seconds, and we get a system working in a non consistant way for no real reason out of different software writters having different preferences for timing, you might consider that good but Ubuntu decided to make a call for consistent system interaction and not random timing behaviour which most users are glad for, if you don't agree with that feel free to use another notification service or distribution -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Holger Berndt wrote: No, that's not true. You can trust me on that - as it happens, I wrote notification spec integration for another Mail User Agent myself, which works exactly as I described above. OK then, how, using notify-send, would you achieve this? You can't, because *notify-send* is broken. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I came to this thread because I'm really annoyed by an add-on to Thunderbird, named Gnome Integration, that displays a bubble every time I receive a email, using notify-send that stays on my screen for not less than 10 seconds. Well that's ok if it's just one email but, when I first start my computer every morning, there are always tens or hundreds of emails waiting to be downloaded by Thunderbird. Every single email creates a bubble and they are displayed in sequence for 10 seconds each one. Sum that up and you'll have an idea of my ordeal. It's common that I finish scanning the whole lot of emails and switch to something else before all the bubbles are gone. The add-on has a configuration gui and one of its options is the time out. I was getting annoyed that whatever the amount of time I set there, there was no change in behaviour and I started googling for a solution. That's how I came across this bug report. It makes me sad that no interest is shown by the Ubuntu team to either tackle this issue or, at least, give us (users and developers alike) a feasible alternative to get what we want/need. I went through this hole thread looking for an easy solution for my issue and the only one I could find was a patch to notify-osd to allow setting different time outs. The problem with that is that, although I'm a developer for other platforms, I don't have the smallest clue as how to apply the patch and recompile the package. So, I think my only solution is to disable (or uninstall?) the add-on until there's a solution to this or until I find another add-on that does the same as Gnome Integration without using notify-osd. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@Airton Torres: Fiddling with timeouts sounds like an exceptionally strange way to solve that particular issue. So, you'd still like to have tens or hundreds of bubbles, flickering unreadably on your screen with short timeouts? Doesn't make any sense to me. Developers already have a way to avoid notification spam of their software: They can update their own bubbles. Other mailers do it like that: When the first mail arrives, it gets a bubble (Mail from Foo with subject bar arrived). When the second mail arrives, and the bubble is still on-screen, the bubble is simply updated (2 mails arrived). When the 272th mail arrives, the very same bubble says 272 mails arrived. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I don't have the background or knowledge to understand the reasoning underlying the design decisions behind notify-osd so I will refrain from demanding design changes, even though it seems a little bit peculiar that having a configurable time-out (with a max-time perhaps) could hurt that much. But, from a use case of view there are two very different scenarios that fits the use of notify-osd and demands different time-outs: 1. Un-solicited notifcation (for example, mail arriving) 2. Pop-up response use case (for example, outcome of runned script) In the first case, a longer time-out is justified in order for the user to notify it, but in the second case, where the user watches the screen, waiting for the response, the long time-out is annoying. I bet 95% of all complainers use the notify-osd as in the second example. These two use cases would require different time-outs. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
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 program the remote to) The old idea of a dialog box that the user clicks is not acceptable for me, because my end goal is to have completely remote based control when using it for music or videos (making a micro remote for a HTPC, basically). Notify-osd appeared to be a perfect way to notify what mode the remote was operating on at the time, and while I can still use the command even with an unpatched notify-osd package (call the osd information every 4.9 seconds that the remote is in the alternate mode), and would work for what I want it for (it only needs to be in that mode for 5-10 seconds anyway, so it will have minimal impact on other programs access to those calls) It is very dirty programming, especially if i plan to re-release this script in the wild one day. Yes, I could make a package level program with it's own system tray icon showing the status and all that fun stuff, but do I really want all that effort for what I know is a niche program when all the tools exist already in the default installation? Not to mention that replacing the notification system with another one brings up it's own problems. First off, anyone installing your app will have to remove notify-osd to put in your preferred flavor. And point B, I refer back to post 29, where it was stated: And regardless of how the package is distributed, the Ubuntu Software Center will issue a warning if installing it involves uninstalling anything else (such as notify-osd) So, no, if anyone plans to redistribute a program using any notification daemon included with Ubuntu that is not notify-osd, we get in trouble. The only options that are left (as the developers want to say) is to use an incomplete/broken program, or to custom build our own notification systems, which have little to no compatability with the existing system already installed. It appears to me to be a lose/lose situation for everyone. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Just as a humble request - for whoever gets to read this thread. If you came here because you were bugged by the behavior of notify-osd ignoring expire-timeouts, please post on this thread - maybe one day we'll be enough people to get the developers thinking. -- Support Wikipedia: http://wikimediafoundation.org/wiki/Donate/en http://volunteer.wikimedia.org/ -- DRM 'manages access' in the same way that jail 'manages freedom'. On Mon, Mar 29, 2010 at 2:13 AM, Finog fi...@yahoo.com wrote: Hey, I was just writing up some bash cron scripts today to notify me about system temperature and, 'lo, I can't control the time these messages display for. That's rather ridiculous. I've read most of the discussion here and agree with those who see this as being a flaw with notify-osd. -- notify-send ignores the expire timeout parameter https://bugs.launchpad.net/bugs/390508 You received this bug notification because you are a direct subscriber of the bug. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Hey, I was just writing up some bash cron scripts today to notify me about system temperature and, 'lo, I can't control the time these messages display for. That's rather ridiculous. I've read most of the discussion here and agree with those who see this as being a flaw with notify-osd. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
@Holger The scope of the work in this bug report is notify-osd, not Ubuntu in general. While it is possible to install something else, that's besides the point. Within the scope of this bug report (notify-osd): - one option is to ask the application for the timeout (make the timeout parameter mandatory, there's no default); - second option is to set a default (5 seconds) and allow it to be overridden with the timeout parameter; - third option is to hard-code all notifications to 5 seconds. Within the scope of a linux distribution, that would be equivalent to: - provide all the different conflicting packages (as it was before Ayatana); - provide one default and allow users to install others if they so choose (what was specified with Ayatana); - provide one application and remove all others from the repository (similar to what's happening here with notify-osd). The analogy is pretty clear, unless you want to pretend you don't understand. The suggestion to install another set of packages that provide the same function, within the scope of this bug report, is similar to suggesting to install a different distribution in response to Ayatana, within the scope of the linux distribution. -- Support Wikipedia: http://wikimediafoundation.org/wiki/Donate/en http://volunteer.wikimedia.org/ -- DRM 'manages access' in the same way that jail 'manages freedom'. On Wed, Mar 24, 2010 at 8:15 PM, Holger Berndt bern...@gmx.de wrote: @Adrian Roman: Weird analogy. You can do the same with notify-osd as you can do with other default applications: Replace it with an alternative from the repository if you don't like the feature set. notification-daemon would be an alternative to notify-osd that offers the features you want. Why don't you just go ahead and use that one instead? Ryan J: By reading the spec and following it. That surely applies both ways, server and client side. Does your client follow Clients should try and avoid making assumptions about the presentation and abilities of the notification server. ? Besides that, that spec is a draft that is under revision anyways. People have expressed their unhappiness with specific parts (e.g. some KDE folks don't like clients being able to query server capabilities, as that breaks model/view separation etc). @Marco Chiappero: And we don't really care about you telling us what's right or wrong for us. I am not telling you what's right and wrong for you (who is we? Majestic plural?). I'm trying to tell you what notify-osd is all about. See above - if it doesn't fit your needs, use notification-daemon instead. That one respects timeouts, and is more configurable in general. Alternatively, try to convince the notify-osd designers (I am btw not one of these) that timeouts are vital. People do tend to change their mind when something is well argued. It has been advised before that this better be done on the corresponding mailing lists, as designers don't generally read bug reports. -- notify-send ignores the expire timeout parameter https://bugs.launchpad.net/bugs/390508 You received this bug notification because you are a direct subscriber of the bug. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I made a ppa package using the patch by Ankur Nayak. ppa:fkalman/main -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@Holger: Guys, you just don't seem to get that notify-osd is about unification and consistency amongst applications using it. In other words, in order to achieve a unified framework, make developers unable to use it, so they will have to use _another_ framework. LOL. Doesn't that strike you as defying the very goal you were aiming for? :) The only way you can realistically achieve the above is if all the applications that can't use notify-osd are not available for Ubuntu. I'm guessing that's not what you want. Jokes aside, please, give us a viable alternative. We can't use notify- osd and you don't want us to use another framework. What SHOULD we do? -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Question: what if we open up a PPA repository and maintain a patched version of notify-osd? We can direct users who complain about the timeout to install the PPA version. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@Adrian Roman: Weird analogy. You can do the same with notify-osd as you can do with other default applications: Replace it with an alternative from the repository if you don't like the feature set. notification-daemon would be an alternative to notify-osd that offers the features you want. Why don't you just go ahead and use that one instead? Ryan J: By reading the spec and following it. That surely applies both ways, server and client side. Does your client follow Clients should try and avoid making assumptions about the presentation and abilities of the notification server. ? Besides that, that spec is a draft that is under revision anyways. People have expressed their unhappiness with specific parts (e.g. some KDE folks don't like clients being able to query server capabilities, as that breaks model/view separation etc). @Marco Chiappero: And we don't really care about you telling us what's right or wrong for us. I am not telling you what's right and wrong for you (who is we? Majestic plural?). I'm trying to tell you what notify-osd is all about. See above - if it doesn't fit your needs, use notification-daemon instead. That one respects timeouts, and is more configurable in general. Alternatively, try to convince the notify-osd designers (I am btw not one of these) that timeouts are vital. People do tend to change their mind when something is well argued. It has been advised before that this better be done on the corresponding mailing lists, as designers don't generally read bug reports. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Holger Berndt ha scritto: @Adrian Roman: [...] Why don't you just go ahead and use that one instead? Probably because he had a look at http://www.ubuntu.com/community/ or http://www.ubuntu.com/community/participate/, considers notify-osd a better option and wants to suggest how to improve it a little bit. However you're somehow right, but looking at the replies from the Ubuntu team, IMHO, the correct question should then be: Why don't you just go ahead and use another distribution instead? Ryan J: By reading the spec and following it. That surely applies both ways, server and client side. Does your client follow Clients should try and avoid making assumptions about the presentation and abilities of the notification server. ? Besides that, that spec is a draft that is under revision anyways. People have expressed their unhappiness with specific parts (e.g. some KDE folks don't like clients being able to query server capabilities, as that breaks model/view separation etc). Well, I don't know any detail about it and I'm not experienced with it, but I'd say it is fine not to make any assumption if then a sort of negotiation capability or query model is present (I know nothing about the server but I can ask it about its own abilities). Otherwise it looks to me that a client developer has no chance to know in advance whether he will obtain what he wanted or not. So, again, why should developers spend time using something that comes with no guarantee at all to work or to work exactly as they expected? @Marco Chiappero: And we don't really care about you telling us what's right or wrong for us. I am not telling you what's right and wrong for you You keep on telling us that the problem lies elsewhere, because it's easier to say that we didn't understand the aim of notify-osd, that we are using it improperly and for the wrong task, that application using it are broken and so on instead of admitting that notify-osd comes with an unmotivated limitation and/or lacks a few basic configuration options. BTW, you probably shouldn't be using is from you, right? (who is we? Majestic plural?). We, all the people complaining. Quite a lot here. Alternatively, try to convince the notify-osd designers (I am btw not one of these) that timeouts are vital. Nothing is vital, neither having a good looking bubble. But desirable? Sure. People do tend to change their mind when something is well argued. It looks like you've read just a couple of comments in this report... As for me, as I already said, one important reason for using the timeout field from application (when a specific value is present) is that the notification daemon knows nothing about the message purpose, content and meaning. In other words the applications know better than notify-osd how much time is suitable/comfortable/needed for the user to read the message. It has been advised before that this better be done on the corresponding mailing lists, Ok, which one? as designers don't generally read bug reports. But some other people from Ubuntu do. I think they should care about forwarding interesting topics or suggestions to the right person/people. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Question: what if we open up a PPA repository and maintain a patched version of notify-osd? We can direct users who complain about the timeout to install the PPA version. At the same time, the PPA could also include a fix to lucids moving the title bar buttons over to the other side and giving users no gui option of moving them back, it could also get rid of the shutdown restart and logout confirmation dialogs that also have no gui way of fixing, along with the ability to put update notifier back to the system tray. Ubuntu just seems to love forcing weird changes on its users for no real reason at all, and not even giving them the ability to switch back without knowing how to use gconf.. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
@Holger on Ayatana That's an interesting philosophy for a linux distribution, but bear in mind that in that case, they did not delete all the other packages from the repository. If you don't like the default application shipped with the Ubuntu install CD, you can very well go ahead and install any others from the repositories. Ignoring timeouts (enforcing the defaults) is similar to removing all the applications that conflict with the defaults from the repository. The problem is not with setting a default - that's fine; the problem is with forcing people to use that default even if they don't want to. -- Support Wikipedia: http://wikimediafoundation.org/wiki/Donate/en http://volunteer.wikimedia.org/ -- DRM 'manages access' in the same way that jail 'manages freedom'. On Tue, Mar 23, 2010 at 1:59 AM, Holger Berndt bern...@gmx.de wrote: Totally wrong No, it's not. Denying reality may be fun, but it's not helpful. I was not talking about what you'd like, but about what notify-osd is aiming at. It is part of project Ayatana, and here's a statement about configurability in that project: http://www.mail-archive.com/ayat...@lists.launchpad.net/msg00747.html Oh really? That's strange, because it fits perfectly my needs Obviously, it doesn't, because otherwise, there wouldn't be any need to complain. BTW, I'm not a luser, I'm a computer engineer (and developer as well), I didn't say anything about lusers. And I don't really care for your engineering background, but thanks for telling me. It's got nothing to do with the discussion at hand, though. so I think I'm able to evaluate that by myself, thanks. So just go ahead, and evaluate if notify-osd fits your needs. Because in fact, it doesn't seem like you did that yet. You're evaluating how notify-osd should change it's design to fit your needs. That's not the same thing. Oh well, finally we discovered the problem: the others Yes, if you rely on notification daemon specialities, you're doing something wrong. For comparison: Here's what the KDE notification daemon developer (completely unrelated to notify-osd) has to say about how and where Galago notifications may end up in KDE: http://markmail.org/message/hxvahasqoemkuhp5#query:+page:1+mid:ij55nyqffhbf3gvs+state:results http://markmail.org/message/hxvahasqoemkuhp5#query:+page:1+mid:hgigaz6777qubzet+state:results How does a developer know how his notification is going to look or behave? If it's not in-house code, he can't. Thus, he can't rely on presentation, or, in other words, if he needs to rely on presentation, it's not the right infrastructure to use. -- notify-send ignores the expire timeout parameter https://bugs.launchpad.net/bugs/390508 You received this bug notification because you are a direct subscriber of the bug. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
@ Krzysztof: As far as I'm concerned, that would solve my problem; but bear in mind that the issue here is not that my personal problem with notify-osd needs to be solved. Other people may want longer notifications on the screen. Same with replace and merge. The issue here is that the developers want to enforce some unnecessary, useless and frustrating restrictions on how people use their code. Some people argue it's their right. I'm not going to say it's not, it's just that without understanding the specific benefits this position is bringing to the community, it seems they're not really following their mantra. If it was Microsoft or Apple - I wouldn't have bothered to argue on this thread - we all know they want to enforce their interests on their users, and charge you for it. It's just that it's Linux, and we're used to freedom and community-oriented decisions rather than corporatist bull motivated by greed. -- Support Wikipedia: http://wikimediafoundation.org/wiki/Donate/en http://volunteer.wikimedia.org/ -- DRM 'manages access' in the same way that jail 'manages freedom'. On Mon, Mar 22, 2010 at 11:50 PM, Krzysztof Jelski kjel...@gmail.comwrote: How about leaving hardcoded limit for MAXIMUM timeout only? So that other notifications wouldn't get blocked. Developers (or users of notify-send) would be able to set the timeout from 1 ms to let's say 5 secs. I guess it would solve 99% of problems mentioned here, wouldn't it? -- notify-send ignores the expire timeout parameter https://bugs.launchpad.net/bugs/390508 You received this bug notification because you are a direct subscriber of the bug. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
I think it might be a good idea if someone could take an initiative and post this issue on the Ayatana mailing list. We might get better answers/resolutions there. Please remember to post the link to the specific mail archive here, if it doesn't hurt. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
You just cannot rely on specific timeouts, or specific behaviour. In
fact, you can't even rely on your notification being visible at all. The
notification daemon could just as well not display anything, but write
the message to a log file (which obviously never times out).
If the only guarantee is that notifications get sent 'somewhere', then
what's the point of even having it? Are you saying that anyone
developing an application that needs to provide visual notifications to
their users shouldn't use any of the notification daemons _at all_,
because that's what it sounds like to me?
How does a developer know how his notification is going to look or
behave?
By reading the spec and following it. That's the reason I've posted in
this bug report. In my opinion the notify-osd developers ignored part
of the spec and, because notify-osd is in Ubuntu, everyone else is
forced to work around their _opinion_ of a suitable timeout value or to
ignore Ubuntu which is a much worse option.
I use notify-send with a single script that rsyncs some data once every
5 mins. When the script runs successfully I use a 3 second
notification. When it fails I use a 15 second notification. I want
both to be relatively unobtrusive, but (in my opinion) it's more
important to see a notification about a failure condition than it is to
see one about success.
I still want a notification when my script runs successfully, because I
want to _know_ that it's running. If it's running properly I don't mind
missing the (short) notification two or three times in a row and, since
I'm used to seeing it, I can read it in about 2 seconds. However, if it
fails I'd prefer to see the notification as soon as possible and want a
little more time to read it (definitely more than 5 seconds).
Is there another solution better than notify-send that I can use that
will push an unobtrusive notification to my desktop. Keep in mind my
script took about 60 seconds to write. Am I mis-using notify-send?
Completely ignoring the argument of what is required by the spec, I
think it was a poor design decision for notify-osd to make _all_
notifications so similar looking. As a user I want (critical)
notifications about something failing to stay on the screen longer and
have a more prominent look to them. I can't be the only user that takes
more time to interpret a failure condition (that I rarely see) than I
take to interpret a success condition (that I'm expecting because I see
it all the time).
I've also seen comments suggesting that allowing a longer timeout will
allow developers to block notifications from other applications by
setting a long timeout value. I can already cause considerable delay by
sending multiple messages to the daemon in short succession. Ex:
for i in {1..3}; do notify-send Hello World $i; done
Had I not taken the time to patch notify-osd, the above would have been
my solution for displaying a longer notification. Is that the kind of
behavior anyone wants to encourage? I'd think that adding some spam
control to the notification queue would be more important to the users'
experience than forcing all notifications to use a 5 second duration.
--
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 is subscribed to Ubuntu.
--
ubuntu-bugs mailing list
ubuntu-bugs@lists.ubuntu.com
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Holger Berndt ha scritto: Totally wrong No, it's not. I have clear in mind what is the aim of notify-osd. But I still don't see any reason why that goal is achived by imposing *every* user a fixed 5 seconds timeout. I was not talking about what you'd like, but about what notify-osd is aiming at. It is part of project Ayatana, and here's a statement about configurability in that project: http://www.mail-archive.com/ayat...@lists.launchpad.net/msg00747.html We are neither talking about good defaults nor about extended configuration options. But you ignores it. Oh really? That's strange, because it fits perfectly my needs Obviously, it doesn't, because otherwise, there wouldn't be any need to complain. No, it fits perfectly, but I do prefer to have different timeouts. What I'm complaining here mostly and what bothers me is the Ubuntu team arrogance and blindness. And the lack af good arguing for this limitation. And I don't really care for your engineering background, And we don't really care about you telling us what's right or wrong for us. Oh well, finally we discovered the problem: the others Yes, if you rely on notification daemon specialities, No need for long stories, I'm not relying on anything, I just want to see a bubble message on my desktop with notify-osd, because I like it, except for the fact that it does not take into account the timeout parameter passed from the application (while it easily could without breaking the unification purpose). How does a developer know how his notification is going to look or behave? Even though I like the new notification system, about this specific topic and about relying on the popup being show or having all the action, I might ask you why developers should use something that comes with no guarantee to work or to work exactly as they expected. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Think this discussion has gone on too long and is going nowhere. It needs to be reviewed. 1) Clearly developers have a need to be able to override the default time of the notification. That needs to be considered, especially if you want to encourage development on the platform. 2) If you're not going to allow it to be ovverrideable, then remove the option from the documentation! Save some of the confusion. 3) My preference would be making it overrideable. There's a system default, which Ubuntu can follow, but 3rd party apps have the ability to override (based on some of the use cases mentioned). If you feel this is inconsistent, that's ok... **You don't have to install the 3rd party apps!** The user can make that choice, why not let them, rather than trying to force it on them. If I for example wrote an app, and set the timeout to 10minutes, I'm sure users would get annoyed, and uninstall my app. It reminds of the sort of awful decisions the UK goverment make, umbrella laws/rules that apply to everything but don't work in terms of interests to the customers, ie the public. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
It's not about providing the use case, it's more about providing third party application ON TOP of Ubuntu. Ubuntu comes standard with 5 seconds time-out for notify-osd. That's fine. We are not complaining what Ubuntu does with its standard base. What we want is the ability to have our application be able to adjust the timeout value. So instead of distributing our application with a NEW notify-osd, we can leverage notify-osd that comes with Ubuntu standard base. When writing core, it should provide developers flexibility to override methods. With this inflexibility, writing third party application for Ubuntu will be a chore. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
you are asking for flexibility for random application to block other notifications for the time they want or to make the system look inconsistent which is not likely what you want, if you were explaining your motivation to change the timeout to a non standard values you could have a better chance to convince to notify-psd writters about the need there -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
As I said quite a long time ago inconsistent has no meaning here right now. Consistent with what? The aspect? Colours? The time you decide is right for everybody? The time you decide is fine for every message you don't even know about? And YES, your inconsistency IS what WE ALL want here, even though you keep on insisting that you know better than us what we want or what it's better for us. It's a shame, I think there's nothing more to say. In any other different company such blindness would not be considered acceptable for the company's sake. BTW, I forgot to reply about this: Marco, it's not true that we know nothing about the message semantic. That's funny, priority and semantic are a totally different concepts, you should buy a dictionary. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
How about leaving hardcoded limit for MAXIMUM timeout only? So that other notifications wouldn't get blocked. Developers (or users of notify-send) would be able to set the timeout from 1 ms to let's say 5 secs. I guess it would solve 99% of problems mentioned here, wouldn't it? -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Guys, you just don't seem to get that notify-osd is about unification and consistency amongst applications using it. It's fundamental design point is to NOT allow applications to use it in different ways, and also not to let the user configure it extensively. In this light, what you request as a feature, could actually be regarded as a bug if it was implemented. As a user, you are free to use an alternative implementation of the D-Bus spec that suits your needs better. As a programmer, you have to deal with the behaviour of possible implementations on your target platform. You just cannot rely on specific timeouts, or specific behaviour. In fact, you can't even rely on your notification being visible at all. The notification daemon could just as well not display anything, but write the message to a log file (which obviously never times out). If that's a problem to your usecase, you probably shouldn't be using the notification infrastructure for it in the first place. That would be a design-bug in your own code, then. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Guys, you just don't seem to get that notify-osd is about unification and consistency amongst applications using it. Totally wrong, we want to use it exactly for this reason: it's a common (and nice) interface for showing messages from different applications. But I can't see how this idea and goal should be (considered) accomplished with fixed timeouts. It's fundamental design point is to NOT allow applications to use it in different ways, and also not to let the user configure it extensively. Right, message priority and timings, not much freedom from the sender standpoint. About the user: for example, he might just choose whether he prefer to consider the timeout field from the applications or a fixed timeout for every message (it is reasonable to have this as default behaviour). I would not call it extensive configurability. In this light, what you request as a feature, could actually be regarded as a bug if it was implemented. At the very beginning someone thought notify-send was ignoring the timeout setting. Then it turned out to be a notify-osd issue. But it is not possible to request it as a feature either, so what are you talking about? As a user, you are free to use an alternative implementation of the D-Bus spec that suits your needs better. We already discussed about Desktop Notification Specification. As a programmer, you have to deal with the behaviour of possible implementations on your target platform. You just cannot rely on specific timeouts, or specific behaviour. It doesn't mean you cannot use the timeout field whenever possible, it is there for a reason, and it is reasonable to consider it too, when makes sense. If that's a problem to your usecase, you probably shouldn't be using the notification infrastructure for it in the first place. Oh really? That's strange, because it fits perfectly my needs (even though I hate the timeout constrain). BTW, I'm not a luser, I'm a computer engineer (and developer as well), so I think I'm able to evaluate that by myself, thanks. That would be a design-bug in your own code, then. Oh well, finally we discovered the problem: the others. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Totally wrong No, it's not. Denying reality may be fun, but it's not helpful. I was not talking about what you'd like, but about what notify-osd is aiming at. It is part of project Ayatana, and here's a statement about configurability in that project: http://www.mail-archive.com/ayat...@lists.launchpad.net/msg00747.html Oh really? That's strange, because it fits perfectly my needs Obviously, it doesn't, because otherwise, there wouldn't be any need to complain. BTW, I'm not a luser, I'm a computer engineer (and developer as well), I didn't say anything about lusers. And I don't really care for your engineering background, but thanks for telling me. It's got nothing to do with the discussion at hand, though. so I think I'm able to evaluate that by myself, thanks. So just go ahead, and evaluate if notify-osd fits your needs. Because in fact, it doesn't seem like you did that yet. You're evaluating how notify-osd should change it's design to fit your needs. That's not the same thing. Oh well, finally we discovered the problem: the others Yes, if you rely on notification daemon specialities, you're doing something wrong. For comparison: Here's what the KDE notification daemon developer (completely unrelated to notify-osd) has to say about how and where Galago notifications may end up in KDE: http://markmail.org/message/hxvahasqoemkuhp5#query:+page:1+mid:ij55nyqffhbf3gvs+state:results http://markmail.org/message/hxvahasqoemkuhp5#query:+page:1+mid:hgigaz6777qubzet+state:results How does a developer know how his notification is going to look or behave? If it's not in-house code, he can't. Thus, he can't rely on presentation, or, in other words, if he needs to rely on presentation, it's not the right infrastructure to use. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
The current system does support appending or replacing, see what the default im client or music player do in lucid Yes, but those abilities are not possible with notify-send. Hence, these bugs: https://bugs.launchpad.net/ubuntu/+source/libnotify/+bug/257135 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559544 You should maybe come with concrete example of things that the current design is limiting which would benefit users I have three audio devices, and I have a script to cycle the current sink to use the next device. Currently, with the broken notify-send, if I hit a hotkey to cycle to the next device I am unable to see which current device is active unless I pause for 5 seconds each time I want to switch devices. This makes notify-send totally useless. It seems as if the Ubuntu UI developers have a deep seated inability to contemplate the possibility that other people have useful and productive things to say. What a nice way to treat people who are basically volunteering their labor to help make Ubuntu better. ** Bug watch added: Debian Bug tracker #559544 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=559544 -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Yes, but those abilities are not possible with notify-send. so there is an another way to fix your issue there which is to improve notify-send or have a notify-osd-send handling those to see which current device is active unless I pause for 5 seconds each time I want to switch devices. This makes notify-send totally useless. that's a fair point but notify-osd doesn't force you to wait, see what happens when changing tracks with a music player on lucid, the limitation there is not with what notify-osd let you do but rather with the notify-send command It seems as if the Ubuntu UI developers have a deep seated inability to contemplate the possibility that other people have useful and productive things to say. What does that mean exactly? This comment doesn't seem especially constructive in reply to a question which aims at understanding your needs to try to solve the issue... Why can't we have something looking nice and behaving in a consitant way there which still working correctly? You failed so far at showing the need of notify-osd changes there ** Changed in: notify-osd (Ubuntu) Assignee: Mirco Müller (macslow) = (unassigned) -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
@Sebastien: You should maybe come with concrete example of things that the current design is limiting which would benefit users This thread is full of examples! That you consider them irrelevant, that's a different story, but all these people that have written on this thread have a valid (for them) use case where the timeout parameter is important. Otherwise they wouldn't have bothered. Plus, you do realise there may be hundreds or maybe thousands of other people that just saw the thread and the arrogant position the developers are taking and just decided to forget about it, in order to not waste time writing stuff here in vain. As somebody else was saying, if notify-send supported merging and replacing we could have worked without the timeout parameter; but since it doesn't, it's essential. But why would you want to improve notify-send by writing all the code required to add these features (replacing and merging) when the timeout patch already exists and it works? (Aside from the fact that I still don't understand why the timeout parameter _has to be disregarded_ anyway - I mean, we could have timeouts and replacing and merging.) @enb: Is there some higher up who actually cares about the users that we can contact for an explanation of this instead of shouting upon deaf ears? That's a very good point; I thought about this as well. Maybe there's a hierarchy of people that we can use to address this dispute. -- Support Wikipedia: http://wikimediafoundation.org/wiki/Donate/en http://volunteer.wikimedia.org/ -- DRM 'manages access' in the same way that jail 'manages freedom'. On Fri, Mar 19, 2010 at 11:29 AM, Sebastien Bacher seb...@ubuntu.comwrote: Yes, but those abilities are not possible with notify-send. so there is an another way to fix your issue there which is to improve notify-send or have a notify-osd-send handling those to see which current device is active unless I pause for 5 seconds each time I want to switch devices. This makes notify-send totally useless. that's a fair point but notify-osd doesn't force you to wait, see what happens when changing tracks with a music player on lucid, the limitation there is not with what notify-osd let you do but rather with the notify-send command It seems as if the Ubuntu UI developers have a deep seated inability to contemplate the possibility that other people have useful and productive things to say. What does that mean exactly? This comment doesn't seem especially constructive in reply to a question which aims at understanding your needs to try to solve the issue... Why can't we have something looking nice and behaving in a consitant way there which still working correctly? You failed so far at showing the need of notify-osd changes there ** Changed in: notify-osd (Ubuntu) Assignee: Mirco Müller (macslow) = (unassigned) -- notify-send ignores the expire timeout parameter https://bugs.launchpad.net/bugs/390508 You received this bug notification because you are a direct subscriber of the bug. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Let's calm down, people. This is a bug report, not a place to vent your disappointment with ubuntu. There are two things at issue here, variable delays, and lack of merging for notifications sent by notify-send. It is clear that the ubuntu people in general do not wish to address the second issue, on the grounds that that would cause disparity between applications. I feel that forcing the whole ecosystem to use a fixed set of parameters by simply ignoring their requests is a bad idea: this should be patched for each application individually. However, this position is understandable, although a finer grain would be nice, instead of simply having normal and urgent. The second one is clearly a bug (or rather, a design flaw that should be addressed as a bug). This has been reported a few times ( https://bugs.launchpad.net/ubuntu/+source/notify-osd/+bug/434913 and the bugs cited by elijah). I believe this would be very simple to fix: as far as I remember, libnotify only merges if three things match : - the notification ID, which is _not_ kept by notify-send between invocations - title of notification - sender app The point is that the first one prevents replacing with notify-send. I think the last two criteria should be more than enough to filter false positive, so that the criteria for notification ID could be removed with no side effects, allowing notifications to be merged with notify-send. In the meantime, I use gnome-osd, which is quite nice, less buggy, and with more features (albeit less pretty), than libnotify. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Seems some people feel strongly about the subject, nobody is being arrogant there but you are discussing at the wrong place since designers will not follow every bug reports which are usually about technical issues or bugs in the code writte. You should raised the topic on the ayatana list for discussion. Well, a brainstorm report was created for discussion and voting on what to do, but that was locked out... -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
examples! That you consider them irrelevant, that's a different story, nobody said example are irrelevant but could you give some specific ones focussing on the user experience rather than on the way to use? notify-send supported merging and replacing we could have worked without the timeout parameter; ok, so you seem to agree that adding timeout to notify-osd is not the only way, notify-send could also be improved to achieve the same goal -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
reading again this bug and the request, it seems that timeout is perceived as needed to: - not have a bubble delay other ones with updated content - let something stay on screen until the user read it the first case should not be an issue if you can append or replace the bubbles right? the second case seems to be a situation where you could as well display a standard dialog since you want the dialog to stay on screen until user act on it -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
There's also a use case for screenshot applications, like Salasaga, where the notification telling the user a screenshot is about to occur MUST be removed before the screenshot is taken. Otherwise, all the screenshots have the warning notification itself in them, as happened when notify-osd became the default. Which is why notify-osd not adhering to something that works fine with the previous (proper, working) implementation is really not scoring points. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
@Sebastian Bacher: Note that the fact that you want to be able to use random timeout in softwares would lead the system to behave in an inconsistant way tiiming wisz So draw up a set of HIG guidelines and kindly ask developers to apply them WHEN they make sense. There's no such thing as an interface that's 100% perfect for everybody and everything all the time. Nothing is solved by hardcoding such limitations. People who want to bypass the limitations will still do so, while legitimate use cases will not be catered to. and wouldn't work with the notify-osd slots design (ie notifications don't get stacked but use the same location). I fail to see how a shorter timeout would affect stacking. Or why shorter timeouts mean we must eliminate stacking, if that's what seems to be implied above. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
On 03/18/2010 10:15 AM, Sebastien Bacher wrote: you are free to install notification-daemon which is the one which was used before or to build your own version of notify-osd if you want to change this one. No, you can't. This only works if you are writing software that you don't want to distribute to anyone else. If you want to share with other people, they must also have a functional (i.e. patched) notify-osd. I think the arrogance of the Ubuntu developers on this thread is really shocking. There are apps bundled with Ubuntu that don't follow the silly 5 second rule, like the volume control. The real problem is that notify-send is very limited in functionality. Either it should support merging, replacement, and stacking, or notify-osd should support the timeout option. This is just common sense. The problem with UI experts is that they like to pretend what they do is a science, when really it is subjective art. Unfortunately, the Ubuntu UI developers have decided that they know better than everyone else. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Ubuntu: We choose what our users want so they don't have to! and: It's not a bug, it's a feature! http://brainstorm.ubuntu.com/idea/24001 Yag, stuff like this was why I dumped microsoft. While I am still free to use a patch, it is still extremely bothersome to have to fight against the developers, not because it's some bug, but because they crippled something on purpose. Is there some higher up who actually cares about the users that we can contact for an explanation of this instead of shouting upon deaf ears? -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Seems some people feel strongly about the subject, nobody is being arrogant there but you are discussing at the wrong place since designers will not follow every bug reports which are usually about technical issues or bugs in the code writte. You should raised the topic on the ayatana list for discussion. Note that the fact that you want to be able to use random timeout in softwares would lead the system to behave in an inconsistant way tiiming wisz and wouldn't work with the notify-osd slots design (ie notifications don't get stacked but use the same location). Either it should support merging, replacement, and stacking, or notify-osd should support the timeout option. This is just common sense. The current system does support appending or replacing, see what the default im client or music player do in lucid. If you want to display a note for ever on screen why don't you just open a dialog to display it? You should maybe come with concrete example of things that the current design is limiting which would benefit users (displaying some bubbles for 6 seconds and some others for 8 seconds because software writters don't agree between themself would not benefit users) and raise the topic on the ayatana list for discussion -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
** Changed in: notify-osd (Ubuntu) Status: Won't Fix = Confirmed -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
The developers of notify-osd have spoken clearly in the bug report. They are not interested in providing this feature. http://brainstorm.ubuntu.com/idea/24001/ So, stop dreaming and let Ubuntu go the MS and Apple way. Do you want freedom? Fork and make your own Ubuntu derivative. Otherwise shut up and use whatever they feel is best for you. -- Support Wikipedia: http://wikimediafoundation.org/wiki/Donate/en http://volunteer.wikimedia.org/ -- DRM 'manages access' in the same way that jail 'manages freedom'. On Thu, Mar 18, 2010 at 10:10 AM, elijah eli...@riseup.net wrote: ** Changed in: notify-osd (Ubuntu) Status: Won't Fix = Confirmed -- notify-send ignores the expire timeout parameter https://bugs.launchpad.net/bugs/390508 You received this bug notification because you are a direct subscriber of the bug. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Wow. They really have. They've marked the idea in the brainstorms site as not being acceptable, so we can't even use the standard mechanisms to actually measure demand. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Can't believe they'd ignore the community so much. Very poor process not to ignore what users are clearly requesting, as a) it'll anger them, and b) they'll go elsewhere eventually when someone offers what they want. In all honesty, I actually use Linux Mint now (have done for a while). May be worth asking there if the patch could be applied, and point them to this thread. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
[Bug 390508] Re: notify-send ignores the expire timeout parameter
Sad! Ubuntu seems to be going the MS way. I hope they realize this before its late. -- 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 is subscribed to Ubuntu. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
