GNOME Bugzilla – Bug 331250
Add "lookup on last.fm/google music/wikipedia/allmusic plugin"
Last modified: 2018-05-24 11:25:01 UTC
from: http://mail.gnome.org/archives/rhythmbox-devel/2006-February/msg00055.html "The highlighed links in RB that open up a page to last.fm. I think this is unnecessary, rarely used or wanted. I think a better option would to be to center on the artist, album in the browser or center the current song if a playlist." I agree entirely with Jonathan. I've never really used the web link feature and all ways thought it was a strange one. Changing this to limiting the browser to the current artist/album seems like a better idea to me.
I disagree, I like having external links to artists, especially for artists I'm not familar with (e.g. when listening to somebody else's DAAP server). I think it's a feature that rhythmbox has over iTunes. And I don't think I'm the only one who uses it. However there are other possible sites which are better: bug #324178 suggests Google Music search and it used to link to allmusic.com which was pretty good. There are also a myriad of other ways to Browse a whole album, but only one way to access external links. That said, it could be possible to have the link have serve multiple purposes (choose from centering behaviour described, Google music, Allmusic, last.fm upon first click, which it then remembers). It could get a bit hairy to maintain, however.
In: http://mail.gnome.org/archives/rhythmbox-devel/2006-February/msg00100.html James Livingstone makes a suggestion for an Artist/Album information page with links: "Personally, what I think it should do is pop up an "Artist Information" "window. The window could have a "Browser this Artist" button and links to several different sites. It could potentially have: * a list of favourite tracks by this artist * a list of their albums * statistics about what the average rating of the artists tracks are * what rank the artist is, in terms of how often you listen to them * an "Album Information" window could also display cover art * anything that a plugin wants" I think this sounds like an excellent idea, it could have links to many different sites and other statistics.
The links have been removed from cvs, but this could be implemented as a plugin. Retitling to reflect that.
*** Bug 324178 has been marked as a duplicate of this bug. ***
*** Bug 317517 has been marked as a duplicate of this bug. ***
From bug 317517: it would also be good to offer links for all songs, not just the currently playing one.
*** Bug 337051 has been marked as a duplicate of this bug. ***
Bug 337051 suggests linking to search page, because of the lack of canonical names for artists/tracks/albums.
Created attachment 64189 [details] Plugin desktop file Adding an initial desktop file for Python plugin
Created attachment 64190 [details] Initial attempt a plugin Initial implementation. Needs to also handle albums, interface needs work and will try and get the list of albums for a particular artist from rhythmdb, but query support need to be added to the Python bindings. To test: put this and the .rb-plugin file into ~/.gnome2/rhythmbox/plugins/
Currently it adds an "Artist Info" at the end of library pop-up menu.
Created attachment 64191 [details] Fixed a typo
This requires HEAD as 2006-04-23 (which is after 0.9.4).
Doesn't always open the correct default GNOME browser, in particular if it is set to epiphany it may use firefox: You can fix this by replacing the line: webbrowser.open(data) with: os.system("gnome-open " + data)
Created attachment 64201 [details] Updated: handle albums Handle albums and make popup appear in all popups where it makes sense: static and auto playlists and queue (haven't tested DAAP yet). Refine search URLs.
Created attachment 64317 [details] Added Discogs
Alex, I checked out your plugin, and I love it. Ability to pick different site is awesome. One thing I was thinking, however, was whether or not the links could be built into the interface more (instead of a seperate window, maybe a "sidebar" below the play queue, or links directly above the track position bar?). I remember a while back when RB made use of the "Song by Artist from Album" boxes. Seems like that would be a good place to add some plugin functionality! I'd love to try it myself, but the RB source doesn't come naturally to me. PS> I can attach a screenshot of what I'm thinking for the plugin/buttons if you want.
(In reply to comment #17) > Alex, > > I checked out your plugin, and I love it. Ability to pick different site is > awesome. One thing I was thinking, however, was whether or not the links could > be built into the interface more (instead of a seperate window, maybe a > "sidebar" below the play queue, or links directly above the track position > bar?). Yes, I thought about that. That probably needs to be added as hooks to rhythmbox itself so that plugins can "dock" with specific locations. It's not possible to create new interface components that are part of the same window yet. We need to add some kind of GTK notebook or somesuch so that different plugins don't end up cluttering up the screen with little windows. I've raised this on IRC before, but there's no standard agreed up as yet. As for reactivating the album/artist links in the playing track area (as per 0.9.4). I also discussed that with Doc on IRC, and he said adding hooks wouldn't be too hard, but need to decide what to do in the case that the plugin isn't installed. > I remember a while back when RB made use of the "Song by Artist from > Album" boxes. Seems like that would be a good place to add some plugin > functionality! I'd love to try it myself, but the RB source doesn't come > naturally to me. boxes? Do you mean the links above the track slider? > PS> I can attach a screenshot of what I'm thinking for the plugin/buttons if > you want. Sure, that would be useful. Think also about how it might interact with other plugins.
(In reply to comment #18) > (In reply to comment #17) > > Alex, > > > > I checked out your plugin, and I love it. Ability to pick different site is > > awesome. One thing I was thinking, however, was whether or not the links could > > be built into the interface more (instead of a seperate window, maybe a > > "sidebar" below the play queue, or links directly above the track position > > bar?). > > Yes, I thought about that. That probably needs to be added as hooks to > rhythmbox itself so that plugins can "dock" with specific locations. It's not > possible to create new interface components that are part of the same window > yet. Sounds like a hook needs to be added, then. This would allow for greater flexibility with regards to plugins and their functionality. > > We need to add some kind of GTK notebook or somesuch so that different plugins > don't end up cluttering up the screen with little windows. I've raised this on > IRC before, but there's no standard agreed up as yet. I would agree that a tracking system needs to be implemented, but if the user wants to clutter their screen with little windows, that is their decision. I honestly wouldn't mind being able to change the order of sidebar items (make them modular, so order doesn't matter). > > As for reactivating the album/artist links in the playing track area (as per > 0.9.4). I also discussed that with Doc on IRC, and he said adding hooks > wouldn't be too hard, but need to decide what to do in the case that the plugin > isn't installed. If the plugin isn't installed, revert the album/artist links back to what they are now (inactive information display). > > > I remember a while back when RB made use of the "Song by Artist from > > Album" boxes. Seems like that would be a good place to add some plugin > > functionality! I'd love to try it myself, but the RB source doesn't come > > naturally to me. > > boxes? Do you mean the links above the track slider? Yes. > > > PS> I can attach a screenshot of what I'm thinking for the plugin/buttons if > > you want. > > Sure, that would be useful. Think also about how it might interact with other > plugins. > I'll attach it when I get home (and have an updated version of RB around).
(In reply to comment #19) > Sounds like a hook needs to be added, then. This would allow for greater > flexibility with regards to plugins and their functionality. Bug #342207 has been created by Doc Livingston to address this. > I would agree that a tracking system needs to be implemented, but if the user > wants to clutter their screen with little windows, that is their decision. I > honestly wouldn't mind being able to change the order of sidebar items (make > them modular, so order doesn't matter). This wouldn't prevent the ability to create extra windows, so a random plugin could always create a new window if it wanted to. In many cases, however, especially with plugins that are distributed with rhythmbox it would be more desirable for them to be integrated in some way in the main GUI. > If the plugin isn't installed, revert the album/artist links back to what they > are now (inactive information display). Right, but the problem was more how to do that, e.g. it might not be possible to not have links in the case the plugin was not installed. In that case, we would need to have clicking on the links do *something*. > I'll attach it when I get home (and have an updated version of RB around). Ping? ;-)
Created attachment 101161 [details] [review] Submenus, Link updates, -ui.xml file Created submenus for each option Updated links for each website Put UI definition in -ui.xml file Separate functions for Artist and Album
Ping?
I'd rather the site information arrays be replaced with an object for each site, implementing a few methods. The current approach is only just flexible enough to handle the current set of sites, and adding something new might require the whole thing to be reworked. Something like this: class Site: def get_artist_url(self, artist): return "http://whatever.com/?artist=" + artist def get_album_url(self, album, artist): return "http://whatever.com/?album=" + album It should be possible to associate the Site object with the action directly, so you don't need the ugly if/elif/else block. + ## use gnome-open, less Pythonic, but uses current GNOME browser + os.system("gnome-open '%s'" % url) This should use one of the os.exec functions. Never pass potentially untrusted data to a shell.
Created attachment 113086 [details] [review] A rework as per previous comments I think this is what Jonathan had in mind. It's not the most elegant solution, but feedback is welcome and encouraged.
Please remove the generated files (Makefile.in, Makefile, infobrowser.rb-plugin) and other junk (infobrowser.old). There also seems to be a fair bit of commented out or obsolete code that needs to be removed too. That aside, this does seem to be more what I was thinking of. It should be possible to construct the UI xml at runtime. It's probably possible to identify site modules at runtime too. We should be able to set this up so users can add new sites by dropping a single file in their user plugins directory (~/.gnome2/rhythmbox/plugins/infobrowser, probably).
(In reply to comment #25) > Please remove the generated files (Makefile.in, Makefile, > infobrowser.rb-plugin) and other junk (infobrowser.old). There also seems to > be a fair bit of commented out or obsolete code that needs to be removed too. Sorry about that... never looked over my patch before submitting it... stupid me! Patch to follow. > That aside, this does seem to be more what I was thinking of. Good! > It should be possible to construct the UI xml at runtime. Any plugins that are capable of this ATM? > It's probably possible to identify site modules at runtime too. We should > be able to set this up so users can add new sites by dropping a single file > in their user plugins directory > (~/.gnome2/rhythmbox/plugins/infobrowser, probably). A 'single file' being an individual fooSite.py file? If that is the case, then the XML for the ui would need to be stored inside the file, right? Could each fooSite class contain a function that returns the XML needed to contruct the UI? Then the main infobrowser.py could construct on the fly? Would I still need a minimal infobrowser-ui.xml file to define the 5 popups? JD
Created attachment 113144 [details] [review] Removed cruft from old files, and removed commented code, also
*** Bug 409166 has been marked as a duplicate of this bug. ***
You should be able to identify all available Site classes with something like filter(lambda x: isinstance(x, Site), infobrowser.__dict__.values()) Then, for each site, create the album and artist info actions, probably checking if the site implements the get_x_info method first. The UI XML could be built up from a set of format strings ('<menuitem name="ViewArtistInfo%s" action="ViewArtistInfo%s"/>' % (sitename, sitename) and such) individually, then merged together.
This should probably be made into a context pane tab now.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/rhythmbox/issues/152.