Provide a configurable DND mode rather than suppressing all async notifications in fullscreen apps

Is the DND mode still in process of being implemented for karmic
 or is this new behavior here to stay?

Please do reverse this. It is annoying and causes a lot of problems for users as we miss important IM messages and we have no idea when i missed it until after i have say finished a movie.

In ayatana Ml we were discussing this and DND mdoe solution was the best, though now the discussion regarding this is not happening.

So someone from the developer team of notify-osd please tell us what is the status?

Please comment wrt status of this issue. Please re-assign/un-assign as appropriate.

Launchpad Bug Tracker wrote:
> Just noticed that the recent notify-osd behavior ,in Karmic, suppresses
> all the async notifications during full screen apps!
>
> This is a bit frustrating , because now
> - I'm not notified about loss of network connectivity!
> - when IM messages are received the lack of notifications forces me to escape from full-screen mode and check with the IM client as to who sent the IM . Previously it was easier to know who had sent it and i could choose if i wanted to reply immediately or not.
> - I'm not notified about new mail arrivals.
>
> I believe there was a lengthy discussion in the Ayatana Mailing list and the decision was to :
> - Use a DND mode in the FUSA/indicator-session
> - Not show notifications only when the user has selected the DND mode.
>

Mirco, did we ever run notify-osd in a mode where it displayed
notification urgency (critical, normal, low)? I wonder if we shouldn't
take the view that full-screen apps block non-critical async
notifications, and that some system-wide async notifications like
network loss would be classed as critical.

Mark

Hi Mark ,
The issues with screen flicker when running apps in fullscreen has been solved in compiz.
So , Why do any of the bubbles have to be suppressed?
Why is an IM not important?

The other day , i was watching a movie and the sound of an IM ping got drowned in the movie's noise , and didnt notice the IM until the movie was over! And by then the person who had sent the IM was offline.

Why cant the status be obtained from the indicator session... So, when user sets themselves as busy and is in fullscreen mode , then suppress the IM bubbles...

For me, if a person sends me an IM , IM *is* more important than the movie and i do want to be notified immediately.

mac_v wrote:
> Hi Mark ,
> The issues with screen flicker when running apps in fullscreen has been solved in compiz.
> So , Why do any of the bubbles have to be suppressed?
> Why is an IM not important?
>
> The other day , i was watching a movie and the sound of an IM ping got
> drowned in the movie's noise , and didnt notice the IM until the movie
> was over! And by then the person who had sent the IM was offline.
>
> Why cant the status be obtained from the indicator session... So, when
> user sets themselves as busy and is in fullscreen mode , then suppress
> the IM bubbles...
>
> For me, if a person sends me an IM , IM *is* more important than the
> movie and i do want to be notified immediately.
>

The issue is presentations - it's potentially embarrassing to have
non-system messages up on a big screen.

On Fri, 2009-10-02 at 18:22 +0000, Mark Shuttleworth wrote:

> The issue is presentations - it's potentially embarrassing to have
> non-system messages up on a big screen.
>

Yes , for those the user can be allowed to set the status from the
indicator session.
But , not every one is going to be doing presentation!

As i commented earlier... I missed an IM during a movie!

Could this behavior of suppressing the IM bubbles be excluded when
playing movies/videos?

Am Freitag, den 02.10.2009, 17:00 +0000 schrieb Mark Shuttleworth:

> Mirco, did we ever run notify-osd in a mode where it displayed
> notification urgency (critical, normal, low)? I wonder if we shouldn't
> take the view that full-screen apps block non-critical async
> notifications, and that some system-wide async notifications like
> network loss would be classed as critical.

 This very capability is implemented in notify-osd coming with Karmic.
During "fullscreen apps" (in other words when in "screensaver
inhibited"-mode, e.g. by running totem or OO-Impress in
presentation-mode) only synchronous and critical asynchronous
notifications are displayed. Asynchronous notifications with low- and
normal urgency are suppressed in this "screensaver inhibited"-mode.

 If you want to test that yourself, there are three asynchronous
notification examples (with low, normal and critical urgency) in
notify-osd's source tree. To get and try them do:

        bzr branch lp:notify-osd
        cd notify-osd/examples
        ./low-urgency.py
        ./normal-urgency.py
        ./urgent-urgency.py

 To make notify-osd display a notifications urgency within each bubble
do:

        killall -15 notify-osd
        DEBUG=1 /usr/lib/notify-osd/notify-osd

Best regards ...

Mirco

Just as a sidenote... e.g. the "Wifi connection lost" bubble (triggered by NetworkManager) has a correctly set urgency-level of critical, thus it gets shown when OO-Impress is displaying in presentation-mode.

Mirco Müller wrote:
> DEBUG=1 /usr/lib/notify-osd/notify-osd
>
Didn't we agree to run it in this mode during the Karmic dev cycle? So
that we could be sure notifications weren't being sent with spuriously
high urgency?

I think it's too late to do it now, we are post-beta. Did we do any
formal review of all the apps that send notifications, and the urgency
they set?

Mark

Mark , Mirco ,
Is there a way to make notify-osd detect whether any OOo app is running in fullscreen or if a movie is playing in fullscreen?

If the issue is about presentations.. suppressing the bubbles during an OOo might be better... now it suppressed the bubbles even when using picture slideshows!

For now , a workaround i do while watching movies , is to *not* use fullscreen. But rather use a Maximized window!
This is *very* frustrating , not being able to even watch a movie peacefully!

Though i agree that a personal message during a presentation would be embarrassing...
What would be the chances of that happening compared to a person missing an IM notification while watching a movie!
[most folks dont turn on the im clients during presentations , this embarrassment problem would be more when a person is using a laptop and has im client running
While this 'fix' this would affect both desktop and laptop users and most definitely a larger user base ]

If time is of the essence and this could not make it into Karmic , why do the fixes have to be done in such a manner? Isnt it better to fix the issues properly , rather than doing it incompletely...!

Mirco,
Could you kindly point to where in the code this change was applied? I'd like to revert this behavior and rebuild the package.

I think mac_v makes correct points.
This bug should be given high priority and resolved ASAP Imho else it will
become a really big annoyance of karmic.

I really dont understand why it was decided to go for this behaviour in the
first place. In ayatana ml this topic was discussed in detail and the
decision reached was

*Show notifications by default in fullscreen apps
*Have a DND mode where notifications are not sent.

If all this could not have been done for karmic, then the issue should not
have been touched at all.

In conclusion, missing IM's,emails,etc while watching movies, etc is a use
case which is more concerning and something which is likely to happen more
often to more no. of users. rather than the pretty limited use case of
someone giving a presentation while having IM enabled.
On Sat, Oct 3, 2009 at 5:27 PM, mac_v <email address hidden> wrote:

> Mark , Mirco ,
> Is there a way to make notify-osd detect whether any OOo app is running in
> fullscreen or if a movie is playing in fullscreen?
>
> If the issue is about presentations.. suppressing the bubbles during an
> OOo might be better... now it suppressed the bubbles even when using
> picture slideshows!
>
> For now , a workaround i do while watching movies , is to *not* use
> fullscreen. But rather use a Maximized window!
> This is *very* frustrating , not being able to even watch a movie
> peacefully!
>
> Though i agree that a personal message during a presentation would be
> embarrassing...
> What would be the chances of that happening compared to a person missing an
> IM notification while watching a movie!
> [most folks dont turn on the im clients during presentations , this
> embarrassment problem would be more when a person is using a laptop and has
> im client running
> While this 'fix' this would affect both desktop and laptop users and most
> definitely a larger user base ]
>
> If time is of the essence and this could not make it into Karmic , why
> do the fixes have to be done in such a manner? Isnt it better to fix the
> issues properly , rather than doing it incompletely...!
>
> Mirco,
> Could you kindly point to where in the code this change was applied? I'd
> like to revert this behavior and rebuild the package.
>
> --
> Do not suppress async notifications when using fullscreen apps
> https://bugs.launchpad.net/bugs/428509
> You received this bug notification because you are a direct subscriber
> of the bug.
>

I could see the rationale in the choices made by the UX team regarding the notify-osd bubbles design , even though there was an outcry from the community.
They[color/position/size/location] were more of personal preferences , it seemed reasonable when the devs didnt want to offer configuration for these and rather wanted to get the default settings right and keep them hardcoded

The choice made here seems to have been more from a personal experience rather than from a design view!
The view that all systems running Ubuntu will be used for presentations is not a correct assumption.

Folks use systems for personal use too and such users might never even do a presentation in their entire life.
Certainly these users would not encounter the situation where an embarrassing personal IM is displayed during a presentation.

The really sad part of this feature is: Unless someone has followed the progress of notify-osd ... the average user might *never* know that this is being done! They would just think that they have missed the IM bubble during the movie. They wont even know what is wrong or where things are wrong!
[well this may make the notify-osd devs happy ;p since they might get less bugs/complaints regarding this feature... users might just blame the IM app is not sending the notification]

But i dont understand the rationale behind the *way* this new feature is being implemented! if it is not possible to effectively distinguish whether the user is viewing a presentation or watching a movie or just viewing a pictures slideshow. Or if there is not enough time to get a DND mode in the indicator-session.
- why not offer a gconf ? there is a gconf for the gravity

I implore that the devs reconsider offering a gconf to turning off this feature , until they fulfill the TODO , they have set for themselves in the src/dnd.c >>> /* TODO: ask FUSA if we're in DND mode */

mac_v wrote:
> The choice made here seems to have been more from a personal experience rather than from a design view!
>
mac_v - the same could be said of your constant repetition of the fact
that you missed an IM during a movie. When you quit the movie, the MI
told you it was there. It's not that big a problem, please stop
overplaying the scenario. We may get a DND mode in the next round, we
don't have one now. Please accept that and engage constructively on
other matters.

On Mon, 2009-10-12 at 08:44 +0000, Mark Shuttleworth wrote:
> mac_v - the same could be said of your constant repetition of the fact
> that you missed an IM during a movie. When you quit the movie, the MI
> told you it was there.

Yes , MI will show *only* when we quit the movie. that is what I'm
trying to say.

By then the message is too late , it is no longer an *Instant* message.

As I'v said already , the contacts might not even be online by the time
the movie is over... [and this has happened to me several times until i
realized where the bug was]

> It's not that big a problem, please stop overplaying the scenario.

Kindly do not minuscule another's personal experience.

I'v not said that a personal IM during a presentation is not embracing
or is an overplayed scenario. Every experience is important to the user
affected.

If you could take a few minutes and read back on the Ayatana mailing
list , several other scenarios were also sighted:
of them a quite common one > User's using firefox in fullscreen mode
especially in netbooks.

But , I do believe that the odds for the presentation scenario happening
are not greater... [already mentioned this in the above comments ]

> We may get a DND mode in the next round, we
> don't have one now. Please accept that and engage constructively on
> other matters.
>
I'v accepted this ... and I'm not insisting on a DND asap.

But did suggest an alternative , [I thought I was being constructive ,
maybe not ], that there be allowed a gconf for turning off this
feature.

Let the bubbles be suppressed by default but allow the user to revert
this via a gconf.
Which *might* not be as tough as implementing a DND... This could be a
temporary band-aid for users , till we have a DND mode.

While it is too late to do anything about this in the Karmic cycle, I must
protest the way this issue was handled. First, this issue was discussed in
Ayatana in detail. And a sensible conclusion that everyone seemed to come to
after discussing all possible cases was DND mode + not hiding notifications
in fullscreen apps by default.
But yet, it seems the developers didn't heed this advice and then turned off
notifications without giving user with a DND mode.

On Mon, Oct 12, 2009 at 3:39 PM, mac_v <email address hidden> wrote:

> On Mon, 2009-10-12 at 08:44 +0000, Mark Shuttleworth wrote:
> > mac_v - the same could be said of your constant repetition of the fact
> > that you missed an IM during a movie. When you quit the movie, the MI
> > told you it was there.
>
> Yes , MI will show *only* when we quit the movie. that is what I'm
> trying to say.
>
> By then the message is too late , it is no longer an *Instant* message.
>
> As I'v said already , the contacts might not even be online by the time
> the movie is over... [and this has happened to me several times until i
> realized where the bug was]
>
> > It's not that big a problem, please stop overplaying the scenario.
>
> Kindly do not minuscule another's personal experience.
>

Various people have discussed various usecases on the Ayatana mailing list.
And no particular use case must be given extra preference. having said that,
the presentation use case is actually something that a minority of the
people are going to experience. various people use apps like pdf readers,
movies, browsers in fullscreen especially with the advent of small screen
netbooks.

>
> I'v not said that a personal IM during a presentation is not embracing
> or is an overplayed scenario. Every experience is important to the user
> affected.
>
> If you could take a few minutes and read back on the Ayatana mailing
> list , several other scenarios were also sighted:
> of them a quite common one > User's using firefox in fullscreen mode
> especially in netbooks.
>
> But , I do believe that the odds for the presentation scenario happening
> are not greater... [already mentioned this in the above comments ]
>
> > We may get a DND mode in the next round, we
> > don't have one now. Please accept that and engage constructively on
> > other matters.
> >
> I'v accepted this ... and I'm not insisting on a DND asap.
>
> But did suggest an alternative , [I thought I was being constructive ,
> maybe not ], that there be allowed a gconf for turning off this
> feature.
>
> Let the bubbles be suppressed by default but allow the user to revert
> this via a gconf.
> Which *might* not be as tough as implementing a DND... This could be a
> temporary band-aid for users , till we have a DND mode.
>
>
So, all I would say is that the way this issue was handled was definitely
not right. and in future if something is so actively discussed, like this
was in Ayatana list or anywhere else, then it might be best to use that
advice or give a sane rationale not to. And definitely not implement it half
baked.

> --
> Do not suppress async notifications when using fullscreen apps
> https://bugs.launchpad.net/bugs/428509
> You received this bug notification...

tgpraveen wrote:
> So, all I would say is that the way this issue was handled was definitely
> not right. and in future if something is so actively discussed, like this
> was in Ayatana list or anywhere else, then it might be best to use that
> advice or give a sane rationale not to. And definitely not implement it half
> baked.
>
The code is open source, and patches are welcome. Please don't describe
as half-baked development which goes in increments!

Mark

Adding upstream task as the DND , is part of the Lucid specs : https://wiki.ubuntu.com/NotifyOSD#Work%20for%20Lucid

Set to high to reflect its being in the lucid specs.

I just got a netbook and have been using Firefox in fullscreen mode for real-estate without realizing I have missed many of my colleagues' messages to their ire. Will this behavior be reversed in Karmic at all? Or will I have to compile my own notify-osd to resolve this while waiting for Lucid?

Why can't there be at least an option for something like this which obviously will not be universally accepted decision based on the lengthy discussion on Ayatana? Oh who am I, I'm using Ubuntu for free :D

This was pretty frustrating. I was using Virualbox on fullscreen when I missed quite a few notify-osd messages as they were not shown because of this. I see that there has already been discussion about fixing this, so I hope it is fixed before 10.04.1. I honestly though this was a bug and still do. If there is not major changes, at least add a config option to allow notify bubbles on fullscreen applications. This needs to be fixed as this bug already looks pretty old, especially to be in the Lucid final release.

i believe we can safely agree, that IMs are the topmost Use Case impeded by this bug's problem.
The discussion is back on over @ Ayatana ML.

I googled hard for the Ayatana ML thread from 2009, couldn't find it.
Vish, perhaps you still have it bookmarked!? anybody?

no problem, we had at least one other thread on the topic, same use cases, same consensus.

i also see that multi-monitor setups were being considered previously..
this doesn't make sense to me at all, the first Use Case is the "AnyUser", not the special extra setup.

please discuss this over @ Ayatana, it's been on the todo for FUSA, before MeMenu was even drafted.
Perhaps someone can also talk sense into the code, to make it behave reasonably, as we have all finally reached consensus.

Another situation in which turning do-not-disturb mode caused of fullscreen application is not appropriate:

I have two monitors at work and three virtual desktops, six spaces total. Normally notification bubble is shown at the left monitor. However, I have VirtualBox in fullscreen mode on the right monitor at the leftmost desktop.

And although notifications bubble isn't overlapped by this fullscreen window, notifications are disabled! Even worse, notifications are still disabled when I switch to another virtual desktop which have no fullscreen applications at all.

@frederik.nnaji: the discussion in ayatana , I believe started here:
https://lists.launchpad.net/ayatana/msg00181.html
It was discussed a lot , there were several sub threads too!

But again , I dont see this bug being fixed or any changes happening for this any time soon. Just learned to shut up , put up with it and use a workaround :-)
Unless you can hack on notify-osd and submit a merge. ;-)

Are there any designs for how do-not-disturb would be implemented?

Presently I see the suggestion that when the current presence is busy that the messages should be suppressed when using a full screen application, and the suggestion that multi-monitor mode be respected.

Multi-monitor mode is a no-brainer, it certainly should display a notification on the screen which doesn't have a full-screen application running.

Suppressing messages when busy is selected is a definite no-no, it isn't obviously connected to the appearance of notifications and may be overlooked.

What would make sense in my view is something like an addition to the indicator-session-applet with a do-not-disturb button, it would also make sense to add a inhibit-sleep button adjacent if such an indicator were to be created. Each of these buttons could be enabled/disabled at the users will, as a toggle button and shown/hidden in an appropriate preferences dialog. Similar implementations exist for the MacOSX panel including caffeine and growl.

Other points to note in implementing an elegant solution;

1, Critical messages e.g. your hard drive has caught fire should always be displayed, which I believe is what Mirco and Mark were previously discussing here.

2, Do-not-disturb is defined as, "I do not want to be interrupted by real-time communication, email or calendar alarms, or anything which doesn't require my immediate attention considering I've just specified I don't want to be disturbed", in this sense, do-not-disturb also prevents alarms going off while you're in meetings and similar distracting events occurring.

Personally, I am the kind of person who would like to stop notifications when he's concentrating on a something, as such email and im clients get closed. The preferred use case for me would be to inhibit any and all notifications which weren't "life-threatening". Then I wouldn't incur the time cost of starting my email and im clients up again.

3, With this feature a full screen application has no effect on notifications except in that the notifications will try and avoid a screen which contains a full screen window. Avoidance of full screen windows when multiple monitors are present should also over-ride the specified behaviour of the notifications should appear on the screen that most of the application is on as it's not as relevant in the case of full screen as is avoiding the full screen window.

4, For any do-not-disturb mode a log of events would need to be implemented, which would require de-duplication/combination of the messages and presentation.

On Tue, 2010-07-27 at 14:05 +0000, Karl Lattimer wrote:
>
> 4, For any do-not-disturb mode a log of events would need to be
> implemented, which would require de-duplication/combination of the
> messages and presentation.

For this we could use the specs MPT has done for notify-osd and the
screensaver "leave message" problem:
<https://wiki.ubuntu.com/NotifyOSD?action=diff&rev2=128&rev1=127>

There is already Bug #333269 for that,its yet to be implemented.

Its a spec for "While you were out" , but we can use the same and title
the scrolling window as "While you were busy" ;)

Notifications are also disabled if you have a fullscreen application running on another workspace.

wow.. still nobody?
I love challenges, but i know for sure that this is not one i can solve alone..

What i do know about the path to a solution here is, that we need to discuss Presence in the Indicator Menus, until we understand how Presence primarily has nothing to do with whether i'm online or not.

I dint expect this DND to be implemented any time soon and finally tried to revert this.
I was *very* surprised how simple it was to 'revert' this change!! ;p

If anyone else wants to have notifications displayed always, you can use it from ppa > https://launchpad.net/~vish/+archive/notify-osd

For Gajim IM users on Oneiric: You can change line #579 in /usr/share/gajim/src/notify.py to

hints['urgency'] = dbus.Byte(2) # High urgency due to Ubuntu bug

Then, notifications are always displayed. I do this change for three Ubuntu versions now manually after each upgrade. :-(

The workaround that I gave in comment #31 doesn't work anymore in Lubuntu 12.10. Now, notifications with "high urgency" just stick and must be closed explicitly. And at the same time, even they are invisible now if one application is fullscreen. This is developing in the wrong direction. :-(

Has a consensus been reached about the *expected* behaviour? It seems to me that fixing this is not that difficult, but nobody really knows how it is supposed to work.

The problem that's blocked me until now, in designing a solution for this, is that a Do Not Disturb mode would so often be forgotten. To be effective, you'd need to remember to turn it on every time you launched the particular app, or went into the particular app mode, and turn it off afterwards. And often you'd forget at least one of those.

But System Settings on the phone already includes a design (not yet implemented) for controlling which apps can use notification bubbles at all. As the designs for form factors converge, I guess it makes sense for the PC to have equivalent settings. Those can then tie in to Do Not Disturb mode. You could let each app use notification bubbles at any time, never, or only at times when DND mode is off.

A remaining issue will be how to categorize notification bubbles that don't come from a particular app: for example, print jobs and Wi-Fi connections.