Re: [Rhythmbox-devel] another queue UI layout

I don't really have time to work on it for the moment but you can see on this screenshot how I tried to implement the album covers :

My arch branch :
m pavot laposte net--2004

Here is what I said on it in this mailing list the last time I have updated it :
- I now work on rhythmbox 0.9 (the 0.8 and the 0.9 versions are at the same level for the moment but I will no more update the 0.8 version)
- There are now small covers in the albums treeview (you can desactivate it in the preference dialog box)
- Rhythmbox automaticaly downloads the cover of the playing album on amazon (if no cover is found on the hard disk)
- You can download and remove covers with contextual menus in the genres/artists/albums treeview.
- If you select only one album in the album treeview, you can choose the keywords for the search on amazon.
- The covers are saved in ~/gnome2/rhythmbox/covers/ in 2 sizes : a normal size and a small size (70*70) to load them faster in the album treeview.
- A lib in lib/rb-cover.c provides some functions to manipulate the covers

If you need the space at the bottom left for the queue, it is possible to remove the currently playing album cover at this place and to only keep the album covers in the album treeview.

James Livingston a écrit :

On Sat, 2005-03-26 at 02:16 +1000, Jonathan Matthew wrote:

This turns out to be surprisingly easy.. of course, the only other GUI
programming I've done recently was with Swing, so I was expecting
some pain.

I'm in the same situation with only having used swing recently. One thing that might help was if we could partially "glade-ify" the main shell-UI. Whether this is a good idea, or would just make things more complicated I don't know, but if it didn't it would help anyone who wanted to try moving things around. Trying to understand the not-really-commented UI setup code is fairly scary the first time you look through it.

I decided not to change the colour of the text, since it's probably
impossible to pick a colour that'll actually be readable for everyone.
The text size for the artist and album is relative to the normal text
size, so if your normal text is at comfortable reading size, the smaller
text should still be readable. I'm not entirely sure this is a good
idea, though.

After playing around with it, I think I like this setup more. When I've got the queue open, it doesn't really matter about having less space for the sources list. As someone (I can't remember who, off the top of my head) mentioned one thing that you want when editing the queue is to have as much space as possible for the list of songs to choose from (library/playlist) and this variant give you more there. I don't think that not having the information from any other columns (rating, time, whetver you have displayed, etc) is really that important, but having the artist and album are good.

As to the style of the artist/album text, what you have at the moment (a
bit smaller and in italics) is fine for me.

On Fri, 2005-03-25 at 08:50 -0600, Thomas Lunde wrote:

Hm. Mostly unrelated, but I just thought of this: Months ago, there
was talk of displaying album art within the UI. The location you have
selected for the queue is used in iTunes for this art. iTunes can
switch between displaying art for the the "Now Playing" track and the
"Currently Selected" track by clicking on the title of this area
(where you have put "Queued Songs").

<and some other bits about cover-art and visualisation>

I think one of the biggest problems with the below-source-list area is that
people are wary of making a "we don't know where to put it, so here will do"
part of the UI. I think that some of the other suggestions were 1) next to
the album in the browser and 2) next to the title at the top of the window.

The former doesn't give you the art for the current song, and I can't remember
the reason for not doing the second was. If we do want to make it a
multi-purpose area probably the best thing to do would be have a submenu with
the options of what to put there (nothing, queue, cover-art, visualisation, etc).

I think one of the other arguments that came up was where to store the cover art,
a number of places being suggested.

1) in the file itself
This has several problems, notably that you can't do this with anything downloaded
from Amazon (I think it was 3 months you could keep it for). Other ones included the
fact that quite a few people don't want to have multiple copies of the image (one
per track) and that some formats don't support this. On the good side it is how iTunes
does it (so I've been told).

2) in a file in the same directory as the track (e.g. folder.png or whatever)
This is perfect for anyone who (like me) stores their music in a /Artist/Album/Track
hierarchy. This would not work *at all* for anyone who has their music in a flat

3) in a special folder (e.g. ~/.gnome2/rhythmbox/covers)
This would work under any situation, but has the problem that it is incompatible
with every other program that deal with cover art.

I don't know if did ever (or will ever) actually get sorted out properly.


James "Doc" Livingston


rhythmbox-devel mailing list
rhythmbox-devel gnome org

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