Review Request 108906: Add ability to drag titles to re-arrange them in queue manager

[Matěj Laitl]

> On Feb. 12, 2013, 2:49 p.m., Matěj Laitl wrote:
> > I don't think creating a custom subclass is the right way to implement drag & drop support. The right way should be implementing QAbstractItemModel for the queue (with drag&drop methods) and then the GUI would automatically support it with none or minimal changes. Similar to what Bart said, we prefer using the .ui files as much as possible. Also, when the QAbstractItemModel approach is used, there should be no need to split the patch into 2 review requests.
> 
> Bart Cerneels wrote:
>     I didn't even consider what the patch is actually supposed to do. Not completely sure that a QAIM subclass is the best option. D'n'D for moving is a bit harder then regular dropMimeData. But a model for a list of simple list of tracks that can be ordered like that could be reused a lot, even after the big PlaylistQueue refactor.

> Not completely sure that a QAIM subclass is the best option. D'n'D for moving is a bit harder then regular dropMimeData.

I still consider implementing QAIM much nicer than reinventing the wheel and implementing the drag & drop at the QWidget level.


- Matěj


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/108906/#review27302
-----------------------------------------------------------


On Feb. 11, 2013, 10:43 a.m., Bartosz Szreder wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/108906/
> -----------------------------------------------------------
> 
> (Updated Feb. 11, 2013, 10:43 a.m.)
> 
> 
> Review request for Amarok.
> 
> 
> Description
> -------
> 
> The new ListWidget (PlaylistQueueEditorListWidget - feeling enterprisey today) supports drag'n'drop of self-contained ListItems to itself. On successful dropEvent a signal is emitted, which is intercepted by a new slot reloadQueue() in PlaylistQueueEditor. This slot in turn recreates the queue via The::playlistActions().
> 
> Things to consider in future:
> - dragging from the playlist into the queue editor 
> - making the whole operation more efficient than clearing and recreating whole queue on each dropEvent 
> - possibly less hacky way of implementing things? maybe some backend interface would need to be added/exposed for the queue editor? any advice from a seasoned Amarok developer would be very valuable
> 
> If this isn't going to be accepted as-is into Amarok codebase then I'm willing to put some time into reworking the solution.
> 
> 
> This addresses bug 263563.
>     https://bugs.kde.org/show_bug.cgi?id=263563
> 
> 
> Diffs
> -----
> 
>   src/CMakeLists.txt 043dc64 
>   src/playlist/PlaylistQueueEditor.h 40b8cdf 
>   src/playlist/PlaylistQueueEditor.cpp f647e37 
> 
> Diff: http://git.reviewboard.kde.org/r/108906/diff/
> 
> 
> Testing
> -------
> 
> Tested on two different installations, no bugs, regressions or instabilities noticed.
> 
> 
> Thanks,
> 
> Bartosz Szreder
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/amarok-devel/attachments/20130217/e1c82683/attachment-0001.html>