Notification apps remain in Unity launcher when they shouldn't

I think I fixed the second bug ("doesn't respond to keypress) in rev 220.

Btw I'm going to try Unity tomorrow to fix this.

One question: why Synapse shouldn't be in Unity's launcher?

Ok, I fixed the second bug in rev 234 (for Unity).

But the first bug is into Unity, so I'm going to add a bug to Unity project.

sounds like a bamf task. Thanks for reporting that :)

@Alberto: It shouldn't be in the launcher for the same reason that no other background tasks should stay there. Maybe some people would like to keep it as a launcher, but I really don't see the need for that. (The normal use case would be to run it on logon.) I guess bringing it up via keyboard shortcut could have it in the launcher as a running task, but it shouldn't be there when it's running in the background.

Yep I got it, that's why I opened the bug in Unity project :)

Seeing that this is now in Unity/BAMF: Is this bug also causing Gwibber to stay in the launcher. I have Gwibber-services running on logon. Gwibber does not however show up in launcher until I start it, either from menu or from the notification area. Having it in launcher makes sense when a Gwibber window is active, but after I X it away, it still remains in the launcher.
I'm a little anal about this, beacuse on my smallish screen, I'd like to keep the launcher as tidy as possible.

I think bzr-gtk suffers this same bug.

So to be clear, the unity side of this bug is that it doesn't respect the skip-taskbar-hint? I can look into that.

OK, I don't think it's a skip-taskbar-hint issue. (A) unity appears to have support for that already and (B) neither synapse or bzr-gtk actually have visible windows. They are both notification apps with .desktop files. Bamf sees that there is a process that a .desktop file handles and shows an icon.

I think that since there are no actual windows (just notification applets), the icon should probably not show. So bamf should be able to detect that and set user_visible accordingly.

Michael, thanks for the help.

Said so, I think that it "is" a skip-taskbar-hint issue:
I think that Unity should not show the application in the taskbar,
it doesn't matter if it has or not the indicator, or if it has the .desktop file or not!

Thanks again!

Alberto, I understand you want the icons not to show up in the launcher. But skip-taskbar-hint is only for windows, not indicators.

All indicators that have .desktop files seem to show up. So far we've seen bzr-notify (from bzr-gtk), synapse, and gwibber. The latter two use new-style indicators, the first uses an old-school notification icon (which don't show up in unity).

It's simple enough to hide all indicators. In bamf-application.c, remove the following code:

      if (BAMF_IS_INDICATOR (view))
        visible = TRUE;

However, I think it would be nice if we could continue showing notification icons in the launcher, while hiding aps that present themselves in the indicator. But that's a design decision and this is getting slightly more complicated that a bitesize bug, as I couldn't easily tell where the code was separating between old-school and new-school indicators. So I'm leaving this one alone for now until a unity developer chimes in.

Oh, I'm a fool. bzr-notify doesn't use old-school indicators. It has a new-style one but just hides it by default. OK, so I'll propose a patch that just makes indicators not show up.

Michael: The lastest Synapse has an option to hide the indicator.
The problem is that in Unity there are 2 indicators: one in the top panel, and one in the left taskbar.
I'd like a way to show only the panel one.

Gentlemen.

I regret not getting to this bug report sooner (why is it originally under synapse?). Anyhow! Let's not get ahead of ourselves here, the solution is no tthat we need to cut off all indicators from BAMF as mterry has done (this kills the tomboy experience for one). The solution is to ensure that programs are properly marking the AppIndicatorCategory for their indicators. BAMF will only expose indicators which are of type APP_INDICATOR_CATEGORY_APPLICATION_STATUS. This is what should be used for applications such as Rhythbox, Banshee, Tomboy (basically anything that may throw up a sustained window or "minimize" to its indicator). Projects like Synapse should use APP_INDICATOR_CATEGORY_OTHER

Regards,
Jason

@DBO/didrocks: It would be really helpful if this was documented in some way in the documentation of AppIndicator library, could you please direct the right people to the last comment? Thanks.

I changed Synapse to use Category.OTHER, so marking as fixed.

Added indicator-weather as I'm seeing that there. It is quite possible that this does not apply to newer weather-indicator, but I see it now on Maverick using indicator-weather 0+95+bugfixes~maverick1 from this ppa: ttp://ppa.launchpad.net/nafallo/indicator-weather/ubuntu
If this bug is no longer present, please mark accordingly. Thanks!

Adding to my latest comment that I see this now in package 10.07.16-0bzr95-maverick1 of indicator-weather. bzr95 looks to be the latest revision. Sorry about the noise.

Made a patch for weather-indicator. Did this first on my laptop, and it works. Made the patch on my phone, hope I got it right.
The patch should be applied to /bin/weather-indicator.

Hope this helps, my first patch ever.

Thanks for indicator-weather patch, works great!

Patch for one-indicator attached. Goes in /ubuntuone_indicator/__init__.py