Polishing Rhythmbox’s GUI vs. Forking

With recent news from OMG! Ubuntu regarding a fork in the Rhythmbox source code for a new project called Rhythm-e (Elementary design in mind), and the controversy or mixed reactions that this has sparked in the comments and mailing list, I’ve decided to take a deeper look at Rhythmbox and share my thoughts and suggestions.

The Elementary take on Rhythmbox that is covered at OMG! Ubuntu attempts to clean up the interface by moving and removing various parts of the default Rhythmbox player. While this can be beneficial at times, I feel that its very important to heavily consider the features that are being removed.

The Rhythm-e project is only a few days old, so I’m holding my judgement on the project for a later date. Instead, I just want to point out changes that I think could have been made before the extreme decision of forking a long standing and popular music player for Linux.

The default Rhythmbox player for Ubuntu 10.10, as pictured above, is by no means perfect, but there are plenty of little tweaks that could be performed to polish the fine details of the application without very much work. Keep in mind that these are solely my opinions and in no way do I consider them to be the only or best way of improving Rhythmbox. I simply offer them out as suggestions and examples.

I’ve taken the screenshot posted above and tweaked a few aspects to show how some spaces could be used more efficiently, thus giving Rhythmbox an overall cleaner appearance without the need to fork the entire project.

The only difference between the two is that the second mockup has a library that has been filtered enough to remove the scrollbar.

Looking closer at the images and comparing them to the original, you should note the following changes:

  • The song title, artist and album have been pulled up into the button toolbar to reduce wasted vertical space.
  • The song’s progress slider has been pulled up in-line with the textual position output to reduce wasted vertical space.
  • The Library and Store list on the left has been widened by 1 pixel and shifted left to hide the unnecessary left border. This creates a cleaner and more flush appearance.
  • The album art image holder has been scaled to take up the full available area, thus removing wasted space and padding. It may be ideal to shrink the image a bit, but keep the top of the album art flush with the list above it in order to allow the resize bar to remain clickable, but the rest of the available space should be used and not wasted.
  • The redundant spacer at the end of the “Time” category has been removed. This is most likely more of a theme problem than a Rhythmbox problem, but it does still make it look cleaner.
  • In the second mockup (short list), the scroll bars are not necessary and have been removed as usual, but the list has been widened enough to push the right border out of the window which helps create a cleaner and more flush appearance.

I also think that the status bar is a bit unnecessary by default, but have left it in the picture to show that it can still look good. If the status bar is removed, the library list should stretch to also push the bottom border out of view as the right side is in the short list mockup.

I think the menus are still relevant and useful, but with the menu bar being removed from the application window in UNE, this would only help in cleaning up the interface.

One thing that Rhythmbox could do to help ideas like Rhythm-e take hold more quickly is to make the interface more configurable by themes or manual configuration files. Allowing stylists to easily move buttons around and remove various elements could also spark new ideas on realistic was of improving Rhythmbox for everyone!

While I think its not always necessary to fork an existing project for a new idea, I also like to see the interest and efforts in making existing applications more appealing. I look forward to seeing the rests of Rhythm-e as it matures, but I’m also hoping to see better communication and collaboration to improve Rhythmbox itself.

While you’re free to take open source software and do as you please without asking questions, its just plain friendly to contribute back as a token of thanks for the work that went into it in the past. Keeping up with the mailing list, I’ve seen a few talks and suggestions back and forth, so I’m crossing my fingers that the two can work together and combine their strengths rather than simply competing separately.

Are there changes that I’ve missed? Something I’ve changed that you disagree with? Let me know in the comments!

4 thoughts on “Polishing Rhythmbox’s GUI vs. Forking”

  1. using Chromium 7 Chromium 7 on Ubuntu 10.10 Ubuntu 10.10
    Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.9 (KHTML, like Gecko) Ubuntu/10.10 Chromium/7.0.531.0 Chrome/7.0.531.0 Safari/534.9

    Hello,

    I am the developer behind nautilus-elementary and now rhythm-e. Rhythm-e is just a few hours hack for now. There’s many things to discuss the design is far from achieved and every ideas is welcome.

    Interesting article. There’s some nice ideas in there, having only the title in the toolbar and the timescale right under the toolbar sounds interesting. I still think the search input is out of place and dis-align all the others panes. A simple input search in the toolbar would be much much better.
    We should align the titlesong in the toolbar with the others elements, it would balance the design.

    ————————————————————–
    |XXX buttons Title song aligned Search input|
    ————————————————————–
    + sound button

    1. using Opera 10 Opera 10 on Ubuntu 10.10 Ubuntu 10.10
      Opera/9.80 (X11; Linux x86_64; U; Ubuntu/10.10 (maverick); en) Presto/2.6.35 Version/10.70

      The only problem I have with aligning the title song is that I find the other buttons to be very useful. Especially buttons for Last.fm and Podcasts.

      Have you considering trying to find a better location for them to preserve them? The “Create an audio CD from playlist” button doesn’t seem like one that you should be removing. Maybe just relocating.

  2. using Chromium 7 Chromium 7 on Ubuntu 10.10 Ubuntu 10.10
    Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.9 (KHTML, like Gecko) Ubuntu/10.10 Chromium/7.0.531.0 Chrome/7.0.531.0 Safari/534.9

    Don’t worry we won’t remove anything. I am only considering moving shuffle and repeat into the statusbar. Rest will stay like it is. Plugins buttons would stack like they always do.

    The screenshots you saw are very earlier state as the code present in my branch. Furthermore we certainly introduce the same toolbar editor that we have in nautilus-elementary. So you would really got control on your interface and arrange it as u wish.

    1. using Opera 10 Opera 10 on Ubuntu 10.10 Ubuntu 10.10
      Opera/9.80 (X11; Linux x86_64; U; Ubuntu/10.10 (maverick); en) Presto/2.6.35 Version/10.70

      I’m aware that this is still very early (as I tried to make apparent in the post as well), I’m just brainstorming really. šŸ˜‰

      I like the idea of the shuffle and repeat buttons moving to the status bar. I had been thinking the status bar should just be off by default, but this could bring it back to being useful.

      If you did that, I don’t see the harm in making the other buttons stack in the status bar as well. Maybe right aligned?

Leave a Reply