Hi,
this post is an appeal, both to the developers of TC and the developers of plugins, to enhance the functionality of file comments and to implement tags.
There is a huge unexploited potentiality in file comments, which has been largely ignored.
For starters, file comments could be used to manage tags. OK, this can already be done manually, but doing it manually would be practically pointless, unless there is a proper software infrastructure that manages tags.
What I suggest is implementing an automated way of managing tags, with advanced search capabilities and logical constraints (e.g. the exclusion of a tag). Tags could be stored in file comments, so they could also be edited manually.
In addition to tags, file comments will still contain what they were meant to contain in the first place: comments.
The tag functionality would be a very powerful organizing tool, because it would allow us to classify the same file as belonging to multiple categories or groups at the same time. This concept has been widely adopted in many software applications. You could have many virtual directories or collections, which include files that are not stored in the same location, but scattered in different parts of your hard disk. And yet, when recalling a given tag (or a combination of tags), all these files will appear listed together, as if they were in the same directory.
I am not expounding this concept further, because I believe that it is well known. But I only want to stress that wonderful things could be done.
One last note: it would be better, I believe, to use the extended file attributes supported by the file system (NTFS has them too - a well preserved secret!), instead of using a directory-based file like descript.ion.
Please contribute to this thread with your suggestions.
Thanks
Tags and enhancing the "file comment" functionalit
Moderators: Hacker, petermad, Stefan2, white
Hello Tyler,
quite some interesting ideas I think.
Generally I agree with you, but there's one problem with ADS that descript.ion s don't have: ADS get (silently) lost when packing and also when copying to a file system that doesn't support them (eg most USB sticks, as they use FAT).
But that's just to mention, I still think tags would be a great use for ADS.
TC's Advanced Search (Alt+F7) lets you use plugin fields (and from 8.5, still beta on also for duplicates search) so that's one place where you could use them. I happen to work on a plugin for ADS myself so I'd be quite interested in your requirements.
quite some interesting ideas I think.
so maybe better in TC suggestions (English)?this post is an appeal, both to the developers of TC and the developers of plugins
I guess you're referring to NTFS ADS (Alternate Data Streams), right? Plz check Integrate NTFS Streams handling into TC.it would be better, I believe, to use the extended file attributes supported by the file system (NTFS has them too - a well preserved secret!), instead of using a directory-based file like descript.ion
Generally I agree with you, but there's one problem with ADS that descript.ion s don't have: ADS get (silently) lost when packing and also when copying to a file system that doesn't support them (eg most USB sticks, as they use FAT).
But that's just to mention, I still think tags would be a great use for ADS.
TC's Advanced Search (Alt+F7) lets you use plugin fields (and from 8.5, still beta on also for duplicates search) so that's one place where you could use them. I happen to work on a plugin for ADS myself so I'd be quite interested in your requirements.
- - are the tags you have in mind simple boolean flags with a name, ie eg "landscape" either present on a file or not?
- or rather like fields that (in addition to being present or not) can have content, like eg the ID3 (mp3) tag "Artist"
- at least, I guess, you'd require custom names, right? (as opposed to the fixed set of ID3 tags)
- managing tags is a rather wide field (how many ID3 editors/managers exist, for example?) - what would be the most basic capability of a "manager" so that you wouldn't call editing (purely) manual anymore?
related thread: suport for comment field in zip files
Thanks for the appreciation, meisl.quite some interesting ideas I think.
You are right. Is there a way to move this whole thread to that section?>this post is an appeal, both to the developers of TC and the developers
> of plugins
so maybe better in TC suggestions (English)?
To be honest, I don't know about ADS. It might be the same thing, as you suggest.
>it would be better, I believe, to use the extended file attributes
>supported by the file system (NTFS has them too - a well preserved
> secret!), instead of using a directory-based file like descript.ion
I guess you're referring to NTFS ADS (Alternate Data Streams), right? Plz check Integrate NTFS Streams handling into TC.
With regard to packing, there are already some archivers that support extended attributes, so they won't get lost.Generally I agree with you, but there's one problem with ADS that descript.ion s don't have: ADS get (silently) lost when packing and also when copying to a file system that doesn't support them (eg most USB sticks, as they use FAT).
Regarding moving the files to a different filesystem, yes, of course, the extended attributes will get lost.
Both.I happen to work on a plugin for ADS myself so I'd be quite interested in your requirements.
- - are the tags you have in mind simple boolean flags with a name, ie eg "landscape" either present on a file or not?
- or rather like fields that (in addition to being present or not) can have content, like eg the ID3 (mp3) tag "Artist"
I agree. It takes a lot of thinking to come up with a well-thought system for tags. I don't have most of the answers now, but I hope that other contributors to this thread will provide useful input.- managing tags is a rather wide field (how many ID3 editors/managers exist, for example?) - what would be the most basic capability of a "manager" so that you wouldn't call editing (purely) manual anymore?
@white: Thanks for moving the thread.
@Tyler:
Basically, TC provides two built-in ways of editing a file's comment, and these correspond to descript.ion vs ADS:
a) Files | Change Attributes | Plugin: tc.comment (descript.ion)
b) right click on file | Properties | tab File Info - or simply Alt+Enter (ADS)
as for b) I'm not quite sure what's the exact tab header in English (it's "Dateiinfo" in German), might as well be "Extended Info" or so in English. This has several fields like "Title", "Subject", "Author", "Category", "Keywords" and "Comment". AFAIK the contents of these are stored two in two separate ADS ("Comment" in one and the rest in another, see again mentioned thread, plz).
When you did it "manually", which one did you use?
Thinking about the envisioned "tag manager", which user interface would come closer to what you'd need?
Btw: do you know about TC plugins, particularly the distinction between content-..., file-system-..., packer-... and lister-plugins? NP if not, just need to know
Could you name some?
Anyways, that'd not be the first thing to tackle.
You know, what I'm really after is improving the "meta" plugin tc_java which allows for writing TC plugins in Java. I happened to choose a content plugin re ADS as a use-case. And whether to keep the tag information in descript.ion or in an ADS is in fact a separate (implying "separable") question.
But nevertheless, what I really need - and would greatly appreciate - is any sort of feedback; and your idea re tags seems like a really good fit to me.
So, if you could help me with defining some first milestones ("most basic requirements") which might eventually turn out to be actually useful - that'd be awesome!
For example, what is your actual use-case? What are you trying to do, with what kind of files? Images, mp3s, how many of them? What are examples of tags that you'd like to be able to manage?
Even better if you were able to give my attempts a try every now and then (which entails possibly tedious re-installing of plugins and testing and so on...)...
But as said, that I'd consider "icing on the cake", just some help with developing first specs would be great in itself
@Tyler:
Have you had time to read the mentioned thread? It's not too long and towards the end there are a few links for further investigation, like Microsoft documentation and already existing plugins for TC.To be honest, I don't know about ADS. It might be the same thing, as you suggest.
Basically, TC provides two built-in ways of editing a file's comment, and these correspond to descript.ion vs ADS:
a) Files | Change Attributes | Plugin: tc.comment (descript.ion)
b) right click on file | Properties | tab File Info - or simply Alt+Enter (ADS)
as for b) I'm not quite sure what's the exact tab header in English (it's "Dateiinfo" in German), might as well be "Extended Info" or so in English. This has several fields like "Title", "Subject", "Author", "Category", "Keywords" and "Comment". AFAIK the contents of these are stored two in two separate ADS ("Comment" in one and the rest in another, see again mentioned thread, plz).
When you did it "manually", which one did you use?
Thinking about the envisioned "tag manager", which user interface would come closer to what you'd need?
Btw: do you know about TC plugins, particularly the distinction between content-..., file-system-..., packer-... and lister-plugins? NP if not, just need to know
Right, full-blown backup systems like eg TrueImage do of course support them. But simple packers - at least those I know of, and especially the ones built into TC - don't.With regard to packing, there are already some archivers that support extended attributes, so they won't get lost.
Could you name some?
Yep, it's a matter of having the user be aware of it. Ideally there should be some warning whenever they might get lost, but what a plugin as such can do wrt that is limited.Regarding moving the files to a different filesystem, yes, of course, the extended attributes will get lost.
Anyways, that'd not be the first thing to tackle.
Ok, so the latter (as it implies the first).Both.I happen to work on a plugin for ADS myself so I'd be quite interested in your requirements.
- are the tags you have in mind simple boolean flags with a name, ie eg "landscape" either present on a file or not?
- or rather like fields that (in addition to being present or not) can have content, like eg the ID3 (mp3) tag "Artist"
You know, what I'm really after is improving the "meta" plugin tc_java which allows for writing TC plugins in Java. I happened to choose a content plugin re ADS as a use-case. And whether to keep the tag information in descript.ion or in an ADS is in fact a separate (implying "separable") question.
But nevertheless, what I really need - and would greatly appreciate - is any sort of feedback; and your idea re tags seems like a really good fit to me.
So, if you could help me with defining some first milestones ("most basic requirements") which might eventually turn out to be actually useful - that'd be awesome!
For example, what is your actual use-case? What are you trying to do, with what kind of files? Images, mp3s, how many of them? What are examples of tags that you'd like to be able to manage?
Even better if you were able to give my attempts a try every now and then (which entails possibly tedious re-installing of plugins and testing and so on...)...
But as said, that I'd consider "icing on the cake", just some help with developing first specs would be great in itself