I'm now showing off the fact that I don't really know how to use arch: How do you pull updates to a branch? I've gotten a directory with two subdirs in it: rhythmbox--queue--0.9--patch-4 and the equivalent to the main 0.9 devel branch. If I try `tla update` in the --patch-4 directory it says it is up to date and in the parent it isn't in the project tree. Anyone got any advice? In the mean time I just grabbed the whole thing again (--patch-9). On Wed, 2005-03-23 at 10:39 +1000, Jonathan Matthew wrote: > On Wed, Mar 23, 2005 at 03:16:25AM +1100, James Livingston wrote: > > * How do you remove stuff from the queue? They don't seem to get removed > > automatically, and right-clicking then going delete doesn't do anything. It seems to be working now. I guess it was a glitch in the matrix. > > * You can't use "previous" while in the queue. > > I couldn't think of a good way to do this. The previous entry is > (supposed to be) removed from the queue, so either the entry would have > to be re-added to the queue, or .. something. Any ideas? I suppose at > the very least, you should be able to use "previous" to go back to the > start of the playing song. Going back to the start of the song sounds like it needs to be there. I just though of another couple of what-the-hell-should-previous-do situations as well, nothing to do with the queue. What if you are playing a song from playlist A, then play a song from playlist B and click on previous? It seems obvious it should play the first song, but should it change the selected source to playlist A (I can see points for and against here)? I checked what Rhythmbox does in this situation, and it simply keeps on going back to the start of the curent song, not letting you go back. I don't actually know what it should do in situations like this (not letting you do it seems as good as anything I suppose); I'm sure there are more similar situations people can think of. What is possibly a solution is to have (if it doesn't already) a global (not queue related) list of the last N songs played, which would be selected by using the previous button. Actually displaying the list to the user (as a "history" part of the queue or whatever) would be seperate. Possible weirdness shows up if you are playing from the "history" and choose to play a different song (either via the queue which would be more hairy, or by double clicking). I suppose in some ways it's similar to the go-back-in-time-and-change-things paradox, but with music instead of reality. For simple situations the previous button makes sense. Creating a small and consistant list of what it does in complex situations, without heaps of exceptions for corner cases, could be fairly difficult. I'll be buggered if I can. > > * When playing from the queue the "Currently Playing" icon is next to > > the one in the queue (good) but it also stays next to the one in the old > > playlist/library. > > I've made a few changes in the vague hope of getting this right. It's > closer, but not entirely there. This was one of those not-really-important things when you keep on noticing that something doesn't look right, it looks fine to me now though. > > * On mine it shows the (N entries) bit when closed and doesn't when > > open, which seems backwards > > I don't know why I did that. Always showing the queue size seems > reasonable to me. Okay, I've just realised I got horrible confused and written that backwards. This is what happened when you edit a sentence and don't invert all of the words. What it should have said was it told you when it was open (and could see how many things were in the list) which is okay, but didn't show you when it was closed. The current version displays it all the time, which is good, but "show queue" and "hide queue" still are backwards. Also putting the rest of what you had in the status bar there as well (either in the same place), or over to the right would probably be good; I can't see what else you'd use the space for, unless you put both disclosure triangle on the same line like Peter was suggesting. A couple of things I noticed when play around with it (mostly trying to break things by playing around with adding things and the next button). 1) You can't double click on a queue entry to start playing it. You might want this if you have one song in the queue playing, and decide you want another in the queue to go first. Also my default behaviour to add things to the queue then play them is to add a couple of songs and then double click on the first one, rather than adding them and then pressing next/play. 2) Pressing Next while play a not-last song from the queue doesn't remove it, this behaviour is fine for me (other people may think differently), but leads to the next one: 2+) If you have two songs in the queue, the first one playing and you press next it will go to the second song (correctly) but once the second song finishes normally it plays from the currently selected source and doesn't remove the song from the queue. a) Should it play from the current Source, or go to the top of the queue. I'd be tempted to say the latter, because in the current situation it will play from there after one non-queue song has played anyway. b) The second song isn't removed. 3) The queue displays the same columns as the main library/playlist (as set in the preferences) but doesn't use the same widths. On one hand I'd expect it to use whatever I have in the main bit by default, but on the other hand some people may want to change them separately (I don't, but it would be more annoying for them if you couldn't). Also a bug report for the 0.9 devel branch (it occurs with the non-queue version too): about 50% of the time Rhythmbox will crash after it has finished refreshing the library. It never crashes while running under gdb however (making getting a backtrace more difficult), I'll see if I can get one tonight. James "Doc" Livingston -- "Never be afraid to tell the world who you are." -- Anonymous
Attachment:
signature.asc
Description: This is a digitally signed message part