[Rhythmbox-devel] architecture

[in7y118 public uni-hamburg de]

Hi people,

We all know that I'm the one who's the loudest in complaining about Rhythmbox's 
code - architecture, organization and documentation.
So I thought I'll just go ahead and post my thoughts about how I want it to 
look. I'm fully aware that this might be very ambitious and maybe some things 
are not even needed, but I'm one of those "do it right" guys.

So, now, ph34r my 1337 ascii skills.

+-------------+ +---------------+
|libgda/sqlite| |GStreamer/Xine?|
+-------------+ +---------------+
       ||              ||
+-------------------------------+       +---------------+
|                               |       |               |
|        librhythmbox           | = = = |   other apps  |
|                               |       |               |
+-------------------------------+       | (applet,      |
        ||           ||      ||         |  rb-script,   |
+----------------+   ||   +-----+       |  ...)         |
|                |========|     |       |               |
| librhythmboxui |   ||   |  P  | = ? = |  bonobo ?     |
|                |  +-----+  L  |       |               |
+----------------+  |     .  U  |       +---------------+
        ||          |     .  G  |
+-------------------+     .  I  |
|                         .  N  |
|     Rhythmbox           .  S  |
|                         .     |
+-------------------------------+

And now I'll explain things a bit :)

1) librhythmbox

We all remember from our CS classes, that you should seperate the backend from 
the UI. This is the backend. It is one big media organization library. It 
handles playback, playlists, smart playlists, what have you. It completely 
abstracts the media framework and playlist organization.
And on top of that there's multiple ways to get access to the library: You can 
access a library directly, via Bonobo/D-BUS - or maybe even via some custom 
protocol to browse other peoples playlists? 
On the negative side this means that every function that this library exports 
must be handled by the remote (Bonobo or D-BUS) backend, too.
Oh, and the whole stuff would have to be gtk-doc documented as an added bonus 
for our coders.

2) librhythmboxui

This is a place for two things:
- widgets for librhythmbox
They would be used in Rhythmbox, but might be useful for other apps who want to 
use librhythmbox, too. (ideas: RbButtonList - the buttons top left, useful for 
the applet; RbCurrentTitle - label displaying the current title)
- hooks for plugins
Predefined ways for plugins to hook into Rhythmbox (idea: 
rb_properties_add_page for a musicbrainz plugin)
Maybe I'D want to split this, I don't know.

3) Rhythmbox

This is just the glue that puts together the UI to control the backend, loads 
plugins and does all the stuff that is needed to have a media player.

4) Plugins

Plugins seem to be useful stuff for me, because there's a lot of extensions in 
current Rhythmbox that are only marginally useful. And on top of that there are 
many parts of the code which should just coexist but not interact directly, 
which can easily be achieved with plugins.
Examples of plugins: Bonobo backend, mmkeys, cd burning, export to 
$EXTREMELY_COOL_FORMAT

5) other apps

This would be apps that are external to Rhythmbox but want to interfere with 
it. This would include a command line scripting tool (#> rb-remote --next), an 
applet, a GKrellm plugin or whatnot.

Now, at the end I'm just going to pull some pseudo-code from nowhere, just to 
show you how I imagine doing this:
/**
 * Open a remote connection to rhythmbox, start playing, exit
 */
int main ()
{
  /* open connection to library backend */
  RbLibrary *lib = rb_library_connect_bonobo ();
  if (!lib) return -1;
  /* set to play */
  rb_library_play (lib);
  /* close connection */
  g_object_unref (G_OBJECT (lib));

  return 0;
}

And now I'm expecting to get evil laughs from most of you and a "too hard" from 
the rest ;)
And then you'll actually tell me how you'd like the code to be reworked. :)


Benjamin