+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.
T
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
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
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
Y
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 (
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 be
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 receive
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
> 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
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
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
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
"bu
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
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, wh
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 ha
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 ca
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
patc
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-update
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 Ubun
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.
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 ad
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 loca
> 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 o
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 direc
> 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
> 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 testin
"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 wri
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 writ
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 b
"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 he
> 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 jus
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
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-
i
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 a
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
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 us
> 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."
>Th
@nstenz ... while i hate to back up the Ubuntu developer side in this
issue, let me point out a flaw that has been brought up before:
"The first sentence of the design spec for notify-osd clearly says it
should implement the Desktop Notifications Specification."
Unfortunately, should != must
Ubu
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.
There's
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 recommendati
@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 ti
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 (w
@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
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:
ng what no one
else has found"
From: Kent deVillafranca
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
> ...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.co
>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 cr
/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 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 re
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 ti
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 notificatio
> 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
app
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* i
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 cons
> 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
@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 ano
@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
@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 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
compu
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
I ended up coming here because I want to enhance a python script that i
have to operate a non-standard remote (Asus AI remote, not supported in
Lirc). I want to use on screen notifications to display the status of
the remote (I plan to program two different key maps depending on what
mode I progra
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://wikimedi
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
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
@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 mand
>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 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
@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
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
@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
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 g
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
"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
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 par
@ 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
@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
> 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
> 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
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 fe
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 ign
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
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 t
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 applicati
@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 i
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
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
> 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
>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
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
@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
> 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 m
> 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/bu
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 disc
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 devel
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 dis
> Dictating other people how they should write the software they work on
> during their free time is not constructive.
That's ironic, considering that that's exactly what the Ubuntu devs are
doing to us by refusing to implement this change.
It is also not constructive to fork an entire package fo
@Omer, I didn't mean to undermine in any way Ubuntu's efforts in
delivering great software. But, it's just sad that so many people have
voiced their opinion about this bug and it has not even been considered
as an option.
--
notify-send ignores the expire timeout parameter
https://bugs.launchpad.
+1
--
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/list
@Sebastien
The issue here isn't anyone trying to tell the devs how to develop their
software. The notify-osd package intentionally ignores part of the
desktop notification spec, yet still claims to be compliant. It breaks
packages around it (ie: notify-send) and forces developers to
'Ubuntu'ize'
"Sad! Ubuntu seems to be going the MS way. I hope they realize this before its
late."
This statement is so not true. The day when ubuntu will be charged will be the
day when you can say ubuntu is going the microsoft way and thats never gonna
happen. That's a promise made by Ubuntu that it will a
1 - 100 of 169 matches
Mail list logo
