> On 2010-12-03 18:43:50, Stephen Kelly wrote:
> > It wasn't so much forgotten as omitted because of complexity and weird UI.
> > 
> > Drops can be released directly on an item, or between two items.
> > 
> > If a drop on a kdescendantsproxymodel is released on an item it is 
> > reasonably clear that the dropped data should be made a child of the item 
> > it is dropped on.
> > 
> > In that case, dropMimeData is called with row == -1, column == -1 and 
> > parent == the drop target.
> > 
> > If a drop on a kdescendantsproxymodel is released between two items it is 
> > not clear where it should be invoked in the source model.
> > 
> > Consider this source tree:
> > 
> > - A
> > - - B
> > - - C
> > - D
> > - E
> > 
> > If I take E and drag it onto A, it becomes a sibling of C. Fair enough. If 
> > I instead drop it between A and B I'll get a visual indicator of a 
> > horizontal line indicating whether it is to be dropped below A (result is 
> > it goes above D as a sibling of A), or above B (result is it goes above B 
> > as a first child of A).
> > 
> > In general, if I drop between two adjacent items the result will be that 
> > the new (or moved) item will appear between them.
> > 
> > Consider what would happen in the proxy model case:
> > 
> > - A
> > - B
> > - C
> > - D
> > - E
> > 
> > Dropping E between A and B could result in E being between A and B (and 
> > change the structure of the source model such that E is a child of A (Weird 
> > - not what the user did), or it would appear between C and D as a child of 
> > the parent of A (Weird - not where the user dropped it, and it also changes 
> > the structure of the source model, which is not what the user is looking 
> > at).
> > 
> > Even dropping on the target itself would be weird. If you drop E on B, it 
> > becomes a child of B in the source model, but it appears as the next 
> > sibling of B in the proxy. Therefore it teaches the user that if they want 
> > E to appear below a certain item, they should drop it on that item (the 
> > user doesn't see the changes to the source model, except maybe somewhere 
> > else in the application).
> > 
> > KDescendantsProxyModel is a bit of a special case in this regard because it 
> > completely changes the structural representation of the source model. 
> > dropMimeData also changes the structure of the model, so this method is 
> > incompatible with this class.
> > 
> > Finally, I couldn't think of any way to use the class where you would want 
> > to do this, so I just left it out.
> > 
> > So I'm -1 on this patch.
> > 
> > Thanks all the same. It's good to know other people are watching the code 
> > I'm writing to try to make it better.
> > 
> > Steve.
> > 
> > PS:
> > I've just read the dropMimeData doc entry, and it's wrong and misleading. 
> > Don't rely on it too much. It is not the responsibility of the view to 
> > decide where things go in the model for one thing.
> 
> Ingo Klöcker wrote:
>     Isn't this model supposed to be used for threading of (email) 
> discussions? If yes, then I know of a use case for drop support: Allow fixing 
> of broken threads, i.e. allow manual adjustment of the threads.
>     
>     Example:
>     - A
>     - - B
>     - C
>     - D
>     
>     where D is a reply to B, but Kontact failed to recognize this. To fix 
> this I'd like to drop D on B (or below B, but I'd be okay with dropping 
> between items not being possible).
>
> 
> Stephen Kelly wrote:
>     Nope, you're thinking of KReparentingProxyModel (still in research 
> stage). Good point about drag and drop making sense for that one, but only in 
> the special case of the source model being a flat list, as is the case with 
> KMail.

good point and thanks for your explanations.

i close this request.


- Mario


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://svn.reviewboard.kde.org/r/6035/#review9115
-----------------------------------------------------------


On 2010-12-03 16:37:47, Mario Bensi wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://svn.reviewboard.kde.org/r/6035/
> -----------------------------------------------------------
> 
> (Updated 2010-12-03 16:37:47)
> 
> 
> Review request for kdelibs and Stephen Kelly.
> 
> 
> Summary
> -------
> 
> bug fix : add a forgotten method in KDescendantsProxyModel to forward the 
> DropMimeData to the sourceModel
> 
> 
> Diffs
> -----
> 
>   trunk/KDE/kdelibs/kdeui/itemviews/kdescendantsproxymodel.h 1203163 
>   trunk/KDE/kdelibs/kdeui/itemviews/kdescendantsproxymodel.cpp 1203318 
> 
> Diff: http://svn.reviewboard.kde.org/r/6035/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Mario
> 
>

Reply via email to