-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
player.bus_name_player_name_part()
returns wrong value on reverse domain package names
#81
Comments
To ease up on discussion, here's the code in question: Line 115 in 26176cb
I agree with this issue and it should be possible to make a better guess of the app name. I'm very much open for PRs on this, until I get the time and motivation to look at it myself. |
I don't believe that there's a clean solution for this because MRPIS doesn't specify how exactly the instance part should look like.
Theoretically doing something as simple as a incrementing counter is fine, so I was thinking about counting the dots in the name which would kinda work:
This is clearly a hack but I guess it does slightly improve the situation. Though I think the smarter thing would be to just assume that all implementations use the example shown on the MPRIS page which is |
I agree that there isn't a foolproof solution to this. It's also worth noting that the dotted notation isn't just unique to Flatpak, it's generally recommended by gnome so calling it specific to flatpak can be misleading. I have one player that is also available on flatpak but I have it installed from system packages and it still has that kind of naming since that's just how application-ids work. Nor are flatpaks forced to comply with this for their D-Bus name, Blanket for example reports it as simply That said I guess the I'm not sure what to suggest in the end:
|
Moving towards making fewer guesses would be my preferred solution; presenting it mostly as-is and letting the client care more about it. However, a "guessing" method could still be useful to provide since the pattern would be very common and I think having all the little edge cases documented in the central library is better than having all clients need to rediscover the exceptions during their lifetimes. I'm pretty sure I based this implementation a bit around how some other software handled it, for example Lastly, one approach that could be possible for guessing is honestly to do a list of known examples. Players like "spotify", "totem", "celluoid", "blanket", and so on could get very accurate detection from being listed in their respective "buckets" for how to "parse" the instances. (Sounds like a nightmare to get this one right and I'm not sure I really see the full value of it, but hey - it's an idea.) |
What is the use case of removing the instance part in the first place though? The bus name is only useful if you want to control a specific player so removing the unique part seems to be counterproductive. I can't think of a situation where the stripped bus name would be more useful than |
I agree with not really understanding it. It as introduced in #53. Perhaps we should just deprecate it and leave apps to do this themselves if they need it. I'm leaning pretty heavy towards that. |
I think that's the best solution. There is no actual spec for the instance part and there's no clean solution for it so I think it's fair to say that it's up to the person using this library to decide how they want to deal with this issue. The only edge case I can think of where this would be relevant is when 2 players have the same name but for some reason use a different bus name (GNOME ID vs regular name or one of the players avoiding a name conflict) but this seems unlikely and not worth the effort of maintaining a big list of players and their quirks. I'm for either just changing let finder = PlayerFinder::new().unwrap();
for player in finder
.iter_players()
.unwrap()
.map(|p| p.unwrap())
.filter(|p| p.bus_name_trimmed().starts_with("mpv"))
{
// Do something with only mpv instances
} I thought about maybe adding this functionality to |
I'm making the call now. Thank you all for the discussion! ❤️ The method will be deprecated and removed in the next major release.
Changing its behavior is a breaking change, so I want to leave it alone. We should mark it as deprecated only.
Having If someone picks up this suggestion to deprecate, please include the code example above in the Changelog and function documentation as a way to work around the deprecation. |
Should I just force push changes into the existing PR or make a new one? And I'm assuming that |
A force push would be appreciated. |
Apps, especially ones from Flatpak use a reverse-domain notation like
io.bassi.Amberol
this makes their D-Bus name show up likeorg.mpris.MediaPlayer2.io.bassi.Amberol
and in return using theplayer.bus_name_player_name_part()
only returnsio
instead ofio.bassi.Amberol
I understand it's partly due to the attempt to remove that instance part on other players, so I am not sure if there is a feasible solution in this case but I wanted to report that such things happen to start a discussion.
The text was updated successfully, but these errors were encountered: