Re: [Rhythmbox-devel] New plugin: Pitch/Speed Shifting

[Jonathan Matthew <jonathan d14n org>]

On Wed, Oct 28, 2009 at 12:42 AM, Sean McNamara <smcnam gmail com> wrote:

[ignoring specifics of this plugin, at least for now]

> ***I am soliciting community feedback on this plugin!*** I personally
> find it very useful, but eventually I'd like to have it become part of
> Rhythmbox proper, as an official plugin bundled with the stable
> release. This greatly simplifies the installation procedure, and
> increases the chance that distros will pick it up. If any of the
> Rhythmbox maintainers read this message, please carefully consider the
> next two paragraphs before deciding whether to pick this up as an
> official plugin.

okay!

> Now that I am happy with the functionality of the plugin, my new goal
> is to help it reach the largest audience possible. I have chosen the
> most favorable license possible by using the same one as the Rhythmbox
> core, and I offer my help and perpetual maintainership of this plugin.
> The RB maintainers can choose to help me reach the largest audience
> possible, or not -- either way, I am still happy using the plugin
> myself. I do believe it is of some general use, and there is precedent
> for other media players including this functionality by default.

Of course, that's one of the motivations for incorporating a plugin
system into an application. It doesn't seem like we're doing a great
job of it, though, considering how rarely we add new plugins.

The limiting factors with regard to adding new plugins are general
utility - how many people would use it?; discoverability - how would
they figure out how to use it?; and UI clutter - does adding this
plugin degrade usability by adding more UI elements and extending the
plugin list?

For things like media player device plugins, the answers are simple
and positive - anyone who owns one would likely use the plugin; it
appears in the source list when you connect the device, so discovery
is easy; and they're usually grouped together in the plugin list,
making it easy to skip them all if that's not what you're after.

For plugins that don't really map directly to a particular user goal
(such as 'copy music onto my ipod'), it's not quite so easy. It's hard
to estimate how many people would use such a plugin, since it could
lend itself to any number of uses; discoverability depends on adding
elements to the user interface, which has an impact on overall
usability; and it's generally harder to make the connection from 'I
want to do this thing with my music' to 'maybe there's a plugin that
will help me' to 'this is the plugin I need', and the last step gets
harder as we add more plugins, since we present plugins in a single
list, sorted by name.

The wiki page we use as a free-form overflow list doesn't really help,
given that (I assume) very few users would be aware of it or have the
knowledge and motivation to download and install plugins from some
stranger's website.

Anyway, the point I'm getting to here is that the current plugin
situation is lacking in a couple of ways that limits our ability to
adopt new plugins.
- the plugin selection UI scales poorly; we could improve this by
splitting it into sections (devices, online services, desktop, ...)
and making it more task focused - one mode for configuring or
disabling plugins, another for enabling new plugins, perhaps.
- I don't think the options for plugins adding elements to the UI are
good enough; it's crucial that plugins be able to integrate into the
UI thoroughly, because what's the point in adding new features if you
can't access them? I don't have any real ideas for fixing this.

>
> As a completely separate issue, I observe that there is currently no
> way to build an out-of-tree Rhythmbox plugin written in C or Vala. Has
> anyone thought about making a rhythmbox-devel package (which, for the
> rb sources, entails writing a pkgconfig file and shipping headers into
> /usr/include/rhythmbox) so that plugins can be developed out-of-tree?

It's not something I'm opposed to at all, it's just not a high
priority. We'd want to make it clear exactly what the intended use
cases are. I think the main aim would be to allow development of
external plugins, and to allow users to build those plugins for
themselves, both without having to build all of rhythmbox. I wouldn't
like to see people distributing binaries of external plugins.

I haven't thought about this a great deal, but the work involved seems to be:
- classify headers into 'plugin API' and 'internal', modify makefiles
to install the plugin API headers
- ensure no plugin API headers include internal headers (especially
things like config.h)
- set up a plugin API version header that external plugins can use to
determine if they work with the version of rhythmbox they're being
built against
- start versioning librhythmbox-core properly

The last item looks like a job for a maintainer, but the rest can be
done by any interested party. Of course there may be more to it than I
realise..