Re: [Rhythmbox-devel] Patches for discussion

On Wed, 22 Feb 2006 00:22:10 +1100
James Livingston <doclivingston gmail com> wrote:


just wanted to feedback on this really quick.

> Restore visibility on startup
> (bug 127320)
> Currently when Rhythmbox starts up it always starts visible. This bug
> is asking that RB remembers whether it was visible, and start in the
> tray if it was like that when the user quit last time.
> The patch implements this, but the question is do we want to do it? My
> main concern is that people may minimise RB to the tray and log off;
> when they start up and load RB again, they may wonder why it isn't
> showing up.

Generally a nice idea, and understandable. However, my concern is that,
even though I love Linux for its stability and all, every once in a
while an application like the system tray crashes, not alwys restoring
all icons when restarted. Some window managers don't even have a system
tray (yeah, I know that in these WMs RB wouldn't get minimized anyway,
but what if ppl use different WMs depending on what they intend to do?)

What I'm saying is that if you minimize RB and - for whatever reason -
lose your system tray icon, you need to be able to see the main window
by restarting RB. So, if this gets implemented, there needs to be at
least a command line option for explicitly showing the main window.

> Plugin Manager UI
> (from bug 330523)
> The base plugin framework (based on gedit and Epiphany) is mostly
> done, and the biggest remaining piece is the plugin manager UI. The
> current version of the patch adds a Edit->Plugins menu item, which
> brings up a list of plugins, with checkboxes, an About button and a
> Configure button (like Gedit).
> Should we use that, or change to something like Banshee and amaroK,
> which has the list of the left, and the configuration page on the
> right?
> While Banshee's probably looks a bit nicer, it has a downside: it
> requires loading all the plugins into memory, even when they are
> disabled, and the gedit-style one doesn't.
> This has a much bigger effect with non-C plugins. If you have *any*
> Python plugin installed, it will force the Python runtime to be
> loaded, even if you have the plugins disabled. This would be even
> worse if we added support for more plugin language bindings.

I like the database idea, where a short description of the plugin is
provided in a simple text file. Using the gedit layout, how about
showing the description as a tooltip?

> Library Location selection UI
> (from bug 328414)
> Currently we are using a file selection drop-menu to choose the
> library location in the preferences. This has a number of issues,
> both those outlined on the bug and others, which mean we probably
> need to change.
> The patch on the bug turns it into a text entry with the path/uri,
> and a "browse" button (like in the druid). The two questions are:
> a) what do people think of that, or is there a nicer UI that works?
> b) would adding a "additional library locations" button be useful or
> confusing

I love the library! Especially the watching feature! (Just wanted to
say that out loud right now.) There are times when it'd be good to
have multiple Library locations. For example in an environment, where
there's a global music location for all users' music plus a private
location for a user's own music. Then again, you could solve the
problem by creating a pseudo-library-location with links to the
different directories containing the music.

Heads up,
-karsten schmiedecke

\ /     ASCII Ribbon Campaign
 X   against HTML email & vCards
/ \   Visit

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