It seems that this happens on Ubuntu when the Shell it started manually using --replace. I'm starting the Shell with the session, and I don't experience this bug.

Anyway, we may need to add yet another workaround for Ubuntu, since they won't do it themselves... A series of killall in src/gnome-shell.in should do the trick.

(In reply to comment #1)
> Anyway, we may need to add yet another workaround for Ubuntu, since they won't
> do it themselves... A series of killall in src/gnome-shell.in should do the
> trick.

Hooray! On topic: pkill is considered more portable than killall ...

Created attachment 163479 [details] [review]
Kill Ubuntu indicators on start-up

Canonical replaced status icons with libindicator based solutions,
which don't work in the shell environment. Force the distro-patched
versions to fall-back to upstream.

The patch has been reported to work, but apparently the indicators don't restart themselves with the panel (yeah!) - keeping track of the indicator processes we kill and restart those on exit should be possible, but frankly I'm not very keen on adding complex distro-specific workarounds (especially ones I cannot test) ...

Comment on attachment 163479 [details] [review]
Kill Ubuntu indicators on start-up

>+        subprocess.call(["pkill", "-f", "indicator-"])

you can't safely pkill random regexes like that. (that would match things like "emacs indicator-session-service.c".)

Also, do you actually have to kill each indicator? I thought there was a certain "indicator host" d-bus service that had to be killed or something, and then all the libappindicator things would fall back to using the tray protocol? Or do they only decide which to use at startup?

(In reply to comment #4)
> you can't safely pkill random regexes like that. (that would match things like
> "emacs indicator-session-service.c".)

Mmmh, crap ... how about something like "^[^ ]*indicator-"?


> Also, do you actually have to kill each indicator? I thought there was a
> certain "indicator host" d-bus service that had to be killed or something, and
> then all the libappindicator things would fall back to using the tray protocol?
> Or do they only decide which to use at startup?

I have no idea - if any Ubuntu user could pick up on this?

the only way i could get them to dissapear was killing them one by one, on some of them when you kill them you get a warning and if you want to reload them.

Created attachment 163514 [details] [review]
Kill Ubuntu indicators on start-up

So far, I haven't been successful in contacting any Ubuntu developers in order to figure out a more graceful method to disable those indicators - meanwhile, here's an updated patch with a more tightened regex.

Created attachment 163618 [details] [review]
Kill Ubuntu indicators on start-up

According to folks on #ubuntu-devel killing indicator-application-service should be enough - I can't confirm that myself, so I'd appreciate testing from Ubuntu users.

Comment on attachment 163618 [details] [review]
Kill Ubuntu indicators on start-up

>+    if perf_output is not None:
>+        subprocess.call(["pkill", "-f", "^([^ ]*/)?indicator-application-service$"])

why does it depend on perf_output?

marking this needinfo since it needs to be tested by an Ubuntu user anyway

(In reply to comment #9)
> (From update of attachment 163618 [details] [review])
> >+    if perf_output is not None:
> >+        subprocess.call(["pkill", "-f", "^([^ ]*/)?indicator-application-service$"])
> 
> why does it depend on perf_output?

It doesn't, it just seems unnecessary when we are about to return to the normal environment anyway (unless we expect it to have a noticeable impact on performance).

(In reply to comment #11)
> > why does it depend on perf_output?
> 
> It doesn't, it just seems unnecessary when we are about to return to the normal
> environment anyway

Oh, right. Well, there have been tray-icon-related performance problems before (the whole "shell doesn't draw anything if the tracker trayicon is running" thing), so I'd say don't special-case it.

Good to commit with that change. Er, once someone actually confirms that it works.

Created attachment 163855 [details] [review]
Kill Ubuntu indicators on start-up

(In reply to comment #12)
> Oh, right. Well, there have been tray-icon-related performance problems before
> (the whole "shell doesn't draw anything if the tracker trayicon is running"
> thing), so I'd say don't special-case it.

OK.


> Er, once someone actually confirms that it works.

Ehm, yeah.

Ok, this patch works for me on Lucid:


diff --git a/src/gnome-shell.in b/src/gnome-shell.in
index ad95c55..ca9b55f 100644
--- a/src/gnome-shell.in
+++ b/src/gnome-shell.in
@@ -178,6 +178,12 @@ def start_shell(perf_output=None):
         if os.path.exists(mozjs_libdir + '/libmozjs.so'):
             env['LD_LIBRARY_PATH'] = os.environ.get('LD_LIBRARY_PATH', '') + ':' + mozjs_libdir
 
+    # Yet-another-Ubuntu-workaround
+    # http://bugzilla.gnome.org/show_bug.cgi=id=621382
+    subprocess.call(["pkill", "-f", "/usr/lib/indicator-applet/indicator-applet"])
+    subprocess.call(["pkill", "-f", "/usr/lib/indicator-application/indicator-application-service"])
+
+
     # Log everything to stderr (make stderr our "log file")
     env['GJS_DEBUG_OUTPUT'] = 'stderr'

Created attachment 163878 [details] [review]
worked for me on lucid.

Created attachment 163879 [details] [review]
working patch

Created attachment 163881 [details] [review]
Kill Ubuntu indicators on start-up

OK, the previous patch didn't work. The applet will restart that service while it is running, so we must either kill it as well or wait for gnome-panel to be replaced.

The other patch uses the first method (which will result in a crash dialog popping up while the panel is still running), this patch moves the pkill call from the startup script into the shell itself.

The patch has been reported to work fine, including restarting the indicators after exiting the shell.

The panel seemed like a logical place to put it, though main.js may be a better place after all ...

Review of attachment 163881 [details] [review]:

Using Ubuntu 10.04:

This patch fixes the battery indicator for me. However, I don't see a volume or message indicator. Should I expect to see these or is the patching working properly?

(In reply to comment #18)
> This patch fixes the battery indicator for me. However, I don't see a volume or
> message indicator. Should I expect to see these or is the patching working
> properly?

The missing volume control is a known problem - it appears that gnome-volume-control-applet is not started on Ubuntu, as the app-indicator based replacement is supposed to handle it.

Now, we could work around that as well by
(1) detecting whether gnome-volume-control-applet is running
(2) remembering the running state
(3) starting g-v-c-a if necessary
[when exiting shell]
(4) killing g-v-c-a if we had to start it

Not sure if it's a good idea though ...


In regard to the message indicator - I don't know exactly what you mean. If it's one of the indicators Canonical added all over the place, then no, none of those work in GNOME Shell.

(In reply to comment #19)
> Now, we could work around that as well by
> (1) detecting whether gnome-volume-control-applet is running
> (2) remembering the running state
> (3) starting g-v-c-a if necessary
> [when exiting shell]
> (4) killing g-v-c-a if we had to start it
> 
> Not sure if it's a good idea though ...

we'll be using a javascript-based volume indicator "soon" probably, so let's not worry about it for now (but maybe note in the wiki somewhere that you can launch that by hand if you want)

Comment on attachment 163881 [details] [review]
Kill Ubuntu indicators on start-up

Move it down to right before the traymanager stuff rather than doing it at the start of the function. Otherwise good.

Attachment 163881 [details] pushed as 9baf8e1 - Kill Ubuntu indicators on start-up

*** Bug 374601 has been marked as a duplicate of this bug. ***