[Rhythmbox-devel] extending Rhythmbox [was Re: usage question]

[Michael Messmore <lists clearcreeksupport com>]

OK, I wrote the original plug-in suggestion, but it seems I was a bit
misunderstood.  

I don't think XMMS style plug-ins would be a good thing for Rhythmbox at
all.  I was using the term "plug-in" very loosely and did not mean
binary plug-ins ala XMMS or Netscape/Mozilla.  I was thinking more like
the ability to write Perl scripts for Gaim, or scripts for various IRC
clients.  I guess bindings would be a better term. 

But after some reading and thinking, here's what I see.  Think of each
time someone suggests "use the bonobo interface" to a feature request. 
So picture this:  A well documented bonobo interface, not only to player
functionality like Stop, Play, Next, etc. and information like currently
playing, etc. but also the ability to read and write to and from
RhythmDB.  Also, I think it would be very nice to have a UI setting
where if you put scripts in a directory you have the option to have them
run when Rhythmbox is running.  This last part is kind of "bonus" and
maybe a bit too much, but it would make running common scripts
accessible to normal users.

A few examples of how this would be handy:  
-Someone wanted to have a playlist of songs they just added (I assume,
each batch added would have its own playlist).  So rather than using
Rhythmbox's built in import functionality, they write a script that adds
a directory of files to the database and adds a playlist with the same
files.  

-Someone has a laptop that sometimes is on a network with MP3s on a
Samba share.  A script could be created to conditionally pop those files
into the database when the share is available and remove them when its
not.

-Someone wants to have a little window with album covers.

-Someone wanted to have Rhythmbox glean metadata from the filesystem
layout.  A script could be written to parse the path and plug that info
into the db.  Although I think they would be better off writing a script
to parse their filesystem layout and write the files' tags, which
wouldn't be too hard.

-A script to stick the currently playing song in a .plan file, Gaim
profile, web page, or what have you would be handy and a piece of cake.

Really a fair bit of this functionality is currently available, it's
just not documented well and it doesn't always behave nicely (ie. 
getting ratings for auto-rated songs returns 2 when Rhythmbox displays
3).  I guess I'd suggest that this should be a higher priority.  I'm
also guessing that the response would be that people need to use it and
report bugs on it/document it themselves.  Alas, you have pinpointed my
laziness ;).

Oh and to address other things:  compile time flags are not a good way
to reduce/increase functionality.  Most people just stick with the
packages their distro gave them.  And the more extreme the suggestion
that arch supplants any plug-in system is ridiculous.  Shoot, I don't
think even all the developers have moved to arch yet, let alone the
"average Rhythmbox user".  It would be pretty silly of us to put so much
work into such a usable interface, and then say that if they want to use
or remove XY or Z that they have to fetch this or that arch patchset and
recompile.  I can just picture the deer-in-headlights look now.  Arch is
good for creating a place to independently develop a feature, but with
the intention of later merging back into the main branch. In other
words, it helps on the developers end, the user doesn't care if we use
Arch, CVS, or two strings and a can.  They just want to figure out if
they can do this or if they're stuck with that.

Anyway, I'll return to listening to music and doing work now.

--Mike Messmore






On Wed, 2004-06-09 at 19:35, Ben Konrath wrote:
> I don't think that Christophe Fergea's response made it to the list, so
> my comments are interleaved without chopping.
> 
> On Tue, 2004-06-08 at 14:15, Christophe Fergeau wrote:
> > > Another reason for a plug-in system is that not all users want to use all
> > > the features. For example, I wouldn't use a visualization system if such a
> > > system were to ever make it into rhythmbox.
> > 
> > You didn't mention visualization in your examples, I was specifically
> > talking about the list that was in your mail.
> 
> It wasn't me who wrote the original mail ... I was just butting in :)
> 
> > >  Also, the plug-in system could
> > > potentially speed the development of plug-in especially if there was a
> > > scripting interface as suggested earlier.
> > 
> > A scripting interface would probably entice some people into doing some
> > cool stuff, but I don't think it would help at all with getting things
> > like audio cd support or tag editing more quickly.
> > 
> > > 
> > > Furthermore, I have noticed that Colin Walters has hinted a few times that
> > > some features in rhythmbox are motived by a need to replace XMMS. If this
> > > is the case, I believe that some sort of plug-in architecture would be
> > > required to allow the "power user" to extend rhythmbox as they feel fit.
> > > 
> > 
> > If rhythmbox UI doesn't fit people's need wrt an xmms replacement, I'm
> > not sure a plugin architecture would really help them.
> 
> You're right in that a plug-in architecture probably wouldn't help the
> UI too much. What I was really trying to say is that if XMMS replacement
> is on the agenda, the UI model that XMMS implements isn't the only thing
> that is going to be missed. The plethora of optional plug-ins available
> for XMMS is something that I would personally would miss. 
> 
> As suggested in another thread, investigating if the bonobo interface
> could be used as the plug-in interface might be worthwhile.
> 
> Cheers, Ben
> 
> 
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel gnome org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
>