[Nepomuk] Nepomuk Tags kioslave - Please Review

Wed Nov 7 00:37:43 UTC 2012

On Wed, Nov 7, 2012 at 6:00 AM, Albert Astals Cid <aacid at kde.org> wrote:

> El Dimecres, 7 de novembre de 2012, a les 05:51:45, Vishesh Handa va
> escriure:
> > On Wed, Nov 7, 2012 at 5:36 AM, Albert Astals Cid <aacid at kde.org> wrote:
> > > El Dimarts, 6 de novembre de 2012, a les 18:30:27, Albert Astals Cid va
> > >
> > > escriure:
> > > > El Dimarts, 6 de novembre de 2012, a les 18:17:29, Vishesh Handa va
> > >
> > > escriure:
> > > > > Ping?
> > > > >
> > > > > I'll be merging this on Thursday. I would appreciate it if somone
> > > > > could
> > > > > review the code.
> > > >
> > > > I'll have a look later today (based on my 0 knowledge of nepomuk &
> > >
> > > friends).
> > >
> > > Had a look to the code and to my knowledge it seems that it does not do
> > > any
> > > ultra silly thing, also it's a kioslave so people won't use it unless
> they
> > > want so in case it is horribly broken the "bad stuff" it can do it is
> > > pretty
> > > limited (just don't use the kioslave and done!)
> > >
> > > So i'd say go ahead.
> > >
> > > I'm curious with what you mean with "loosing"  in "You can move files
> into
> > > a
> > > tag folder thereby effectively loosing them" though. Could you give
> some
> > > more
> > > info?
> >
> > The file will be deleted.
>
> Ok, that's bad, i'm vetoing on that then. Deleting user files is the worst
> thing ever, even if it is in a "exotic" kioslave.
>

Couldn't I still merge it and then work on the bug fix before it is
officially released?

>
> > From what I understand KIO does moves by copy +
> > delete.
>
> That's not true, try moving a 4GB file to from a folder to another in the
> file:/
> kioslave and you see that it actually "moves" the file, not copies and
> deletes
> it (basically the operation is instantaneous instead of taking ages)
>

I think the behaviour I described is across two different kio slaves.

>
> > The copy operation results in the corresponding tags being applied,
> > and the delete operation then deletes the file. The correct behaviour in
> > our case would be to either only allow copy operations or convert move
> > operations into copy operations.
>
> Why does the tags: kioslave even knows how to delete files? What's the
> point of
> it? If i am using the tags: kioslave i would understand i'm just working on
> tags and not on file content.
>

The tags kioslave doesn't delete the file. It's the "file" kioslave that
deletes it.

Deleting a file from the tags kioslave results in that tag being removed.

> Cheers,
>   Albert
>
> >
> > We'll need to introduce some new kio flags to fix this. At least that's
> > what I understood from my discussion with David.
> >
> > > Cheers,
> > >
> > >   Albert
> > >
> > > > Cheers,
> > > >
> > > >   Albert
> > > >
> > > > P.S: You sent the email to the wrong list, we do reviews in
> > >
> > > kde-core-devel
> > >
> > > > not kde-devel
> > > >
> > > > > On Wed, Oct 31, 2012 at 3:12 AM, Vishesh Handa <me at vhanda.in>
> wrote:
> > > > > > Hey everyone
> > > > > >
> > > > > > I recently wrote a 'tags' kio slave, which allows one to browse
> > >
> > > nepomuk
> > >
> > > > > > tags, and the files containing those tags. It is currently in
> > > > > > kde-runtime/nepomuk/kioslaves/tags/, in the nepomuk/tagsKioSlave
> > >
> > > branch.
> > >
> > > > > > Could someone please review it? I would like to merge it before
> the
> > >
> > > hard
> > >
> > > > > > freeze.
> > > > > >
> > > > > > It has a custom url naming scheme -
> > > > > >
> > > > > > *tags:/tag1* => All the files tagged with 'tag1' and additional
> tags
> > > > > > which can be used filter the results.
> > > > > >
> > > > > > *tags:/tag1/file_url_of_the_file* => This is the url of the file.
> > > > > > Ideally
> > > > > > I would just use the normal url of the file, but we need to have
> the
> > > > > > 'tags'
> > > > > > protocol, so that we can handle delete events. We don't want to
> > >
> > > delete
> > >
> > > > > > the
> > > > > > file, rather just remove that tag.
> > > > > >
> > > > > > This file_url_of_the_file is added as the UDS_NAME, and results
> in
> > >
> > > the
> > >
> > > > > > search results looking slightly ugly if the file properties are
> > >
> > > checked.
> > >
> > > > > > Is
> > > > > > there a better way of handling this?
> > > > > >
> > > > > > *tags:/tag1/tag2 *=> Files tagged with both tag1 and tag2
> > > > > >
> > > > > > Known problems -
> > > > > > * You can move files into a tag folder thereby effectively
> loosing
> > >
> > > them
> > >
> > > > > > * No automatic updates
> > > > > > * It shows the tags with the nepomuk icon. We need a better
> 'tags'
> > >
> > > icon.
> > >
> > > > > > --
> > > > > > Vishesh Handa
> > > > >>
> > > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> > >
> > > unsubscribe
> > >
> > > > >> <<
> > > >>
> > > >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to
> > >
> > > unsubscribe <<
>

-- 
Vishesh Handa
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20121107/3f6456a9/attachment.html>