[Playlist Perspective] New Perspective

OK and the playlist repository view shoul dbe refactored into a tree o playlists

o smarts

o new... o Best of

o Favourites albums/genre/artists/year o ...

o podcasts o web radios o Normal playlists

o playlist 1.m3u ...

On pod casts, I agree they should be taken as playslists. However, I feel that webradios should be conciderated as devices indead (not sure)

(ticket cleaning, wrong version)

Well, this is now a priority in summertime to fully refactor the playlist features. Related tickets: #852, #918

Here's finally what I plan to implement (please argue ASAP if you don't agree) :

• Playlist editor becomes "Queue view" and is no more linked with playlists in any way. Its behavior may change to avoid voiding it when stopping (to be digged)

• New perspective: Playlist that contains following views: ** A new view : "playlist table" that shows all physical playlist in a table and logical playlist when checking a "hide duplicate" button. It contains as well 4 big buttons upon the table for smart playlists" : bestof, newest, new and bookmark. ** The playlist editor is somewhat the current one, still connected with playlist tables and smart playlist view (instead of playlist repository). A auto-completable combo allow fast access to smart and regular playlists. ** If we have time, we'll add new podcast and radio views as suggest on this ticket

Logical playlists feature is still in the engine but removed from documentation and user visibility.

Hi Bertrand, Have you started working on this? Could you please tell me how exactly you are planning to work on this.. so that I can also help you.

Hi Varun,

No I didn't begin to work on it and I finally suggest a little change on my own proposal : implement a single view for playlist table and playlist editor (a two-tables view actually) and not two that makes the whole thing much more complex. I think about a two panes view with:

• On the left the playlist table (list all physical playlists) + a checkbox button to hide/dhow duplicates (actually it makes the table switch from physical to logical playlists) + the 4 buttons for smart playlist bestof/newest/new/bookmark
• On the right, the playlist editor (the current one). Of course selecting a playlist on the table or clicking on one if the smart playlists synchronize the right pane with its content.

What do you think ?

Replying to fsck222: Oops, sorry Alexis, I unfortunately deleted your comment

Replying to bflorat:

Hi Varun, No I didn't begin to work on it and I finally suggest a little change on my own proposal : implement a single view for playlist table and playlist editor (a two-tables view actually) and not two that makes the whole thing much more complex. I think about a two panes view with: * On the left the playlist table (list all physical playlists) + a checkbox button to hide/dhow duplicates (actually it makes the table switch from physical to logical playlists) + the 4 buttons for smart playlist bestof/newest/new/bookmark * On the right, the playlist editor (the current one). Of course selecting a playlist on the table or clicking on one if the smart playlists synchronize the right pane with its content. What do you think ?

I like the idea but how about top/bottom panes rather than left/right.. that way I feel we will have more width to display the song/album details in the table. We can have buttons at the top to switch between playlists.. or we can actually make them two independent views so that users can move them easily and place them wherever they want.

In any case could you please create a structure of classes/methods required which I can start implementing. Are you planning to use the existing playlist editor code + the buttons that we have on the top of playlist editor for save, clear, moving tracks, prepare party etc.

+1 for the idea of horizontal splitting. I really think we should make a single view. It would really ease the developpement and the overall result : - The size of this view is not a problem because we create a new perspective to it - Two views are complex. For ie, to manage because user can display only one from any perspective and then, we have to synchronize the views of the same perspective.

Anyway, I do think we should design the GUI of this view so it can easily be splitted into two views if required. For instance, simply use SplitPane? (at 50 or 60 % of height) to separate the two parts of the view.

What do you plan for smart buttons ? I see this :

<pre> O Show duplicates [New] [Bestof] [Newest] [Bookmark] filter: [combo] contains [ ] (keep code from AlbumTableview? for ie) ... playlist table (the "show duplicates" checkbox switch from physical to logical playlist list) _Split pane_ <current playlist editor buttons and label, no changes> <playlist detail (current behavior>> _ </pre>

On prepare party button, I think it should be availble on any (smart or normal) playlist, shouldn't it ?

On the Playlist view: I suggest to subclass it to a new "QueueView?" without:

• label "Queue"
• prepare party
• Play
• Delete

(think about an elegant way to make buttons and label optional in PlaylistEditorView? and QueueView?)

OK, if you want to implement this (please affect the task to yourself. I let you create classes: Please: - Rename the PlaylistEditorView? PlaylistView? - in org.jajuk.ui.views, create a QueueView? that extends PlaylistView? - Create a new "Playlists" perspective class in org.jajuk.ui.perspectives - Remove playlist repository view and all related code (synchronization events between repository and edition views for ie) - Update the exisiting perspective XML files (playlist editor -> Queue View, remove playlist repository) - Create the perspective XML conf file in src/resources/perspectives

Check AlbumTableView? and AlbumModel? classes to write the playlist list code, it should be pretty near and simpler.

Don't hesitate to ask by e-mail or Jabber.

Well, here's a better preview: see attached file

Hi Bertrand, this looks bit confusing to me. Could you please create blank classes/methods first whcih I will start implementing. I guess you already know what exactly needs to be done.. so I guess you can do it faster and more efficiently.. I will have to read up some examples for split panes etc before starting.. Once I see the outline structure, I can slowly build on that.

Well, I'm pretty busy this week, I'll try to make it this week end. Please look at the others tickets I assigned you at the mean time if you wish.

Hi Bertrand, any progress with this. I am getting bit impatient 8-)

Actually, I already spent many hours on it and it runs now but it's a large and pretty complex commit so I want to make sure everything's all right as it impacts many classes. I plan to commit this tonight or tomorrow. Note that even if I probably made the most complex part of the job, the remaining part is still difficult so I could work with you on it if required. In the mean time, I try to make the code clear for you.

I finally commited my playlist GUI refactoring. Among many others things, PlaylistEditorView? has been splitted into new views: QueueView? and PlaylistView? and PlaylistRepository? views (Logical and Physical) have been dropped. Overall architecture has been simplified and some events like EVENt_PLAYLIST_REFRESH have been dropped.

What still to do is to implement the new PlaylistView? as described below. Note that it is a pretty complex task so please don't hesitate to ask and I may work with you on it.

My TODO list :

• To simplify the design, I assume that the playlist editor (for normal or smart playlists) is not refreshed externally. for ie, if user display several Playlist views and change a playlist, the same playlist in another Playlist view has not to be updated (user can work on it and we don't want to change the playlist content externally). To refresh it, user can simply select another playlist in the playlist table and come back on the previous one.

• Some thing for the playlist table is a playlist is deleted (from the files tree view for ie) : user can still view and edit it.

• For playlist table labels, reuse labels from PhysicalPlaylistRepositoryView?, I dropped some others. Don't create new labels if not required.

• Make sure that the playlists are always correctly refreshed after an external event. I removed notifications to old PLAYLIST_REFRESH event and I may have missed some refresh notification.

• I think that the "Prepare party" feature should be available for any playlist from the Playlist View and not only the "New" one

• We will have to make sure we don't loose drag and drop capabilities. Some DnD features will have to be rewrite like dropping or dragging to/from the playlist table. Some code could be token from the now removed PlaylistTransferHandler? (still exist in 1.5 branch)

Hi Bertrand,

I don't see any Playlist Repository or Playlist Table view with buttons for [New] [Bestof] [Newest] [Bookmark] etc. Have you finished implementing it?

Hi Bertrand, Some questions: 1) Why did you remove the old PlaylistTransferHandler? code? What all changes will have to be made for the new setup? What exactly was PlaylistFileItem? earlier which has been removed now? 2) What is the differnece between PlaylistEditorTransferHandler? and PlaylistTransferHandler?? 3) Shouldn't the drag and drop feature be same for all Playlists -> Including Queue View and the Playlist View? Currently it works for Queue playlist. 4) We should also implement drag and drop of files within a playlist also, and try to remove the buttons currently being ued for moving items in playlist view?

Hi Varun, No I didn't implemented them. the playlist table is the main part of the job remaining.

On your questions: 1) I removed the PlaylistTransferHandler? because it deals with playlist items (playlist icons + label in the playlist repository views) that I removed too. I suppose you should write another dnd handler dealing with entry from the playlist table and probably based on the previous PlaylistHandler? code (it make me thing that we have to find a way to allow drop over smart playlists, perhaps using a separated handler if they are displayed as buttons and not table rows ? or should we finaly show them as regular table rows ? or should we show smart playlists like playlist items in old repository views before ? what do you think ?)

2) playlist editor transfert handler deals with dnd from and over the playlist editor table rows. PlaylistTranfertHandler? was used to manage dnd over and from the playlist repository playlist items (icons)

3) Good question, we should think about it and write down all possible use cases now queue and playlist editor views have been splitted to make sure we don't miss some. BTW, now or later, we should implement a row-level drop in queue and playlist editors (drag from somewhere, drop on a specific row, idealy showing a red line in the table where the item will be dropped or something..)

4) Ideally yes but we can keep up/down button (a lot of users don't use dnd). This is related with the row level drop I suggested before but then, the drag is from the same table. This is probably technically difficult but you may find such code on the web I guess...

In the trunk I can't use Playlist view at all. I can't select Playlists from the playlist table and I can't add files into the playlist.

Also, the playlist table should have horizontal scrollbar. For 1024x768 resolution only 2 icons are visible completely.

Sorry, playlist view is in progress. I hope it to be functionnal soon.

Hi Bertrand, How is the work going on the Playlist view? I wanted to work on the two feature related to DND:

1) DND at a particular location in the playlist. 2) DND within the playlist using mouse.

Please let me know how should I go about implementing these?

Varun

Thanks for proposal. On item 1, I suggest to go further only if you found precisely how to implement it (sample code for ie), otherwise, it should be postponed to next release. On item 2, the playlist view is still under heavy work and I'm not sure if it's even possible for 2 people to work efficiently on it, I should work on it this week, I'll tell you more if I find parallelizable tasks on it.