El Dimecres, 7 de novembre de 2012, a les 06:07:43, Vishesh Handa va escriure: > On Wed, Nov 7, 2012 at 6:00 AM, Albert Astals Cid <aa...@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 <aa...@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?
Well, Beta 1 is in 8 days... > > > > 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. Ahh, you mean copying from file: to tags: I see... I'd like to hear David's opinion on how that is going to be fixed at the kio/kioslave level. Cheers, Albert > > > > 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 <m...@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 << >> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<
