After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 331250 - Add "lookup on last.fm/google music/wikipedia/allmusic plugin"
Add "lookup on last.fm/google music/wikipedia/allmusic plugin"
Status: RESOLVED OBSOLETE
Product: rhythmbox
Classification: Other
Component: last.fm
0.9.x
Other Linux
: Normal enhancement
: ---
Assigned To: RhythmBox Maintainers
RhythmBox Maintainers
: 317517 324178 337051 409166 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-02-15 08:59 UTC by lexual
Modified: 2018-05-24 11:25 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Plugin desktop file (223 bytes, text/plain)
2006-04-24 10:37 UTC, Alex Lancaster
  Details
Initial attempt a plugin (4.38 KB, text/plain)
2006-04-24 10:39 UTC, Alex Lancaster
  Details
Fixed a typo (4.36 KB, text/plain)
2006-04-24 10:56 UTC, Alex Lancaster
  Details
Updated: handle albums (6.48 KB, text/plain)
2006-04-24 13:02 UTC, Alex Lancaster
  Details
Added Discogs (6.61 KB, text/plain)
2006-04-26 12:10 UTC, Alex Lancaster
  Details
Submenus, Link updates, -ui.xml file (12.56 KB, patch)
2007-12-18 06:05 UTC, John Daiker
needs-work Details | Review
A rework as per previous comments (121.35 KB, patch)
2008-06-20 01:45 UTC, John Daiker
needs-work Details | Review
Removed cruft from old files, and removed commented code, also (16.68 KB, patch)
2008-06-20 20:20 UTC, John Daiker
none Details | Review

Description lexual 2006-02-15 08:59:40 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.
Comment 1 Alex Lancaster 2006-02-15 09:14:17 UTC
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.
Comment 2 Alex Lancaster 2006-02-18 17:42:18 UTC
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.


Comment 3 James "Doc" Livingston 2006-03-20 07:34:08 UTC
The links have been removed from cvs, but this could be implemented as a plugin. Retitling to reflect that.
Comment 4 Alex Lancaster 2006-03-20 09:15:08 UTC
*** Bug 324178 has been marked as a duplicate of this bug. ***
Comment 5 James "Doc" Livingston 2006-03-20 10:46:34 UTC
*** Bug 317517 has been marked as a duplicate of this bug. ***
Comment 6 James "Doc" Livingston 2006-03-20 11:00:41 UTC
From bug 317517: it would also be good to offer links for all songs, not just the currently playing one.
Comment 7 Alex Lancaster 2006-04-04 03:01:23 UTC
*** Bug 337051 has been marked as a duplicate of this bug. ***
Comment 8 Alex Lancaster 2006-04-04 03:03:23 UTC
Bug 337051 suggests linking to search page, because of the lack of canonical names for artists/tracks/albums.
Comment 9 Alex Lancaster 2006-04-24 10:37:13 UTC
Created attachment 64189 [details]
Plugin desktop file

Adding an initial desktop file for Python plugin
Comment 10 Alex Lancaster 2006-04-24 10:39:20 UTC
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/
Comment 11 Alex Lancaster 2006-04-24 10:41:51 UTC
Currently it adds an "Artist Info" at the end of library pop-up menu.
Comment 12 Alex Lancaster 2006-04-24 10:56:25 UTC
Created attachment 64191 [details]
Fixed a typo
Comment 13 Alex Lancaster 2006-04-24 11:10:42 UTC
This requires HEAD as 2006-04-23 (which is after 0.9.4).
Comment 14 Alex Lancaster 2006-04-24 11:22:09 UTC
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)
Comment 15 Alex Lancaster 2006-04-24 13:02:46 UTC
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.
Comment 16 Alex Lancaster 2006-04-26 12:10:30 UTC
Created attachment 64317 [details]
Added Discogs
Comment 17 John Daiker 2006-05-09 17:48:55 UTC
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.
Comment 18 Alex Lancaster 2006-05-10 13:22:11 UTC
(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.

Comment 19 John Daiker 2006-05-10 22:08:10 UTC
(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).
Comment 20 Alex Lancaster 2006-05-18 07:03:51 UTC
(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? ;-) 

Comment 21 John Daiker 2007-12-18 06:05:19 UTC
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
Comment 22 John Daiker 2008-01-08 18:34:04 UTC
Ping?
Comment 23 Jonathan Matthew 2008-02-13 12:40:05 UTC
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.

Comment 24 John Daiker 2008-06-20 01:45:48 UTC
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.
Comment 25 Jonathan Matthew 2008-06-20 14:59:22 UTC
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).
Comment 26 John Daiker 2008-06-20 19:03:49 UTC
(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

Comment 27 John Daiker 2008-06-20 20:20:25 UTC
Created attachment 113144 [details] [review]
Removed cruft from old files, and removed commented code, also
Comment 28 Jonathan Matthew 2008-06-26 13:12:49 UTC
*** Bug 409166 has been marked as a duplicate of this bug. ***
Comment 29 Jonathan Matthew 2008-06-28 05:14:50 UTC
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.

Comment 30 Jonathan Matthew 2009-12-28 04:39:45 UTC
This should probably be made into a context pane tab now.
Comment 31 GNOME Infrastructure Team 2018-05-24 11:25:01 UTC
-- 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.