Created attachment 61675 [details] [review]
leaftag integration

Thanks for your efforts, milestoning to Nautilus 2.16.

From a performance perspective this seems like a total non-starter. Not only does it do a blocking call which is forbidden in nautilus, it does (unless i'm misreading the code) a separate sql query for each file. So, reading a directory with 1000 files we'll be doing 1000 blocking sql queries...

At the minimum we need an asynch mechanism for this that can get all the tags for all the files in the directory in one go. Ideally it would also support change notification so that the UI can always be up to date.

Also, I'm not sure it makes sense to have a separate library and database just for tags. We really should use the same mechanism to store all dead metadata (i.e. icon positions, custom icons, emblems, notes, tags). Of course, such an implementation must also handle all the requirements we have: change notification, safe cross-process use (even on NFS $home), and it should not corrupt the db if accessed from two machines concurrently on shared NFS (its ok if we don't get a perfect user experience in this case, but we should not destroy data).

From a nautilus integration perspective I also think this needs more thinking, as it sort of conflicts with emblems. Emblems are essentially tags already, so just dumping in another form of tags next to it is looking kinda weird.

Created attachment 75415 [details] [review]
Updated Leaftag Integration Patch

Just an update that I got to build and run, however, it has some major functionality issues, and crashes a lot. And is very slow. Maybe leaftag is overkill to some extent, but we need to come up with one centralized place to keep this metadata about files. Its find it nautilus wants to do it (assuming of course the emblem GUI gets a major overhaul at some point ;) ) but I think we need to get this somewhere.

Setting right patch status as for comment #3 and comment #4.

It looks like the project is not maintained anymore. Closing as WONTFIX.