Re: [Rhythmbox-devel] architecture

[Douglas McMorris <virage83 mail utexas edu>]

On Mon, 2003-08-18 at 11:09, in7y118@public.uni-hamburg.de wrote:
> 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. :)

Looks good to me.. but I'm not that familiar with how to hook in
libraries and all.  Personally I think our short term goal should be to
rewrite the db in sqlite or libgda and then implement smart playlists
using the powerful queries those would give us.

> Benjamin
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel@gnome.org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
-- 
Douglas McMorris <virage83@mail.utexas.edu>