Newer Google Chrome versions >= 35* offer to integrate Google Now cards and other features into the browser via a notification thingy. It presents itself as a Bell in the notification area but only works if libappindicator is installed. Chrome runs without but cannot access Google Now Cards etc.
I don't think it makes sense to add a dependency for an optional feature like this.
(In reply to Mike Gilbert from comment #1) > I don't think it makes sense to add a dependency for an optional feature > like this. In that case, why not have a USE-flag?
Well it's not just "optional". You need libappindicator to get a chrome icon in your taskbar for background processes (like extensions). Without it the processes run but you cannot access them in any way without opening up a new browser window. There is a related bug in the chrome bugzilla (https://code.google.com/p/chromium/issues/detail?id=267195) which talk about getting an X11 compatible icon thingy going but right now libappindicator is the only option.
Interestingly enough, after the installation libappindicator, the notification centre still does not show up. I am using chrome 35.0.1916.114_p1 and have google now cards enabled in chrome://flags.
libappindicator may be the incorrect version. Google says it requires libappindicator1. The libappindicator ebuild installs libappindicator3 for me. See this issue: https://code.google.com/p/chromium/issues/detail?id=378294
I think libappindicator1 is the version you get when you build against gtk2 instead of gtk3. There are currently no ebuilds providing this in the portage tree. @ayatana-bugs: Any advice here? I guess google-chrome has a soft dependency on this.
(In reply to Mike Gilbert from comment #6) > I think libappindicator1 is the version you get when you build against gtk2 > instead of gtk3. > > There are currently no ebuilds providing this in the portage tree. > > @ayatana-bugs: Any advice here? I guess google-chrome has a soft dependency > on this. - ayatana-bugs@ is understaffed - Ubuntu has designed the build-sys of the ayatana libraries, like libappindicator, in a way it's not easy to SLOT them because gtk2 and gtk3 share same headers So, we only ship GTK+ 3.x ayatana libraries in Portage for a purpose If at all possible, disable any use of GTK+ 2.x ayatana libraries in your package, and preferably put it behind USE="ayatana" (which is use.masked)
google-chrome is a pre-built binary; it loads libappindicator.so.[01] using dlopen. I don't need headers, all I need is the shared objects. If you will not provide this, I will have to close this as CANTFIX.
(In reply to Mike Gilbert from comment #8) > google-chrome is a pre-built binary; it loads libappindicator.so.[01] using > dlopen. > > I don't need headers, all I need is the shared objects. > > If you will not provide this, I will have to close this as CANTFIX. you can join ayatana-bugs@g.o, and maintain SLOTed libappindicator:0 with design of: libappindicator:2 (gtk2 shared lib, .pc file, docs, etc. ) libappindicator:3 (gtk2 shared lib, .pc file, docs, etc. ) libappindicator:headers (both :2 and :3 depend on this since they share headers) ayatana-bugs@ contains Unity prereq libraries and we've kept them minimal in tree, letting people get full unity from the unity-overlay instead since it's clearly not supported in Portage currently (needs specially patched toolkits like gtk and qt, it's pretty ugly in the end) but you can join ayatana-bugs@ just to maintain package or two, or add chrome to metadata.xml, ... all good :)
Thanks, but I'm really not interested in maintaining it.
