Re: [Rhythmbox-devel] Session management

James Livingston wrote:
On Sun, 2006-01-22 at 12:19 +0100, Pavel Roitberg wrote:
Thomas Kirby wrote:
Are there any plans, say, to implement features such as preserving the current song and play queue from one session to the next?

Current cvs saves the play queue between sessions. Saving the playing sound wouldn't be that hard, however it wouldn't really makes sense unless we also saved the playing source and it's state.

yeah, or remembering the current search term.
I used to have a cool player who did that, but then Linus came and was
right :D

Saving full source state has a number of issues, some technical and some to do with users.

On the technical side, there is how to store it for some sources.
Permanent source are easy, we used to have a gconf key for the library
search string. Playlists are harder since they don't have a unique
identifier (you can have two with the same name), we could store it in
the playlist.xml file, but I think that should be for playlist
definition, not random state. Other source like removable media, daap
shares and audio cds don't really lend themselves to storing state - and
I'm not even sure they should.

If we do store the search string, we should probably also store the
state of the browsers and similar things.
You could create an separate xml file containig only the state of the different sources.
In the case that the source is not available any more, you could fall back to the library and its state.

Although I personally liked the library remembering my search string, a
lot of people had problems with it. From reports, people would have used
the search box, quit RB, and the next time they loaded it they would
wonder where half their library had gone.

If we wanted to bring back storing source state, we would need to make
it more consistent, and not confuse people.
I can understand this issue, but I don't think that throwing the feature out completely was the right solution.
Simply not making it default would have been enough.

Furthermore I think that the real problem was not actual behavior, but that the people were not used to it, since session saving is not that common among WinAmp deviants.

Anyway there is a WYIWYG aim in the Gnome3 plans, which even suggest as you type saving for editors in order to get rid of the save button.


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