Closed bflorat closed 9 years ago
Commented by bflorat on 8 May 2007 20:45 UTC 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)
Commented by fsck222 on 15 Jul 2007 13:23 UTC (ticket cleaning, wrong version)
Commented by bflorat on 10 Feb 2008 21:06 UTC 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) :
Logical playlists feature is still in the engine but removed from documentation and user visibility.
Commented by varun on 26 Feb 2008 07:52 UTC 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.
Commented by bflorat on 26 Feb 2008 09:10 UTC 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:
What do you think ?
Commented by bflorat on 26 Feb 2008 09:12 UTC Replying to fsck222: Oops, sorry Alexis, I unfortunately deleted your comment
Commented by varun on 26 Feb 2008 14:08 UTC 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.
Commented by varun on 26 Feb 2008 14:10 UTC 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.
Commented by bflorat on 27 Feb 2008 08:33 UTC +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 :
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 :
__________________________________________________________ O Show duplicates [[Bestof](New]) [[Bookmark](Newest]) filter: [contains [ ](combo]) (keep code from AlbumTableview for ie) __________________________________________________________ ... playlist table (the "show duplicates" checkbox switch from physical to logical playlist list) __________________________________________________________ _______________Split pane_________________________________> _________________________________________________________
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:
OK, if you want to implement this (please affect the task to yourself. I let you create classes: Please:
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.
Commented by bflorat on 27 Feb 2008 08:35 UTC Well, here's a better preview: see attached file
Commented by varun on 27 Feb 2008 16:39 UTC 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.
Commented by anonymous on 27 Feb 2008 20:47 UTC 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.
Commented by varun on 15 Mar 2008 15:12 UTC Hi Bertrand, any progress with this. I am getting bit impatient 8-)
Commented by bflorat on 15 Mar 2008 19:02 UTC 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.
Commented by bflorat on 15 Mar 2008 22:07 UTC 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 :
Commented by varun on 16 Mar 2008 12:57 UTC 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?
Commented by bflorat on 16 Mar 2008 15:49 UTC 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...
Commented by varun on 28 Mar 2008 15:48 UTC 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.
Commented by bflorat on 28 Mar 2008 17:24 UTC Sorry, playlist view is in progress. I hope it to be functionnal soon.
Commented by varun on 15 Apr 2008 05:51 UTC 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
Commented by bflorat on 15 Apr 2008 07:28 UTC 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.
Reported by fsck222 on 31 Mar 2007 10:44 UTC I think we should add a new icon on the left called "playlist". It will have the current feature of playlist windows available on Physical/logical view. And later (much later) we could add in it: