Re: [Rhythmbox-devel] GUI mockup... let's get this sorted once and for all

["James \"Doc\" Livingston" <doclivingston gmail com>]

On Wed, 2006-03-22 at 23:45 +0000, Gareth Murphy wrote: 
> On Thu, 2006-03-23 at 10:12 +1100, James "Doc" Livingston wrote:
> > I'm still not convinced that podcast should be part of a music player.
> > Particularly one you start getting in to these kind of things, I think
> > it would be better as a separate podcasting app.
> 
> Understandable opinion, although I think that the majority of people
> will probably disagree, including myself. Podcasting is a great new part
> of the online multimedia experience, and to not support it in an audio
> app such as rhythmbox would be like shooting yourself in the foot.

I just can't really see how podcasts are related to music players. Aside
from a lot being audio-only (although that's changing), and iTunes
originally doing it, I can't see what the connection is.

To me, the logical place to deal with podcasts is in your RSS feed
reader - it can call Totem/whatever to play the media.


> Admittedly it's going to be a nuisance to work out the gui implications
> of these new 'enhanced' podcasts, but we'll get it done, that's what
> this effort is for after all ;)

As far as I can see, the UI stuff is most of the work. Thanks to
GStreamer, we get video support fairly cheaply (probably using
BaconVideoWidget), so figuring out how it all fits into RB is what I see
as the biggest issue.


> Although I do think this discussion is getting slightly off-topic...
> Here are a few things I've been thinking for the new 'enhanced' podcasts
> in the gui:
> 
> -- We should deal with the actual podcast picture as normal album art

Makes sense to me.


> -- Video could be offloaded to Totem or the users choice of video
> player... it wouldn't be too difficult and it would save us having to
> implement video playback code and the UI enhancements to do it, which
> would be a REAL pain to do.

Thanks to GStreamer, video playback itself isn't that hard - and we
could steal/import Totem's BaconVideWidget to save rewriting stuff
ourselves.


> Back to the things which could be implemented sooner rather than later,
> you could change the icons pretty much immediately... for the library
> you could use the home icon or the home folder icon which is in the
> namin spec,

In a number of themes, the GTK_STOCK_HOME icon looks like a house, which
probably isn't the best thing to use for the library.


> for daap shares you could use the network-server icon (which
> is nicer than the current one in use, even though it is from Tango
> icons)

We currently use "gnome-fs-network" for this. When using the Tango icon
theme, that is the same icon as the icon-naming-spec's
"network-workgroup"[0] - which I don't think looks too bad.


> I've asked jimmac about using the icons and he said it should be fine.
> They were made for Banshee, which uses a MIT license but he informed me
> that it shouldn't be a problem to license them under GPL (the icons I
> assume) if need be... so we could clarify that with him and get this
> wheel moving at last?

The biggest issue with providing our own icons for this kind of thing is
that we won't automatically get the icons from the user's theme if we
override them with our own. But if we don't override them then we get
the "boring" icons.

If the icon in question isn't provided by gnome-icon-theme, but is by
some other standard, then it works nicely (as it does for media-eject),
but I'm not sure what we should do when g-i-t already provide an icon
for the purpose.


Cheers,

James "Doc" Livingston
-- 
"...And the lord said, `lo, there shall only be case or default labels
inside a switch statement'" -- MPW C error message