[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: multi-url KBookmarkDrag
From:       David Faure <david () mandrakesoft ! com>
Date:       2002-03-20 23:15:20
[Download RAW message or body]

On Wednesday 20 March 2002 23:50, Alexander Kellett wrote:
> The attached patch changes KBookmarkDrag to allow for multiple 
> bookmark drags. The interface to me seems fairly logical, but very BIC. 
> 
> Therefore, if possible i'd like to either get this into 3.0 release (or at
> least the most basic change of using a qptrlist but not changing the actual
> implementation) or alternatively get an idea on how to make this change without
> any need for BIC changes.

There is a BC way, but an awful one: copying the code into keditbookmarks 
and extending it there. After all, I can think of any other user of multiple
bookmark drags than keditbookmarks itself.
However, since you made the patch before 3.0 is out, I think it'd be
simpler and cleaner to commit it to KBookmarkDrag itself.

But... why a QPtrList? IMHO it makes the memory management difficult
(who deletes the items?). Why not use a QValueList instead?
KBookmark is value-based (being a wrapper around QDomElement),
copying a KBookmark is very cheap (it amounts to copying a pointer,
internally in QDomElement). With a QValueList this would be cleaner.

> Tronical suggested using KBookmarkGroup wrapped by a KBookmark, and
> passing that around. But, umm... i'm not sure i agree as my patch would
> probably look cuter :)

Actual groups (folders, with subfolders etc.) are not supported by KBookmarkDrag
even with this patch, right?

I think those are two separate issues. Ultimately, one should be able to
drag multiple items, each item being either a bookmark or a bookmark group.
So the perfect API is QValueList<KBookmark>, where items of that
list can be kbookmark groups - which is possible since a KBookmarkGroup
is a KBookmark.

I see how a "fake global group" hack would allow bundling those separate
items into a unique group, but I think this would be difficult to handle
(for a single bookmark, you'd get a fake global group masqueraded as a
KBookmark, you'd have to cast to a group, then extract the unique child?).
BC isn't the only thing that must be preserved, behaviour must be preserved
too (so if 3.0 comes out with "KBookmark" in the kbookmarkdrag methods,
3.1 must not only use KBookmark, but also the same way, not bundling
a group into it).

Summary: I strongly suggest QValueList<KBookmark>, and committing
before 3.0.

Thanks!

-- 
David FAURE, david@mandrakesoft.com, faure@kde.org
http://people.mandrakesoft.com/~david/, http://www.konqueror.org/
KDE, Making The Future of Computing Available Today
[prev in list] [next in list] [prev in thread] [next in thread]