Fix loading albumArt from Chromium MPRIS

[EndarValuk]

Added new handle for albumArt from MPRIS metadata provided by Chromium based browser in a PlayerRow.

Before:

After:

Fixes #279

[danirabbit]

Historically we have avoided adding application specific workarounds. Can this be reproduced with other flatpak apps as well? Can this be solved in way that isn't specifically hardcoding the Chrome RDNN?

For example at a minimum maybe can we check for the existing of the file in /tmp and if it isn't there, then we can check if it exists in .flatpak / application_id? I think we should be able to get the app ID from MPRIS

Probably should also use GLib.Path to build paths https://valadoc.org/glib-2.0/GLib.Path.build_path.html

[EndarValuk]

@danirabbit

Historically we have avoided adding application specific workarounds. Can this be reproduced with other flatpak apps as well? Can this be solved in way that isn't specifically hardcoding the Chrome RDNN?

Checked, its not a flatpak-specific "feature" of chromium. Its a "chromium" way.
Same behaviour persists even when using "deb-based" chromium distribution.
I will take look on it, for which apps its an applicable case.

For example at a minimum maybe can we check for the existing of the file in /tmp and if it isn't there, then we can check if it exists in .flatpak / application_id? I think we should be able to get the app ID from MPRIS

I will take look on it, to implement a cleaner way.

Probably should also use GLib.Path to build paths https://valadoc.org/glib-2.0/GLib.Path.build_path.html

I will update code according to that note

[EndarValuk]

@danirabbit

I think we should be able to get the app ID from MPRIS

atleast, we got very strange behavior, dbus sending us something like that:
org.mpris.MediaPlayer2.chromium.instance33959
but we got an com.google.Chrome app name actually.

And if i'm right, current implementation doesnt allow us to get an actual app_info from stripped ifaces.
It will require refactoring a bit.

Fast way solution, updated:

            /**
            * For some MPRIS sources, we can see strange file uri like "file:///tmp/.com.google.Chrome.{Hash}",
            * files being stored in users runtime directory, and we should handle it properly to display albumArt.
            */
            if (! FileUtils.test (fname, FileTest.EXISTS)) {
                fname = Path.build_path (Path.DIR_SEPARATOR_S, GLib.Environment.get_user_runtime_dir (), ".flatpak", "com.google.Chrome", fname);
            }

UPDATED:

According to MPRIS spec we wont get actual google chrome app name, because chrome developers set it as chromium, but they r storing files under com.google.Chrome folder.
Working on it. Help appreciated.

[danirabbit]

Hm yeah this seems like it's just a bug upstream in Chromium and will need to be addressed there since we can't get the proper app id from either the Identity or DesktopEntry properties (DesktopEntry is null even). This happens in both Chrome and Chromium so just hardcoding Chrome's app ID here doesn't fix it.

Another thing I can think of, it's kind of brute force, but you could iterate over every folder in user_runtime_directory / .flatpak and check if the file exists in any of them. Not super clean, but it should work

[EndarValuk]

Another thing I can think of, it's kind of brute force, but you could iterate over every folder in user_runtime_directory / .flatpak and check if the file exists in any of them. Not super clean, but it should work

Added little bit more elegant solution with a regex

[danirabbit]

That's definitely a lot smarter than iterating over every folder, nice job! Just gotta make sure to stick to code style conventions re variable naming, spaces, etc.

https://docs.elementary.io/develop/writing-apps/code-style

See also linter output: https://github.com/elementary/wingpanel-indicator-sound/actions/runs/11359271917/job/31695048276?pr=280

[EndarValuk]

@danirabbit code updated

UPDATE:
Re-done Regex from literal to instance, to prevent lint false erroring.

[danirabbit]

Hey sorry for taking a couple days to respond. We usually prefer printf syntax over string literals. See https://docs.elementary.io/develop/writing-apps/code-style#string-formatting

[EndarValuk]

Hey sorry for taking a couple days to respond. We usually prefer printf syntax over string literals. See https://docs.elementary.io/develop/writing-apps/code-style#string-formatting

I'm new in vala lang development(mostly use managed languages), but never encountered printf syntax over regexp literals.

Anyway I've updated PR code. No more linter errors occur.
Is it now ok, on ur perception, to be merged?

[danirabbit]

This looks good to me. Nice fix!