[Kde-pim] Handling virtual collections in applications

[Volker Krause]

On Tuesday 03 March 2009 16:25:15 Stephen Kelly wrote:
> Sorry, this is another in the series of 'Steve's long emails' :)

and as usual, one that took me way to long to answer ;-)

Let me start with a general note on this stuff: As we don't really have 
implemented search yet, virtual collections are largely unused. The 
Item[Un]Link jobs have been implemented on request of Tom and Dmitry who 
wanted to use virtual collecitons for the Nepomuk tag resource and the KRSS 
stuff. Not sure about the latter, the tag resource might as well be the only 
current user.

> Something that came to mind while implementing the models stuff is how the
> model should handle virtual collections. I think it should not be possible
> to move, or insert an entity from a virtual collection using regular user
> actions (like drag and drop). However, I don't think there's currently any
> way to know if a particular collection is a virtual collection. Do we need
> a Collection::isVirtual()? Does a collection know that it's virtual?

There is no way to detect that currently, which is also a problem for the 
server side implmentation. Currently its a big hack using hardcoded resource 
names :-/

> It would be necessary to know that in the EntityTreeModel::dropMimeData
> method to for example stop the meaningless action of dropping a contact
> into the Search collection or any other virtual collection. Dragging from a
> virtual collection would have meaning, but it might also be confusing.
>
> Consider some tree like
>
> (root)
> -> Col 0
> -> -> Item 0-0
> -> Col 1
> -> -> Item 0-1
> -> Search [virtual]
> -> -> Item 0-0
>
> And imagine that the user drags Item 0-0 from Search into Col 1. That could
> behave exactly like dragging the item from Col 0 into Col 1, but the user
> might be confused that they dragged the item from the Search collection,
> but the item actually disappeared from Col 1, and it's still in the Search
> collection (because it still contains their search term). An option would
> be to disable internal moves as well from virtual collections, and only
> allow copy actions.
>
> Any thoughts on that?

I agree with Ingo, moving from a virtual collection has its use-cases. In 
fact, dragging to a virtual collection has as well, eg. in case of the tag 
resource. But that is probably impossible to handle in a generic way.

> What else are virtual collections used for, apart from search? Are there
> any other use cases for them?

I'm not aware of anything that is not search-releated here.

> Virtual collections can't contain collections as far as I can see (there is
> an itemLinkJob, but not a CollectionLinkJob). Is there a usecase for
> (dis)allowing that?

Good question, I can't think of a use-case for allowing it at the moment. 
Somewhat related is the question of cascading virtual collections. That makes 
IMHO more sense, see eg. the tag resource. Mixing both could get very 
confusing though.

> Is there actually anything special about virtual collections, or is it
> simply any collection which has an item linked in it? In the same way that
> I can symlink files and directories in my filesystem. Can I link an item to
> any collection?

Currently that is not allowed. There is no unsolvable technical reason for not 
doing it though. However, I can obviously not write any inter-resource links 
to any resource backend, I'm not even aware of any backend that would support 
intra-resource links. So, such links would be purely local, not something you 
might expect in your IMAP/Groupware folders. Given that I don't see a 
use-case for that yet, I would suggest to not allow it.

> What happens if I list a collection which contains (sym)links to items?
> Will the list job return a list including linked items? Will I have any way
> of knowing whether the returned item is really in the listed collection, or
> if it is just a link to an item in another collection?

Currently you cannot detect the difference at all, list jobs return both, 
items and links. It would be possible though, if we do not allow mixed 
collections and add a way to detect if a collection is virtual. Also, having 
the full parent path available in the item as we discussed elsewhere would 
allow such a check, even in the mixed case.

regards
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-pim/attachments/20090311/99b7af6c/attachment.sig>
-------------- next part --------------
_______________________________________________
KDE PIM mailing list kde-pim at kde.org
https://mail.kde.org/mailman/listinfo/kde-pim
KDE PIM home page at http://pim.kde.org/