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 <email address hidden>wrote:
> 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.
>
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 <email address hidden>wrote:
> Adrian, please report a bug on libnotify if the notify-send man page is /bugs.launchpad .net/bugs/ 390508
> 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:/
> You received this bug notification because you are a direct subscriber
> of the bug.
>