Re: [Rhythmbox-devel] Re: usage question

[Benjamin Otte <in7y118 public uni-hamburg de>]

I'd love to see Rb going the plugins route. There's certainly a lot of demand 
for it (lirc, album covers, visualizations, mass tagging, irc integration, 
gDesklet integration, applets, musicbrainz, ...) that shouldn't be required in 
the core. In fact Rb should support 2 types of plugins: Scripts that interact 
with the running application via a powerful IPC mechanism (not that joke that 
exists right now, I can't even write autorating scripts) and plugins that are 
loaded on demand for UI stuff (album art) or stuff integrating with the audio 
(equalizer, visualization).

However - and this comes from a GStreamer developer that maintains a heavily 
plugin based system - a system with a plugin mechanism requires a lot of 
effort. I'd expect it to require twice the effort to maintaining just a player 
with the most popular "plugins" included as options somewhere. The reason for 
this is simple: You need a well thought out interface and you need to keep 
API/ABI stability or the plugins will break randomly. Ensuring this is a bitch. 
So don't hold your breath unless some magic people show up that are willing to 
do a lot of work. :/

Benjamin



Quoting Michael Messmore <lists clearcreeksupport com>:

> Unique usage scenarios such as this are becoming somewhat of a
> reoccurring theme on this list.  Rhythmbox is a music player for people
> who listen to music, and unfortunately people listen to, store, etc.
> music in different ways.  While I agree that it would be possible to
> come up with one or two common main scenarios that would address the
> mythical average user, it seems that there are a significant number of
> users left out by this approach.  Rhythmbox is not the only piece of
> software to face this issue either, and I think some lessons can be
> learned from other projects and their approach to handling it.
> 
> I think a great example is the world of post-mozilla web browsing.  In
> the Gnome world there are three main browsers who approached this
> differently.  
> 
> Historically the first of these was Galeon.  It began lean and slick,
> but fell prey to featuritis.  It tried to be the one browser for
> everyone.  When it was time to change toolkits to Gtk2, the task of
> moving every feature was too great, it stumbled, and has all but died
> out.  
> 
> The second is Firefox (Phoenix, Firebird).  It it aimed to be lean and
> slick, but took usability as a cause and rallying point.  The difference
> here was that the authors decided to build an application towards a
> select usage scenario for the average user, but also built an extension
> architecture.  So when obscure or niche features are begged for the
> authors can say "Ummm, no.  But you can write an extension."  There is
> now a rich library of extensions to meet a variety of niche needs from
> web development to browsing pr0^h^h^hphoto galleries.  
> 
> Next the now official Gnome web browser is Epiphany.  Born out of
> Galeon, Marco sought usability with near religious fervor.  It nailed
> the average use scenario well, but completely left out niche users.
> Other than text editors I would argue that this is probably one of the
> most often replaced pieces of core Gnome software, because of this. Now,
> it also uses an extension system, and is just beginning to gather a
> collection of usable extensions, although much more difficult to install
> than Firefox's.
> 
> So what am I getting at here?  What I mean to say is that I think that
> Rhythmbox should focus on a core set of features, but find a way to
> allow users to extend the software, and share these extensions.  I think
> ideally the extension system would be done, so that extensions are
> written in a scripting language such as Python, where installation
> consists of dropping in files so as to avoid Epiphany's pitfall, but
> even compiled C extensions would be better than none.  
> 
> The cost of this would be the development time, exposing parts of
> Rhythmbox to some sort of accessible API.  The benefits would be great,
> however.  Development on Rhythmbox could continue focused, with
> extension writers addressing niche issues, and features that are
> difficult to develop "the right way" (eg. an extension for tag editing
> with a crappy UI until it can be done right).  Say an extension becomes
> surprisingly popular, or addresses an unforeseen issue.  Then it could
> be carefully implemented in core Rhythmbox.  This allows for a great
> deal of experimentation and inventiveness without risking the core
> codebase and helps to avoid the problem of Rhythmbox re-inventing itself
> once a year and spending the rest of the year trying to stabilize. 
> 
> Think of the variety of issues this could cover: portable music players,
> CD playing, Samba or NFS mounts for laptops, tag editing, file name
> based metadata, etc.  Rather than experimenting with these in core
> Rhythmbox and putting all users at risk, these could be developed and
> mature as extensions.  If later deemed useful to most, and after
> conceptionally maturing, they could then be integrated in the core
> Rhythmbox feature set.
> 
> Anyway, this is becoming somewhat of a manifesto I know, but it was an
> idea I wanted to throw out there.  I love this piece of software and
> have only love for all the hard work Colin et al have put into it.  I'll
> return to lurk mode now unless anyone has any questions about what I
> mean (which I seriously doubt).  
> 
> --Mike Messmore
> 
> 
> 
> On Thu, 2004-06-03 at 08:11, Mike Frisch wrote:
> > Aleksander Demko wrote:
> > 
> > >Is there anyway to browse a library by file system file and/or make
> > >playlists based on filesystem/directories etc?
> > >
> > >I have quite a bit of music, a lot of which is poorly ID3 tagged...
> > >
> > The latter is exactly the feature I was requesting in the thread 
> > entitled "Import into a playlist?".  I hope to implement this feature, 
> > but time is tight right now so I couldn't tell you when.  I will post to 
> > the list if I get it done.
> > 
> > Mike.
> > 
> > _______________________________________________
> > rhythmbox-devel mailing list
> > rhythmbox-devel gnome org
> > http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
> > 
> 
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel gnome org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
>