Re: [Rhythmbox-devel] Bugzilla Roundup #1 (Fuzzy Matching and Tray Icons)



On Tue, Oct 25, 2005 at 06:13:30PM +1100, James Livingston wrote:
> 
> In regards to the issue of whether we should have a permanent tray icon,
> the HIG[0] explicitly says that non-core application must not default to
> having a permanent tray icon. One option is to add a "show tray icon"
> preference, and have it default to off. Another option would be to work
> with the developer(s) of the Rhythmbox applet, and promote it to an
> official part of Rhythmbox (removing the tray icon in the process).

As the developer(s) of Rhythmbox Applet, I've been considering the
opposite approach: split Rhythmbox into two separate programs: a backend
server and a GUI.

The backend server would handle managing the music library, playlists,
and music playback.  It wouldn't have a user-visible interface, but
would communicate with other applications over D-Bus.

The GUI as we know it today would then become just another client of the
backend's D-Bus interface, just as Rhythmbox Applet is now.  The user
could then use the "official" Rhythmbox GUI, the applet, or some other
program to control the backend server, which would be completely
invisible --- the user would just notice that the official GUI, the
applet, and so on would all have the same view of his music library.

One possible problem with this decoupled approach is, what happens if
the backend is playing and all clients are closed?  If you keep playing,
then the user has no obvious way to stop that --- it's hardly intuitive
to start a new program to stop something from running.  You may need to
keep *something* around that the user can see.  Unless you have the last
client stop playback before it terminates.

And if you really want to run with this, why should the Rhythmbox
backend be responsible for managing the local music library?  What if
the backend just relied on Beagle to index the local music collection
and queried that as necessary?  Then the backend only needs to keep
track of what sources of music are available: local disks via Beagle,
music shares via DAAP, radio streams via HTTP, portable media players
via HAL, etc.  And building playlists, of course.

(Disclaimer: My only experience with Beagle comes from looking at its
web page.  I have no idea if using Beagle for the local music library is
desirable, let alone feasible.)

Attachment: signature.asc
Description: Digital signature



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]