+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.
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
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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. :-)
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.
@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
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
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
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
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
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-
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
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.
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
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
@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,
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
@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
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
/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
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
...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:
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
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
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
@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
@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
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
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
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
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
@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
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.
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
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:
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.
--
@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
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
@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
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
@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
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
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
@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
@ 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
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
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
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
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
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
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
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
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
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
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
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:
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
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
@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
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
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
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
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
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
@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
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
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
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
** 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
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
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
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
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.
--
1 - 100 of 169 matches
Mail list logo
