Re: [Rhythmbox-devel] Rhythmbox Elementary

[Sean McNamara <smcnam gmail com>]

Hi,

On Sun, Sep 26, 2010 at 2:19 AM, Jonathan Matthew <jonathan d14n org> wrote:
> On Fri, Sep 24, 2010 at 2:34 AM, yank memo <yankmemo gmail com> wrote:
>> Hello all,
>>
>> I am the lead developer of nautilus-elementary and now rhythm-e. First i
>> wanted to say that we've been covered by larges blogs such as omgubuntu and
>> webupd8 while we just started working/hacking on it. The screenshots you saw
>> are just a begining there's nothing achieved there, only a few hours hack.
>
> Sure, I understand that.. maybe I was a bit hasty in commenting, but I
> am concerned that you might end up simplifying a bit too much and end
> up compromising usability, particularly for new users. I generally
> like the ideas you've presented - it's hard to argue that the toolbar
> and time scale don't waste a lot of space - but I think maybe some
> things need a bit more thought.
>
>> Anyway let's talk about this project, we want to redesign rhythmbox
>> interface and give it a fresh air.
>> I don't know if u know elementary-project or nautilus-elementary. Our goal
>> is simplicity, we like clean interfaces.
>> You can find the sources code of rhythm-e here (based on last git 0.13.1)
>> : https://code.launchpad.net/~am-monkeyd/+junk/rhythm-e
>> It's just a little hack for the moment, basically 2 widgets moved in the
>> toolbar, some removed buttons (the ones around the search field) and a menu
>> with show/hide functionalities linked to the keyboard shortcut F8 (like in
>> nautilus-elementary or like any other gtk elements toolbar, statusbar...).
>> What it look like? https://dl.dropbox.com/u/4135996/scrot/0920_r1.png
>> It's missing the buttons shuffle and repeat i was thinking about putting
>> them in the status bar.
>
> Well, my plan for simplifying and cleaning up the interface involves
> removing the status bar, since it generally doesn't display anything
> interesting, so.. maybe you could rethink that.

The information in the status bar here says "528 songs, 1 day, 10
hours and 26 minutes, 2.9 GB". This particular information is
*exceedingly* useful and interesting to me many times throughout the
day as I use Rhythmbox:

1. When putting tracks on a space-limited mobile device like my phone,
I want to know how big my playlist is, or how big an album is, to plan
accordingly. I could use Nautilus, but the information is right there
in RB. Similarly for my older Cowon player that has an upper limit on
how many tracks you can store on an SD card, so I care about the
number of songs too.
2. When using a computer with RB to play music throughout a room for a
bunch of people without my constantly editing the playlist, I like to
build a nice playlist with at least enough music to cover the amount
of time I expect company to be around. A quintessential use for this
would be to play Christmas music through the living room PC while
opening presents. It'd be annoying to add up the run time of each
track in my playlist, and I don't think Nautilus provides that info
either, so being able to see how long my playlist will run without
looping is very useful to me.
3. Sometimes I am just interested how big my collection has grown over
time, how many songs I have overall, how much space music is using on
my HDD, etc. I could figure this out in the shell, but RB makes it so
easy!

My question is: if you're planning to take away the status bar,
*where* will these data (# of songs, run time, and total file size of
the current playlist or selection in the browser) be relocated? And
make sure you capture each of these fields, not just one or two of
them.

I wouldn't be opposed to having the status bar removed *if* Rhythmbox
provides an alternate, convenient way to get this information. Or you
could make an option to just hide the status bar and enable it by
default. I have a 1920x1200 and 1680x1050 screen, so a status bar
isn't hurting my vertical space at all. But losing the only source (as
far as I am aware) of this information would be unacceptable, as would
having to execute a long string of operations (clicks / keypresses)
each time I want to get this information. Regardless of how this
information is organized or where it is presented, I would like to
have the option to display this information somewhere on screen at all
times, provided the required option(s) are toggled on.

Don't forget that Rhythmbox still runs on desktops with big screens,
folks. We have a huge amount of screen real estate, more often than
not. It is extremely sub-optimal, for us, to have to click and drag
and press keys to view information that could just as easily be thrown
onto the screen at all times. The bigger your screen, the more info
can be fitted onto the screen at all times. It's all well and good to
design a Rhythmbox UI that fits within the constraints of <= 1024x768
and appeals to new users, but I'd like to continue to use the full-fat
UI while being able to receive updates to the core plugins, audio
engine, etc. So that basically means I want to continue to use
mainline Rhythmbox, and if I have to apply patches or other hacks to
keep the UI the way I want it (i.e., the way it currently is), that
would be bad.

I wouldn't consider myself an advanced user of Rhythmbox; I don't use
any of the PMP functions, nor do I build complex playlist
arrangements, use podcasts, or buy music from the online stores
plugins. I load my music onto my computer in a single folder (the
library folder), and play music usually by album sequentially using
the search function to restrict what tracks are looped. I use a plugin
I developed (rbpitch) to change the pitch/tempo sometimes, but that's
not a very complex function either. But -- I have been using Rhythmbox
as my main music player since about 2006, and I'm actually a bit
curmudgeon-y and resistant to change when it comes to changing up the
Rhythmbox UI. I like it how it is. Really, I do. :)

Thanks,

Sean

>
>>The entries for icon plugins actions are still there
>> in the right of the toolbar and on the left of the search input (for the
>> search related ones) .
>
> Generally I don't think plugin and source actions belong in the
> toolbar. The toolbar, and in general everything above the search bar
> and the source list, relates to the current playing track, not the
> selected source, so things like 'eject this CD' or 'sync this media
> player' don't belong there. The audioscrobbler 'ban' and 'love'
> buttons probably do belong there, though, so we still need to provide
> the option of adding buttons to the toolbar.
>
>> My screenshot is a bit outdated like we use some ubuntu patchs for
>> play/pause button for example, i don't understand why it's not merged yet by
>> the way? do you find a combined button play/pause useless?
>>
>> Our objectives:
>>
>> cleaning up the interface:  there's many vertical pixels wasted actually in
>> rhythmbox, the timescale occupy too much space. The search row dis-align
>> completely the other widgets (sidebar, browse panel, extra right panel).
>
> I'm not sure what you mean by that.
>
>>The
>> toolbar is used for only a few buttons there's many free space in it, let's
>> take advantage of it, a timescale and the search can occupy this space
>> easily. We don't need a time scale which occupy all the width of the window.
>
> Your changes so far don't allocate enough space for the time scale and
> the playing track information. The track information in your
> screenshots is ellipsized, which is unacceptable except for really
> long track names.
>
>> The buttons arround the search field are pretty useless if you use the
>> browser mode, let's keep things simple for the users with a simple search
>> input if they want to filter more they can use the browse panel or we can
>> make the search engine a little smarter too with some keyword.
>
> I don't think you can say 'just use the browser instead'. If my artist
> browser has a few thousand entries in it, searching it visually is
> difficult and time consuming.
>
> Replacing the search types with 'some keyword' is probably going to
> introduce discoverability problems. Maybe the search types would work
> as a drop down menu attached to the search box?
>
>> The browser
>> panel (albums / genre) are not adapted to wide screens, we can save many
>> wasted space by placing this panel vertically instead of the actual
>> horizontal mode.
>
> I'm not sure about this, but it might work out. Shouldn't be very hard
> to do either.
>
>> a compact menu to replace the menubar when hidded
>> an icon view for covert/album art: there's an excellent plugin which was
>> released a few days ago, rhythmarty. It can be an excellent candidate to
>> this UI revamp, i already contacted its developer and he's interested too to
>> work on this project.
>> a clutterview (like in nautilus-elementary) : an animated view like
>> coverflow or cooliris. something like
>> this http://www.youtube.com/watch?v=yHHSOdVG2t4 , 3 modes:
>> film/grid/coverflow.
>
> I'm really not a fan of things like this - it looks nice in TV ads,
> but we don't do those anyway. We can certainly make improvements to
> make implementing these things easier, but I think alternate views
> like this belong in plugins.
>
>> give rhythmbox the ability to play video files, what about my video clips?
>> they're videos but they're music too. Of course totem/mplayer does a better
>> job playing a video but it can't search my videos by artists / genre etc and
>> propose me new related tracks.
>
> There's a lot of background work involved in making rhythmbox into
> even a bad video player, and it's not really clear to me that a video
> collection works the same way a music collection does.
>
> Anyway, I'm looking forward to seeing how your ideas work out. If you
> have any questions about how things work internally, drop by
> #rhythmbox on irc.gnome.org and I'll do my best to help you out.
> _______________________________________________
> rhythmbox-devel mailing list
> rhythmbox-devel gnome org
> http://mail.gnome.org/mailman/listinfo/rhythmbox-devel
>