> 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.
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. - Bart ----------------------------------------------------------- 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 > >
_______________________________________________ Amarok-devel mailing list Amarok-devel@kde.org https://mail.kde.org/mailman/listinfo/amarok-devel
