hello.
advanced "descript.ion" file of csv or xls or a similar table format.
with fields editable directly by clicking on them in file list.
advanced "descript.ion" - csv
Moderators: Hacker, petermad, Stefan2, white
hello.
do you think "this would be good but this is too difficult and tc should not become table editor and this should be implemented in file system not by tc's custom file"? or you simply had not understood because i write english not correctly?
about file system i think it would be good in the future for old filesystems like fat32, ntfs..
i will explain with some examples this my suggestion:
it would give ability to add custom column like "some parameter of video encoding" and fill this field for every file manually and this would be stored in that "index.csv" file and copied with this file when it is being copied.
that is if somebody tests an encoder and wants to compare files made with different options of encoding. currently in such case i write all this info in the file name:
MPEG4v2,720px,24b,25f,LFF;;kfe2s,5cmprs,82kbps.avi
MPEG4v2,720px,24b,25f,LFF;;kfe2s,5cmprs,1033kbps.avi
...
Cinepak,720px,24b,25f,LFF;;2%,kfp50f.avi
...
dvT2,720px,24b,25f,LFF;32mh,16b,ster.avi
and others.
also another examples: try different formats with xnview with different options, and also output formats of lot of programs: photoshop, djvu express enterprise, fine reader.
do you think "this would be good but this is too difficult and tc should not become table editor and this should be implemented in file system not by tc's custom file"? or you simply had not understood because i write english not correctly?
about file system i think it would be good in the future for old filesystems like fat32, ntfs..
i will explain with some examples this my suggestion:
it would give ability to add custom column like "some parameter of video encoding" and fill this field for every file manually and this would be stored in that "index.csv" file and copied with this file when it is being copied.
that is if somebody tests an encoder and wants to compare files made with different options of encoding. currently in such case i write all this info in the file name:
MPEG4v2,720px,24b,25f,LFF;;kfe2s,5cmprs,82kbps.avi
MPEG4v2,720px,24b,25f,LFF;;kfe2s,5cmprs,1033kbps.avi
...
Cinepak,720px,24b,25f,LFF;;2%,kfp50f.avi
...
dvT2,720px,24b,25f,LFF;32mh,16b,ster.avi
and others.
also another examples: try different formats with xnview with different options, and also output formats of lot of programs: photoshop, djvu express enterprise, fine reader.
ability to edit the existings fields would be a first step for this. for example: click to extension and edit it. click to file size and edit it! click the file date and then edit it! click to file name and edit it or select for editing file name without extension. but for editing mp3 tags there should work plugins i think.
I've thought about this quite a bit over the years and loosely designed an approach which I have never actually implemented. A three part solution seems best:
Part 1: Stand-alone "table" design tool for field definitions, display formats, etc. The definitions themselves would be stored in a (text) file.
Part 2: A wlx plugin to a) assign a "table" definition and b) edit/display the field values for the selected file. The Descript.ion text associated with the file would include a reference to the "table" definition file to be used (created in Part 1) and a delimited series of values.
Part 3: A wdx plugin to extract the delimited values from Descript.ion, match them to the field definitions (in the assigned "table" definition file), format the values accordingly, and display them in TC custom columns.
Shouldn't be too hard to implement, actually, but I haven't approached this in the past due to TC's various limitations with the descript.ion file format (record length in the descript.ion file being the biggest issue). Plus I've never built a wdx plugin.
Another reason to avoid this approach might be that using Windows native metadata capabilities (NT Streams?) is probably a better method in the long run. Using the above method (instead of streams or other method) would limit the metadata visibility to TC.
Still. I keep coming back to the idea...
Part 1: Stand-alone "table" design tool for field definitions, display formats, etc. The definitions themselves would be stored in a (text) file.
Part 2: A wlx plugin to a) assign a "table" definition and b) edit/display the field values for the selected file. The Descript.ion text associated with the file would include a reference to the "table" definition file to be used (created in Part 1) and a delimited series of values.
Part 3: A wdx plugin to extract the delimited values from Descript.ion, match them to the field definitions (in the assigned "table" definition file), format the values accordingly, and display them in TC custom columns.
Shouldn't be too hard to implement, actually, but I haven't approached this in the past due to TC's various limitations with the descript.ion file format (record length in the descript.ion file being the biggest issue). Plus I've never built a wdx plugin.
Another reason to avoid this approach might be that using Windows native metadata capabilities (NT Streams?) is probably a better method in the long run. Using the above method (instead of streams or other method) would limit the metadata visibility to TC.
Still. I keep coming back to the idea...
Licensed, Mouse-Centric, moving (slowly) toward Touch-centric
Good point about FAT, but I disagree about the XML. The wlx should be "lite" and parsing XML isn't "lite".
One thing the lister (wlx) would do is match delimiters between two records: the definition record (stored separately or in a designated line in the descript.ion file) and the data record, stored once in descript.ion for each file. An XML field definition would complicate that considerably, I think. Are there any "tiny" XML parsers for Delphi VCL out there?
If a really robust system was needed, then it would be better to use the MS desktop database engine (Jet) for that (or perhaps MySQL). But then, no need for descript.ion, right?
Anyway, my idea was just "quick and dirty", to match a need I have from time to time.
One thing the lister (wlx) would do is match delimiters between two records: the definition record (stored separately or in a designated line in the descript.ion file) and the data record, stored once in descript.ion for each file. An XML field definition would complicate that considerably, I think. Are there any "tiny" XML parsers for Delphi VCL out there?
If a really robust system was needed, then it would be better to use the MS desktop database engine (Jet) for that (or perhaps MySQL). But then, no need for descript.ion, right?
Anyway, my idea was just "quick and dirty", to match a need I have from time to time.
Licensed, Mouse-Centric, moving (slowly) toward Touch-centric
(
but using separate file for table is not very bad, it has advantages: file system is smaller so faster - faster its most important functionality, table is a less important, additional feature, and because it is a simple (usual, custom, general) file it is easier to change handling-opening it, format of it..)... this should be implemented in file system not by tc's custom file"? ...
about file system i think it would be good in the future for old filesystems like fat32, ntfs..