Use libappindicator for tray icon

[Oleksiy-Yakovenko]

Original issue 1268 created by Alexey-Yakovenko on 2015-02-13T13:38:29.000Z:

I am using plasma next on archlinux. It is known that plasma next has dropped support for xembed tray icons. GTK applications should use libappindicator to display a tray icon in plasma next. Is there any plan to implement tray icon with libappindicator?

[Oleksiy-Yakovenko]

Comment #1 originally posted by Alexey-Yakovenko on 2015-02-13T14:11:48.000Z:

There are no plans to implement appindicators support ATM.

Perhaps this project would be useful for you: https://github.com/rpeshkov/deadbeef-indicator

EDIT: looks like it migrated here: https://bitbucket.org/rpeshkov/deadbeef-indicator

There are other similar projects, just google for "deadbeef appindicator".

[Oleksiy-Yakovenko]

Comment #2 originally posted by Alexey-Yakovenko on 2015-02-14T00:26:20.000Z:

Yeah,I found that too.Since libappindicator implement is not coming soon,I will use a script to start deadbeef and the python script at the same time. Still it would be great if there is a plugin for that : )

[vovochka404]

Как известно, зима близиться... А точнее plasma5 уже начинает становиться дефолтом в дистрибутивах.

Изучение тематики показало что libappindicator обладает одним существенным недостатком, а именно отсутствие события "клик мыши". Оно просто вывалит меню, что соответственно меняет поведеине по умолчанию, а этого хотелось бы избежать. Вообще говоря с обработкой событий там как-то плоховато.

Есть и другой вариант. https://github.com/jjk-jacky/statusnotifier Но он не имеет встроенного fallback'а, т.е. заморочится придется сильнее чем с appindicator, к тому же как я понял только для gtk3 версии. А еще видать эту либу надо тащить к себе в проект.

Наверняка вы уже что-то думали по всему этому поводу, может поделитесь мыслями, соображениями по этому поводу? Стоит ли ждать вашей реализации, или таки попробовать наваять что-то самому? :)

[Oleksiy-Yakovenko]

@vovochka404 Сожалею, но я ничего не думал по этому поводу, и никаких изменений в отношении индикаторов у меня нет.

[vovochka404]

А возражения? Если я таки попробую прицепить appindicator?

[Oleksiy-Yakovenko]

возражения против чего конкретно, и почему они у меня должны возникнуть?

[Oleksiy-Yakovenko]

Switching to english..

I will explain my position on the Tray icon vs AppIndicators:

The tray icon in deadbeef is useful, because:

• you can control the volume (scrollwheel);
• pause/unpause (middle click);
• view the current track in tooltip (hover);
• hide/unhide the player (left click);
• access the mostly useless menu (right click).

Of this list, the indicators can only do the last item.

The problem is, the preferred way to do this in Ubuntu/Unity is using MPRIS to integrate with Ubuntu Sound menu.

This means, appindicator for deadbeef is not needed.

Now, am I missing something?

[Oleksiy-Yakovenko]

Another thing to note, @vovochka404

The playback menu, which I guess is the reason why you want the appindicator, is already accessible via the dock icon. Here's the screenshot from Ubuntu:

and I just added the same thing to OSX version:

Is this thing not available in KDE?

[vovochka404]

About plasma5/KDE5

The main and only problem of tray icon in plasma5 is that it's absolutely absent. Old systray sticked to X11 is not supported any more

About appindicator limitations

Appindicator has scroll-event signal and secondary_activate_target (meny entry). Yep, in fact it's really inconvenient, but better then nothing.

On the other hand i've proposed another realization of StatusNotifier protocol. It's more flexible, allows to control all events, but has no builtin fallback to a common tray icon.

[Oleksiy-Yakovenko]

So what about the dock icon menu and sound menu, similar to Unity? Is it supported on KDE? If not, then obviously KDE is going different route than everything else, and you might want to implement the appindicator to fill the gap. But that would mostly be a KDE-specific feature.

[vovochka404]

Plasma have no dock by default (and never had). Task bar has no any app specific menus. Tray works just like always (except it doesn't support xembed-based icons and only works with SNI) KMix must support Sound Menu (but it's about MPRIS, nothing related to icons).

[Oleksiy-Yakovenko]

But if there's kmix with sound menu -- why do you need another appindicator for deadbeef? (Of course, I mean if deadbeef supports MPRIS :)

[vovochka404]

In fact i didn't now that kmix in kde5 has support for Sound Menu :) Will check later when i'll be at home.

But it's inconvenient to work with player through kmix. I want deadbeef to have it's common tray icon :)

[vovochka404]

And! On the other hand currently: 1) deadbeef supports mpris through 3d party plugins. 2) deadbeef dies in opensuse 13.2 when this plugin is used.

[Oleksiy-Yakovenko]

I want deadbeef to have it's common tray icon :)

App indicators do not replace or simulate system tray icons. Well, maybe they do in KDE, but definitely not in GNOME, Unity, or OSX (where they originated). Dock should be used instead. When there's no doc -- there's a problem. And I will repeat my question again :) What feature(s) of the system tray icon do you want to put in the appindicator? The menu is possible, and turned out that scroll wheel is possible. But nothing else.

If you want system tray -- you will have to use something that has system tray. Like XFCE, LXDE, MATE, etc.

deadbeef dies in opensuse 13.2 when this plugin is used.

This is because the plugin is poorly implemented. Which doesn't mean nobody will make a better one which doesn't crash.

[vovochka404]

App indicators do not replace or simulate system tray icons.

AppIndicator - is just a realization of StatusNotifier specification (but contains fallback to a common systray icon for environments without StatusNotifierWatchers). The representation on StatusNotifierItems - is task of StatusNotifierHosts. In unity the role of SNH played by dock. In kde - by tray. Their behavior is just the same.

What feature(s) of the system tray icon do you want to put in the appindicator? The menu is possible, and turned out that scroll wheel is possible. But nothing else.

From the status notifier spec about signals: ContextMenu - commonly rmb. Activate - commonly lmb SecondaryActivate - commonly mmb Scroll - scroll But activators depends on StatusNotifierHost

So, if custom realization will be used (not libappindicator) but the other one i've proposed then all current behavior will be saved. But the main problem of this custom realization is that it's looks like for gtk3.

[Oleksiy-Yakovenko]

I will try the statusnotifier demo app, and will get back to you.

[Oleksiy-Yakovenko]

I have tried to build the statusnotifier lib, and turned out it doesn't work on ubuntu 12.04. Do you know which linux distro it is compatible with, so that I can try it easily?

[vovochka404]

В чем выражается это "не работает"? В осутствии иконки? Или оно умирает? Иконки вероятно нет из-за того что эта реализация расчитана сугубо на StatusNotifier И как я говорил, не имеет фолбека на стандартные иконки. Т.е. если в 12.10 не запущено ни одно StatusNotifierHost - то конечно иконки не будет, ничего работать не будет.

Для того что бы это проверить - достаточно запустить qdbusviewer и фильтранунть сессию по status и убедится есть ли StatusNotifierWatcher и какой-нибудь StatusNotifierHost

Я знаю что это дело поддерживается лишь в kde4/5 и Unity (не знаю с какой версии). Но может и не только...

[Oleksiy-Yakovenko]

В чем выражается это "не работает"?

https://github.com/jjk-jacky/statusnotifier/issues/6

[vovochka404]

it's must be fixed in "next" branch

[Oleksiy-Yakovenko]

Yes, the "next" branch worked better. I built the lib, and the example. Running the example doesn't do anything though -- no icons appear in notification area. I'm running unity.

[vovochka404]

Have u seen help? Have specified icon via --icon?

[vovochka404]

And add --status active

[Oleksiy-Yakovenko]

I didn't know there's help :)

Running like this: ./a.out -i /usr/share/icons/hicolor/48x48/apps/gdu-error.png -s active

Still nothing happens.

I have tried many different ways to specify the icon name, full path, just the name, name.png -- nothing works.

[vovochka404]

-I -this must be a path to a file, -i - must be an icon name.

Do u have StatusNotifierHost in your system?

[Oleksiy-Yakovenko]

Do u have StatusNotifierHost in your system?

How do I find out? There's no such process. I thought that this thing is a standard indicator, just implemented with another library.

[vovochka404]

It's dbus interface. check it via qdbusviewer.

I've described it in this comment

[Oleksiy-Yakovenko]

ok that's more tricky. it requires to install qt4 devtools, and apt-get says it will take 4 hours. waiting for it.

[vovochka404]

Sorry for that... I don't know any other way to inspect current dbus session. :(

[Serranya]

deadbeef dies in opensuse 13.2 when this plugin is used.

Are you talking about my rewrite of the MPRIS plugin ? If so please open a bug report.

[vovochka404]

Are you talking about my rewrite of the MPRIS plugin ? If so please open a bug report.

Nope. Packman currently provides only first and unmaintained plugin

[Oleksiy-Yakovenko]

Checked in qdbusviewer, and I don't have any StatusNotifierHost. What does that mean? Do KDE and Unity use different protocols for indicators?

[Oleksiy-Yakovenko]

Nope. Packman currently provides only first and unmaintained plugin

The deadbeef wiki links to the one @Serranya linked. Unfortunately, the app devs don't have any control over what the distribution maintainers put in their repositories.

[vovochka404]

Unity use different protocols for indicators?

Nope. Looks like your current unity version does not support StatusNotifier. :( May be u can try with cairo-dock? It also must support StatusNotifier.

[Oleksiy-Yakovenko]

I tried running KDE, and the example worked, the icon appeared in there.

[Oleksiy-Yakovenko]

Yes, I can try cairo-dock, but that's useless, because the whole point of running the example was to see whether it will work in both KDE and Unity. It doesn't.

[vovochka404]

It doesn't work in your unity version. And i've spoken about fallback to an old GtkStatusIcon several times.

libappindicator have a builting fallback support. This lib - doesn't. So, when receiving "registration-failed" signal deadbeef should return to old behavior.

I've mentioned this as one of the problems of this lib, that fallback must be implemented by hands. The second one - i don't think that it'll be easy to port it to gtk2 (or may be it's easy, i don't know)

[Oleksiy-Yakovenko]

To me, looks like appindicator lib is a far better option then. Except it doesn't support mouse clicking etc.

The conclusion is: all libs are bad.

I'm not convinced thad deadbeef needs to have any of them integrated.

You're free to implement a deadbeef plugin for any of the libs though.

Hope I answered all of your questions.

[vovochka404]

Nope, you aren't :) With plugin i won't be able to control common icon.

May be i can try to deal with gtk2 porting and creat a fallback functionality?

Will u accept such patch? Or plugin is the only way?

[Oleksiy-Yakovenko]

With plugin i won't be able to control common icon.

Do you mean the tray icon? You're not supposed to control it. The indicator is a separate thing from tray icon. They can even exist simultaneously. The user will have to decide whether he wants the built-in tray icon, or the indicator. Both need to be OFF by default.

Will u accept such patch?

I can't tell whether I'd accept a patch before I see the patch.

Or plugin is the only way?

Plugin is the only way either way -- patch or not.

[Oleksiy-Yakovenko]

Depends on the OS... VisualStudio on windows, XCode on OSX, and I couldn't find any good IDE for linux, so just stick with VIM and GDB in xterm.

[vovochka404]

And here i'm back.

I'd like to discuss following patch It's a preview version :)

This patch adds modified version of statusnotifier lib. It removes tray-related stuff from gtkui.c to tray_cmn.c|tray_sni.c. It adds --enable-sni configure option.

The idea is to use tray_cmn when this flag is disabled and to use tray_sni if it's enabled.

tray_cmn have only GtkStatusIcon based realization. tray_sni tries to initiate StatusNotifierItem and if fails - returns to GtkStatusIcon But currently tray_sni is only possible way (in this preview).

Please, do not judge too strictly, i'm absolutely new to all this c/gtk stuff. If this idea can survive (and accepted as a patch), please help me to make it :) Any advises will be welcomed :)

If this idea is bad, please explain why :)

[Oleksiy-Yakovenko]

If this idea is bad, please explain why :)

I'm not taking patches containing code under GPL 3. Usually I'm not taking GPL2 patches either. That reason alone is enough, but I'll try to cover other reasons after I build and look at the result.

[vovochka404]

Hm... License... I'v forget about it :( (Russian mentality)

So okay, plugin... How it can be done? :(

[Oleksiy-Yakovenko]

Another reason:

configure: error: dbusmenu-glib and dbusmenu-gtk is required for SNI support for gtk2ui plugin

GTKUI must remain compatible with computers running GTK2.12.x / GTK3.0.x and up.

When you add features adding hard dependencies which are not compatible with older systems -- it becomes impossible to make a single build, which is compatible with both new and old systems.

Making such feature a plugin makes it a soft dependency. Which is possible to ship without breaking compatibility with older systems.

[vovochka404]

But this is not a hard dependency, it's a choice. This "feature" is disabled by default (thus it doesn't require anything) and a maintainer or user should decide whether he wants it or not.

[Oleksiy-Yakovenko]

It's a compile-time option versus runtime option. Users don't like compiling. When providing binary builds to them, they expect stuff to "just work".

And yes, of course it should support being disabled at compile time. But that's a separate thing.

[vovochka404]

And here a maintainer of a package in a distribution have to decide whether this feature is possible in this distribution or not. If distribution is compatible with this feature - why not to use it?

[Oleksiy-Yakovenko]

I need to generate the binary builds compatible with all distros, and the builds must have all deadbeef features included in them, configurable at runtime. As I already mentioned, we are talking about 2 completely independent separate use cases. Your approach would work for the users who build the app themselves, but not for the case when I build the app.