Latest revision as of 19:03, 10 January 2013

New Playlist Wizard

The above are the four steps of the wizard. The idea is that the wizard would only show the first and then the appropriate last step. The crucial change in the Smart playlist creation dialog is that the Match... section now uses a checkable frame. This is unfortunately not available in KDE 3.2, but since this wouldn't go into amaroK until 1.3 anyway, I think we'd be safe :)

My feelings on this are that are a wizard is a little too much work for the user. Still try it and we'll see. I'd think a simple toolbar button with drop down to make a new playlist and then using drag and drop would be quicker while still being easy and, of course, more amaroK-like. Good ideas here though Mxcl

I suppose you could make it not a wizard, but a more specialised interface... Make the three radio buttons into proper buttons, in turn showing a new dialog and not another step in a wizard... That way we could actually combine your idea with this, have a single click spawn the dialog with descriptions and the three options, then have a combo buttons allowing you to make each of the three directly :) --Leinir 09:58, 15 Mar 2005 (EST)

Well then you are compromising such that the approach is half-hearted and not an improvement. I think the best approach is both a wizard and a drag and drop system.

Good call :) (I don't really like the second option I suggested either, I just thougt I'd do brainstorm and toss out the idea so it didn't get completely lost) --Leinir 19:52, 18 Mar 2005 (EST)

Playlist Browser

The idea is to utilise the greatness that is KNewHotStuff for getting our things, but do it without the user interface. While that is all good, it does not really suit our purposes too well. I've not looked into it very deeply at all, but it seems that it does what we want: Update the streams browser from a central repository of some sort, but not hammer the server (like e.g. iTunes does (it updates the streams list each time you collapse and expand the tree)). This is of course all just speculation since I won't be the one implementing it, but that's my thougts so far anyway :)

   Simple suggestion, to avoid hammering servers, why not implement using http and if-modified-since, or some sort of rsync-like protocol? Quinn

Good ideas :) Mxcl

Update: Thanks to Cozy who last night did a neat bit of work looking at precedence in the field of Shoutcast usage, it seems that there's not actually any problem parsing Shoutcast, we simply cannot hammer the shoutcast server from one IP (i.e. like I suggested above), but in stead we hammer the server from multipple IPs (i.e. from each client), and they seem to be fine with this. Essentially, of course, that's just browsing it like you normally would, just with a more friendly, non-webified user interface. So, go Nullsoft for taking the decision for us ;) --Leinir 09:52, 15 Mar 2005 (EST)

Ideas continued ;) The playlists browser itself should be refactored, so that the only thing it knows itself is that it has x entries, of a random type of playlist, then drop-in functions are provided to get the information about those playlists, where they are saved and such is not the realm of the browser, it simply asks these functions for information. Children are only recieved when the parent is expanded, so as not to churn too much on the database (or load too much info from the net, and also to be as up to date as possible). Each type of playlist has a root of it's own, so that we have (from the top down) Playlists, Smart Playlists, Internet Radio, Podcasts (thanks |Zekant for that one) --Leinir 14:12, 9 Apr 2005 (EDT)

This could easily have podcasts as well (essentially a RSS arregator for media files, and full of buzz-wordiness) --Eean 00:49, 10 Apr 2005 (EDT)

Another idea

sebr: I came up with a new idea for the playlist browser, which also incorporates party mode. This would also allow the user to save stream sources, etc:

animefan: The new part on the mockup looks static to me and I don't think it's a good idea to waste so much space. Consider running not fullscreen. I don't want to see it all the time. Additionaly it's not quite clear which playlist-properties you're seeing/editing. BTW: I would still prefer to see the playlists and the collection incorporated into one view... Putting the party mode there would make sense. Some of the various options related to the party mode don't seem very important to be shown in the browser, perhaps they could be moved into a seperate options dialog. --Eean 14:53, 4 May 2005 (EDT)

oggb4mp3: A few more ideas for the playlist browser

a button to launch the users last.fm stream. This requires authentication, but uses the users audioscrobbler login, which is already present in the config dialog, so no additional configuration options will be needed. The last.fm web service is documented here.

sebr: This could be a default Stream? Would be awesome.

have the party mode config open automatically when party mode is enabled, since the user will probably want to configure party mode if they enable it.

sebr: Okay, this has been implemented into amaroK-SVN. It looks slightly different to the screenshot show, go to this image for a more up to date image. Party dialog has been reduced in size substantially, and it is possible to hide/show the dialog with the click of a button. It is still really important to deal with the issues of party mode, so please try it out and provide feedback!