Applications launch faster than the extension and then fail.

[InFerYes]

In my example, when I log in, Synergy launches automatically and puts an icon in the tray. When there is no tray, the application gives an error message.

I can close the application and launch it again, then it will correctly get shown in the tray.

                   -`                 
                  .o+`                 
                 `ooo/                 OS: Arch Linux 
                `+oooo:                Kernel: x86_64 Linux 4.13.6-1-ARCH
               `+oooooo:               Uptime: 2h 29m
               -+oooooo+:              Packages: 1154
             `/:-:++oooo+:             Shell: bash 4.4.12
            `/++++/+++++++:            Resolution: 1920x1080
           `/++++++++++++++:           DE: GNOME 
          `/+++ooooooooooooo/`         WM: GNOME Shell
         ./ooosssso++osssssso+`        WM Theme: 
        .oossssso-````/ossssss+`       GTK Theme: Adwaita [GTK2/3]
       -osssssso.      :ssssssso.      Icon Theme: Adwaita
      :osssssss/        osssso+++.     Font: Cantarell 11
     /ossssssss/        +ssssooo/-     CPU: Intel Core i3-4010U @ 4x 1.7GHz [44.0°C]
   `/ossssso+/:-        -:/+osssso+-   GPU: intel
  `+sso+:-`                 `.-/+oso:  RAM: 1277MiB / 7895MiB
 `++:.                           `-/+/
 .`                                 `/

Gnome: Version 3.26.1

[3v1n0]

I don't think there's a way to make the extensions to load faster and the name is exported pretty early... This should probably be fixed by the app which should try once the watcher is available

[jhasse]

Does GNOME Shell load extensions before start-up apps?

[InFerYes]

<InFerNo_> does anyone know if extensions are loaded before applications defined in startup, or if they load at the same time?
<fmuellner> gnome-shell is started before autostart applications
<fmuellner> for extensions that are enabled at login, that *usually* means that they are loaded before autostart apps
<fmuellner> but of course a badly behaving extension could block the compositor
<fmuellner> and obviously if an extension is only enabled later by the user, it's enabled after autostart apps

My active extensions are Disconnect Wifi KStatusNotifierItem/AppIndicator Support Refresh Wifi Connections Removable Drive Menu Sound Input & Output Device Chooser TeaTime Todo.txt User Themes

[InFerYes]

When I boot for the first time and log in, the tray always works. When I log off and log back in, it fails every time, even when I log in with a different account first (like guest) and then back to my main account, and every time after.

1. Log in with account A
2. Tray works
3. Log off with account A
4. Log on with account A
5. Synergy loads before tray, shows error.

Alternatively

1. Log in with account A
2. Tray works
3. Log off with account A
4. Log on with account B
5. Log off with account B
6. Log in with account A
7. Synergy loads before tray, shows error.

B in my case is a guest account that has no profile, it's created on the fly when logging in and deleted after logging off.

[ColinHarrington]

@InFerYes Sounds like it may be a race condition between the gnome-shell environment loading and the startup. A simple workaround might be to just add a delay to the startup application by adding X-GNOME-Autostart-Delay=1 to the .desktop file in ~/.config/autostart/ to delay by 1 second.

• https://wiki.archlinux.org/index.php/GNOME#Startup_applications
• http://www.webupd8.org/2014/05/how-to-delay-startup-applications-in.html

I don't think there are any links between gnome startup applications and gnome-shell extensions. I think we want them to load in parallel on our multi-core systems. I'd imagine that the synergy app could be enhanced to handle this scenario or more scripting to do a better waiting process or add(or find) another hook into the gnome-shell extension support.

[jhasse]

We're using Gio.DBus.session.own_name which is async so that it could happen that GNOME Shell

• Calls our enable function where we call Gio.DBus.session.own_name which queues an event to own the name
• Start Synergy, which shows error
• Process event to own the name and call StatusNotifierWatcher._acquiredName

If we block in our enable function, this won't help us since Gio.DBus.session.own_name doesn't actually do anything. The event needs to be processed by the Glib main loop (from GNOME Shell).

After reading https://stackoverflow.com/questions/21485642/running-multiple-concurrent-gmainloops I think it might be possible to create a dedicated thread which tries to own the name and blocking in our enable function. Not sure if this hack would work. Thoughts?