Add optional support of indicator applet

Isn't the indicator applet for messages like email, IM, etc.? Exaile doesn't generate any of those...

Indicator applet is also used by Rhythmbox and other apps (not only IM and emails). It is a way to make the panel clean by replacing the current GtkStatusIcon.

Do you have a link to the spec, or examples of how to use it then? As I don't use Ubuntu or GNOME myself I won't be working on this, but if someone comes along who is interested in adding this to Exaile such documentation would be useful to have on hand.

There is an example using Python here :
https://wiki.ubuntu.com/DesktopExperienceTeam/ApplicationIndicators

I think this would also be useful. Adding exaile support to sound-indicator.

http://www.webupd8.org/2010/07/sound-indicator-in-ubuntu-maverick-gets.html

I tried to implement the Application Indicator for exaile and after quite a lot of struggling have abandoned that branch, while I was working on it I really started to see how the sound menu indicator seemed like much more of a good idea.

I started implementing the mpris 2 interface for exaile and have gotten quite far, I've attached a screenshot displaying current progress.

Most of the functions have been implemented besides off the top of my head the open uri and album cover location as I don't think exaile exposes the location in its api so I set the cover to the nocover image in the mean time.

Currently clearing the track does not work and for the item to be registered in the Sound menu you have to have a /usr/share/applications/exaile.desktop Desktop properties file, which you will have if you have installed exaile from a repository

> I don't think exaile exposes the location in its api so I set the cover
> to the nocover image in the mean time.

That's because it is not guaranteed that the cover will HAVE a location in the filesystem. For example, when the cover is embedded in the file's tags, it is just loaded directly from the tags instead of being copied to somewhere on the filesystem. As a workaround for this, I suggest creating a temporary cover file in /tmp when the cover is requested and using that path instead.

I've implemented displaying cover art and almost all of the other functions.
The sound menu works fine as it only uses a subset of the mpris2 interface, currently.

I've had a few problems mapping some of the interface properties to exaile though, volume is a property
in the Player interface but because volume is controlled via the settings object it currently does not emit an event
when it is changed. The seek event also needs to be triggered but currently seeking does not trigger events either.
Exaile also doesn't track if there is a next or previous track available but I think that could be done with some playlist object
workarounds.

According to the spec tracks require a unique id - unique inside playlists even with the same track added multiple times - to make it available on dbus, this is really a side issue as there is currently no track interface and this is only in the interface for future extensions, so the MetadataList object index method should work but I think it will break if them same track is added multiple times as the first index will be returned.

Also for some reason when I try to set the shuffle mode and repeat modes via dbus nothing seems to happen, I'll attach some code that prints the track metadata and tries to change the Shuffle and LoopStatus properties

Could you give me some help on how to use/test your branch?

I've copied your branch, but when I run it (through the "exaile" script or "python exaile.py") I get no sound menu integration.

For sound menu registration to work you need to have a '/usr/share/applications/exaile.desktop' file, that's the only thing I can think of that you might be missing. If you install exaile form the repos you should have it.

Also which version of Ubuntu are you using?

I'm using Ubuntu 10.10 - is that the problem? I noticed I had to change
"python2" to "python" in /usr/local/bin/exaile

I installed exaile from the repos copied the exaile.desktop to another
location and removed the repo-exaile. Then I did a "make && make
install", and restored exaile.desktop to where it should be.
Tried to run "exaile" and got something like "python2" not found.
Changed "python2" to "python" then ran exaile, and got the following:

Traceback (most recent call last):
   File "/usr/local/lib/exaile/exaile.py", line 62, in <module>
     main()
   File "/usr/local/lib/exaile/exaile.py", line 57, in main
     from xl import main
   File "/usr/local/lib/exaile/xl/main.py", line 44, in <module>
     from xl import mpris
   File "/usr/local/lib/exaile/xl/mpris.py", line 28, in <module>
     from xl import event, covers, player, settings
   File "/usr/local/lib/exaile/xl/covers.py", line 545, in <module>
     check_exists=False))
   File "/usr/local/lib/exaile/xl/covers.py", line 132, in __init__
     default_cover_file = open(self.default_cover_path, 'rb')
TypeError: coercing to Unicode: need string or buffer, NoneType found

On 11-01-26 12:58 AM, Ciaran Liedeman wrote:
> For sound menu registration to work you need to have a
> '/usr/share/applications/exaile.desktop' file, that's the only thing I
> can think of that you might be missing. If you install exaile form the
> repos you should have it.
>
> Also which version of Ubuntu are you using?
>

I managed to reproduce the bug, I'm using Ubuntu 10.10 aswell btw.

It seems that nocover.png is not in any of the expected folders that exaile checks - ['~/.local/share/exaile', '/usr/local/share/exaile', '/usr/share/gnome/exaile', '/usr/local/share/exaile', '/usr/share/exaile'] but when run form the source directory with
`python exaile --startgui` it checks the exaile/data directory for the image and finds it.

Copying the noimage.png from the data/images folder to ~/.local/share/exaile/images/ should fix the problem, I had a quick look through the makefile but I couldn't tell if it was the problem.

Looked a bit closer at the code, the file is on Ubuntu installed to
/usr/local/share/exaile/data/images/noimage.png and the current trunk expects it to be
/usr/local/share/exaile/images/noimage.png

This could be added to the mainstream package: http://github.com/sunng87/Exaile-Soundmenu-Indicator

Provides perfect integration with indicator-sound.

See also bug 618483 about MPRIS2 inclusion. In short, don't worry about the .TrackList and .Playlists interfaces, they're too much code (complicates codebase and slows down startup) for too little gain (people actually use those?).

I imagined having an MPRIS2 plugin first and then gradually merging it to core, but I don't really see a problem with it going straight to core. It's also possible to move our current D-Bus interface to a plugin before phasing it out in a later version.

Ciaran: Regarding the track ID, actually it should not be the URI at all. The documentation is inconsistent, but if you look at SetPosition it has the type "o", which means it's a D-Bus object path. I actually suggest using '/org/exaile/trackid/' + str(hash(track)). It's not unique at all (because tracks are singletons), but it's the laziest solution considering we don't care about .TrackList.

Johannes: Its not really important as its only there for future use anyway, there are no functions that can be called on
a track object anyway currently.

I realized while trying to code the plugin how far reaching the entire interface is and how some of the exaile api's don't
allow for the needed functionality.

For the minimal plugin I've been looking at https://code.launchpad.net/~rick-rickspencer3/+junk/sound_menu
which contains all the glue code for the indicator applet, but I was hesitant to write a plugin that only Ubuntu would benefit
from.

It would be nice if you can move the AppIndicator part to a plugin. At this point it doesn't matter where you put the MPRIS2 part, it can be moved around easily later.

By the way, how complete is the code in your branch? Once it's done, you can submit a merge proposal and then we can do a proper review.

I implemented the minimum requirements to be MPRIS compliant, just the org.mpris.MediaPlayer2 and org.mpris.MediaPlayer2.Player interfaces. I might have skipped one or two functions like rate and playback rate.

The basic functions work quite well, I've been using it for the past month or so but I don't think the code is good enough yet.
There are still quite a few hacks in some areas i.e. adjusting the volume and album album art file location.
Also adding the other interfaces would be difficult with the current queue api.

After looking at Rick's I've already seen a few ways to improve it but don't have the time right now, this would be mostly changing alot of the variables to use the property wrapper and testing the methods properly.

For now here is a minimal plugin using Rick's code: pause next raise etc. all work but album art is not implemented.

> Regarding the track ID, actually it should not be the URI at all.
> I actually suggest using '/org/exaile/trackid/' + str(hash(track)).

Actually, since Track objects in Exaile are unique per-uri, that's effectively the same as just using the uri outright.

The proper way to do this would be to take advantage of playlists in trunk using MetadataLists and storing a unique id in "mpris_track_id" or something for each track. I don't think the MetadataList api is exposed on Playlist itself yet but that's easy enough to fix. This would require a fair bit of extra code though, so for now I'm in favor of just not supporting the TrackList section of the MPRIS api.

I don't have any objection to supporting a minimal MPRIS2 in mainline alongside our current dbus api - it's a pretty small amount of extra code and opens a lot of possibilities for integration with other apps. Extra MPRIS2 features like TrackList can either be added later when we figure out a good way to do them, or can be added onto the core via plugins.

In natty, Exaile is not even listed in the sound indicator.

AFAIU it is not related to MPRIS protocol implementation, but to the .desktop file
(my source: http://theravingrick.blogspot.com/2011/02/easily-support-sound-menu-in-python.html)
However I could not figure out what difference there is with Banshee's one.

I am the author of the exaile sound menu support plugin,
I just updated it to make it compatible with Natty.

You can download the head version and test it.
https://github.com/sunng87/Exaile-Soundmenu-Indicator

Currently I still have a problem on trayicon. According to Ubuntu SoundMenu wiki, trayicon should be disabled when soundmenu item registered. And when soundmenu activate, window_close should behavior as hide.

However, this cannot be archived by a plugin. I tried to modified the xl.gui.main.controller.trayicon at runtime, but it's very difficult to archive the full functionality. I think I need some help from upstream. The right behavior should be: click 'X' to hide window when tray icon is also disabled.

You will get a lot more feedback for your plugin if you post a patch or atleast create a bzr branch instead of using a third party vcs site as this makes it impossible for any of the developers to take a quick look .

In order to hide exaile, you can use the options "Show tray icon" and "Minimize to tray" (appearance options). Natty doesn't show the systray. So, when you minimize or close exaile, it hide the window and you can control exaile with the sound indicator !

Marked as duplicate since bug #618483 has more progress.