Erlend Davidson wrote: >>PS: I've also an 5-month old patch to add leaftag support, which I could >>update to the latest Thunar version with some effort, if there's >>interest (would add a 'tag:' filesystem with the list of current tags, >>and a list of files for each tag). The idea was to replace the >>emblem-mechanism with tags (tags have an associated image). In general I >>think this would be very useful, but unfortunately leaftag doesn't scale >>very well (as mentioned before) and it seems that leaftag is mostly dead >>(nearly no SVN activity). > > Would the Leaftag functionality be a plugin, so that the slow-down is > optional? Looking at the Leaftag blog > (http://www.chipx86.com/blog/tag/leaftag) the developer mentions (in > Feburary) lack of time and moving Leaftag to a dedicated server - AFAIK > it hasn't happened yet.
As botsie said, a relational database is probably not the way to address this problem, or atleast SQLite 2.x is not. It works fine as long as the number of tags and sources is below 500 or so, but even then, because the sources have to be matched by their URIs, the folder loading will be slower when locating the emblems for each file. Storing the tags in extended attributes would solve this issue with modern file systems (note that not all file systems offer fast extattr access), but it does not allow to query the files by tag. > The slow-down with scaling is a real pity - a tagging filesystem would > be excellent for linux. Well, not only for Linux... Benedikt _______________________________________________ Thunar-dev mailing list [email protected] http://foo-projects.org/mailman/listinfo/thunar-dev
