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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
Submitted as http://brainstorm.ubuntu.com/idea/24001/ However, This idea is awaiting moderator approval before going to the popular ideas area. Let's see if it doesn't get rejected by a moderator. -- Support Wikipedia: http://wikimediafoundation.org/wiki/Donate/en http://volunteer.wikimedia.org/ -- DRM 'manages access' in the same way that jail 'manages freedom'. On Sun, Mar 14, 2010 at 7:36 AM, Justin Clift jus...@salasaga.org wrote: Sounds like we need someone to write this up as an idea for http://brainstorm.ubuntu.com, so that way we can vote on it and put some actual numbers around the demand a version that supports timeouts. Who wants to write it up? -- 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
MPT: [...] Anyway, I have already suggested that you report a bug about the man page; if you do that it's more likely to get fixed than if you complain about it (even twice) in the comments of a bug report about a different package. Initially I was going to report a bug about the man page, but in the meantime I've decided not to do it, because actually the man page doesn't bother me at all. It bothers me that this bug won't be fixed, and maybe if the man page stays as it is more people will complain on this thread. It's frustrating that the man page lists the expire time parameter, but the fix for that is not to remove the parameter specification from the man page; the fix is the patch that has already been provided to you, tested by me and a couple of other people, and that you won't apply because you feel you know what's best for _everybody_. -- 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, Dec 2, 2009 at 8:44 PM, Justin Clift jus...@salasaga.org wrote: MPT: The fix for this appears to be a 12 line patch (including the blank lines) which has been submitted, and shown to work. Yet you guys are refusing to implement this (very simple) patch, which would enable apps with specific needs to continue working to full functionality. We've had to code a reduced functionality workaround that detects Notify-OSD, and makes use of a confirmation bubble approach instead in order to GET THE NOTIFCATION OFF THE SCREEN in time for the screenshot. But it makes for a lesser user experience. I'm obviously extremely unimpressed with the inflexible line you guys are taking on this. It really doesn't suit *100%* of software packages, and the code to allow the edge cases (like our app) to work is already available. Can't you guys just enable it and allow people to move on with coding more important stuff? -- 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
Tested the patch - works great here! -- 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, Nov 24, 2009 at 12:45 AM, Ankur Nayak ankur@gmail.com wrote: I forgot to mention. The patch works with version 0.9.24 of notify-osd. Please let me know if the patch works fine. Thanks, Ankur -- 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
As long as I have a executable binary (notify-send) which is accessible by the user, and the binary takes a -t (timeout) parameter, I consider that we're talking about end user freedom and not developer freedom. This wouldn't have made it all the way here if this -t option wasn't in the man page. If it was an API / method or function call parameter, then I agree - it would have been developer-land. And I'm sorry, but you can make all the excuses you want, you're not going to convince me that it's beneficial for the majority of Ubuntu users to ignore this parameter. That you want to create a framework for the notifications, that will have good defaults for everything instead of relying on application developers to set the notification durations is a worth-while endeavor, and you deserve praise for it; but the existence of reasonable defaults _does NOT_ automatically exclude the ability to override them. Aside from the minimal effort of spending the resources needed to implement this feature (which should be significantly cheaper than arguing over the merits of this thread), there is no reasonable benefit for anybody that arises from ignoring the expire time parameter. I'm working on a solution myself, because I have lost hope that somebody in the Launchpad / Ubuntu team will fix this problem. I'm very disappointed, but there's no way to force you, so I have to fix my own problem - thanks to RMS and the GPL, this should be possible. If and when this solution of mine will work, I will make it public - but so far I have no foreseeable release date. On Mon, Nov 23, 2009 at 2:19 PM, Matthew Paul Thomas m...@canonical.comwrote: wirespot, the variable durations are not implemented yet. Once they are, you'll find that Screen saver ON will display for 5 seconds rather than the current 10, which should be much less annoying. Adrian Roman, this has little if anything to do with users' freedom to alter the environment, because the timeout parameter is for application developers, not end users. We think we can set more consistent and reliable durations for users automatically than diverse application developers ever could manually. Calculating the appropriate duration will be *more work* for us than simply heeding the timeout parameter, but we think it will be worth it. For your remote control work, which sounds very cool, I suggest you either (1) enhance notify-send (or find someone to do it) so that you, and anyone else, can set replaces_id, (2) use a scripting language that lets you set replaces_id instead of using a shell script, or (3) if you really want a challenge, work out how to integrate the remote control volume changes into gnome-settings-daemon so that it generates the standard volume bubbles instead of notification bubbles. Marco Chiappero, it is true that expire_timeout is not part of the Hints table and therefore not explicitly optional, though I could get all RFC-2119 about it and point out that the definition of expire_timeout uses the word should rather than must. We are fortunate that the Desktop Notifications Specification was flexible enough to allow what we wanted for notifications in Ubuntu, so we didn't need to fork it. movaxes, showing synchronous things like which workspace you've just switched to would be a misuse of notifications, which are for asynchronous things. But provided you follow the software license, you're welcome to adapt the Notify OSD code for your own synchronous overlays. Justin Clift, if your application is distributed in an official Ubuntu archive or a PPA, you can expect unfavorable ratings and reviews in future if installing it produces ugly notifications not just in your application but in every other application too. 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). If you are more specific about what you want, designers could help you find a more harmonious solution; I suggest mailing the Ayatana mailing list https://launchpad.net/~ayatanahttps://launchpad.net/%7Eayatana with details. ** Changed in: notify-osd (Ubuntu) Status: Triaged = Won't Fix -- 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
Ankur, please post the patch here; we'll be able to validate that it works and it will serve whoever else feels encumbered by the current state of affairs. MPT: I seriously appreciate the work involved in creating a consistent framework for notifications. It's just that you went only one step too far. Like a lot of people and I have said before, having a good set of defaults does not require you to eliminate the override option. That's really arrogant. There's no benefit to you or anybody else in doing that, and you have consistently failed to prove otherwise. -- 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, Nov 23, 2009 at 10:07 PM, Marco Chiappero ma...@absence.it wrote: I'm really really really disappointed. Sorry Mattew, but what the hell are you saying? We think we can set more consistent and reliable durations for users automatically than diverse application developers ever could manually.. You're not supposed to do that, you should not do that, you don't even knot how to do that because you know nothing about the message semantic. You are telling us that you our own decision is much better than mine or the application one which knows the messages content? You know better than me in deciding what I want and what I need? Really? That's ridiculous... These are really good reasons, while still waiting for reasoning from you (I'm ignoring the nonsense above, consistent means absolutely nothing here) about this bug (yes, it's a regression). Honestly, who cares about what you think it's best, people do care about properly working and useful software. People want good defaults, not stupid behaviours. That's indeed your job, not preventing people from doing fine their own job. A little though: where is the innovation in Ubuntu? Is this all the innovation Ubuntu is supposed to provide, breaking things? How brilliant... I think I will revert to debian testing, much more recent software and no blind developers. Sorry for the hateful message, but I think you really deserve 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
Re: [Bug 390508] Re: notify-send ignores the expire timeout parameter
@Matthew Paul Thomas: I completely disagree with your arguments. As a more philosophical explanation, if I wanted somebody to tell me how the software should work for me, I could go use Windows. The spirit of free software is exactly this, to enable users' freedom to alter the environment they work with for whichever need they have, regardless of how niche that need / use case may be. I agree that having access to the source code with the proper license allows users to modify and build their own packages that do exactly that, but I don't understand the reason why it benefits anybody to intentionally restrict the capabilities of software under these circumstances. It's not like it's confusing users with too many options, this is a command line tool for advanced users - so usability couldn't be a reason. It does not require massive amounts of development work, so resources couldn't be the reason. So then, why? As somebody else already pointed out, we have not yet heard any valid argument why restricting the use of the timeout property is beneficial. There's an important distinction between making things simple and making them dumb. Specifically in my case, the use case is this. I have a TV tuner with an IR remote control. I use lirc to define actions (call bash scripts) for the buttons on the remote control. I used separate buttons for volume control in tvtime and totem for a while, but I then realized it's not really efficient using 2 sets of buttons for the same function, so I switched to using a single pair of buttons for system-wide volume control. So I use amixer to increase / decrease volume, and I do so in increments of 3%. If I'm at 35% and I want to get to 50% volume, I need to press the volume up button 5 times. That effectively means I will have 5 bubbles, each 5 seconds long, each telling me that the volume has increased 3% - so for at least 20 of the 25 seconds (how long the bubbles stay on the screen) I will have old information on screen, coming from the queue of notification events. Too bad I can't either set the timeout to 1 second, or replace the older bubbles with the newer ones. Too bad both of these capabilities are referenced in the man page, but neither work - but not because it's a bug, it's a feature! -- 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, Oct 2, 2009 at 11:24 PM, enb elitenoob...@gmail.com wrote: Did I just change the status? I had no idea I could do that. I was just messing around and thought that it would reject it because I thought that only moderators or priveledged users could change bug statuses, and now it won't change back to won't fix. Whoops. :( ** Changed in: notify-osd (Ubuntu) Status: Won't Fix = New -- 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
That's just my signature below, it has nothing to do with the bug report - sorry for the confusion. I'll try to remember to delete it, starting with the next message I send. I'll open a bug on libnotify as requested, but I really would prefer it if we could just specify the timeout instead of deleting that from the man page. I use custom lirc scripts to modify the sound volume with a IR remote, and if I press the Volume up button 3 times to increase the volume, it will create 3 different notification messages, 5 seconds each - so in total, it will take 10 second to display the final volume level, and the volume level will stay on the screen for 15 seconds. It should be trivial to read the expire time from the command line and pass it on, instead of the default. In the end, I guess I'll end up spending the time to build my own expire-time-enabled package if it won't be fixed. DRM 'manages access' in the same way that jail 'manages freedom'. On Tue, Sep 22, 2009 at 6:38 PM, Matthew Paul Thomas m...@canonical.comwrote: Adrian, please report a bug on libnotify if the notify-send man page is inaccurate. I don't understand the relevance of DRM to this bug report. Smeuuh, if we offered a configuration screen for something as boring as notification bubbles, we would have done something terribly wrong in the design. It's possible we have something terribly wrong, but if we have, it's a bug that should be fixed, not configured around. enb, Notify OSD does not implement timeouts at all, so it is not disabling them, and it is not not disabling them either. In Karmic, bubbles with short messages automatically stay up for a shorter time than long messages. -- 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
This may be a little dumb, but as I look at the man page for notify-send, it specifies a -t parameter, and I don't see the reason why that parameter exists without me having the possibility to use it. Is there any way that I could use that parameter? Can I choose to use notify-send with something else than notify-osd? DRM 'manages access' in the same way that jail 'manages freedom'. On Fri, Sep 11, 2009 at 2:07 PM, Mirco Müller mirco.muel...@canonical.comwrote: Please see https://wiki.ubuntu.com/NotifyOSD#org.freedesktop.Notifications.Notify stating that if the notification-daemon is notify-osd values for expire_timeout are ignored. -- 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
The manual page of the notify-send program specifies: [...] SYNOPSIS notify-send [OPTIONS] summary [body] DESCRIPTION [...] OPTIONS [...] -t, --expire-time=TIME Specifies the timeout in milliseconds at which to expire the notification. [...] If the expiration time for the notifications must be hard-coded, why leave the -t option? DRM 'manages access' in the same way that jail 'manages freedom'. On Mon, Jun 29, 2009 at 4:50 PM, Mirco Müller mirco.muel...@canonical.comwrote: That's deliberate any by design. The timeout-policy for notifications is specified here here https://wiki.ubuntu.com/NotifyOSD#Animations%20and%20durations. ** Changed in: notify-osd (Ubuntu) Importance: Undecided = Wishlist ** Changed in: notify-osd (Ubuntu) Status: New = Won't Fix ** Changed in: notify-osd (Ubuntu) Assignee: (unassigned) = Mirco Müller (macslow) -- 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
As I understand the code, the expire_timeout variable is first initialized with a default, then the same value is used later to define an array and then to set the expiration timeout for the notification. I don't see any code that reads the notification timeout from the command line and sets the expire_timeout variable accordingly. Anyway, regardless of where the problem lies, the expiration timeout can only be the default 5 seconds - there's no way to change this value. DRM 'manages access' in the same way that jail 'manages freedom'. On Sat, Jun 27, 2009 at 6:39 AM, A. Walton awal...@ubuntu.com wrote: Notify-Send is sending the timeout to the server correctly as your grep shows, but Notify OSD does not support timeouts. ** Package changed: libnotify (Ubuntu) = notify-osd (Ubuntu) -- 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
