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.
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
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
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
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 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
/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
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
@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
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
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
@ 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
@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
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
"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
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.o
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 i
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
wrote:
> I forgot to mention. The patch w
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
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
pag
@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
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 dele
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
The manual page of the notify-send program specifies:
[...]
SYNOPSIS
notify-send [OPTIONS] [body]
DESCRIPTION
[...]
OPTIONS
[...]
-t, --expire-time=TIME
Specifies the timeout in milliseconds at which to expire the
notification.
[...]
If the expiration time for the n
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
26 matches
Mail list logo
