Descript.ion support

We welcome any suggestions for new features or improvements in Altap Salamander. Please post one suggestion per report.
User avatar
Posts: 94
Joined: 12 Mar 2006, 20:55
Location: Deutschland

Descript.ion support

Post by AbteriX » 06 Sep 2006, 13:20

An search about "Descript*ion" founds nothing? Even not in the ALTAP Roadmap (updated 05/26/2006)
Is no one intressted to use Decriptions?

Feature request: native use of Descript.ion within Salamander
Or know any one an stand alone tool i can use with Sala? Please?

Long time i didn't know what to do with this 'descript.ion's.
I used to use text files, named like the file i wanna to describe.
And i will do so in future... for longer text.

But now i use descript.ion in Sala and after a few days of using i love it!

I have for ex. an folder with a many command line tools.
I had a lot of work to create text files with info what this exe or com does :?

An, i want call it "descript.ion handler", show me all files in an folder
and allow me to put an sentence as decription behind this file name.

In the DESCRIPT.ION text file is an text like:
Blat.exe - Commandline eMAil tool
xyz.exe - will extract all boot images from...

See all the files in the folder.. and the DESCRIPT.ION file:

In this DESCRIPT.ION file are all file with name and an description about this file:


Descript.ion is a standard used by many applications to save file and
folder descriptions. It creates a hidden file in the folder containing the file
or folder, with the name of the item and description. Descriptions will be
saved and thus appear on the next time you look at the folder with a
software that supports the standard.
Info about and example Descript.ion: ... ormat=html

Descript.ion are also support in Monat: ... Part2.aspx

Here is an more advantage Description handler who use even plugins
to export some description automaticly:

What do you think?
Is DESCRIPT.ION support needed this days?
Will Altap Staff implement such a feature?
Will rose marry joe.. err, this is one another story, soon on Pro7.

Posts: 44
Joined: 28 Apr 2006, 17:21

Post by Tomcat » 07 Sep 2006, 20:40

Sounds like an interesting feature, though I do not think that it will make it into the core...
This seems to be a perfect scenario for a custom-made plugin (special interest feature but very helpful for a some (special) users).
Once Altap shoves out the promised plugin SDK, somebody may pick up this idea and create a plugin to show descript.ion data inline.

Jan Rysavy
Posts: 5196
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic

Post by Jan Rysavy » 07 Sep 2006, 23:13

The Servant Salamander SDK is very limited. Only functions you know from existing plugins could be implemented (file systems, archivers, viewers, menu extensions).

Posts: 162
Joined: 10 Dec 2005, 15:44

Post by JohnFredC » 08 Sep 2006, 01:28

This seems to be a perfect example of the usefulness of a column plugin.

Does the SDK address custom file panel columns a la the TC wcx plugins?

It would a straightforward matter to match the filenames and lines in the descript.ion file and post the descriptions to a column.

Sure hope the SDK supports Delphi 5 (my tool). Plugins would just be DLLs, right? So the "SDK" would consist of interface specifications (only)...?
Mouse-centric, Registered

Jan Rysavy
Posts: 5196
Joined: 08 Dec 2005, 06:34
Location: Novy Bor, Czech Republic

Post by Jan Rysavy » 08 Sep 2006, 06:37

There are not "custom columns" parsers now in Servant Salamander 2.5 RC1 (still sits on Altap Roadmap).

Decript.ion must be handled by SS core (operations such as Copy/Move/Rename/Pack/Unpack must modify the Decript.ion file).

Plugins are just simple DLLs with WINAPI like interfaces. So Delphi should be OK.

User avatar
Posts: 98
Joined: 24 Jul 2006, 17:13

Post by Georgd » 09 Oct 2006, 22:05

Tomcat wrote:This seems to be a perfect scenario for a custom-made plugin (special interest feature but very helpful for a some (special) users).
I disagree to the limited interest in that way, that currently there's imited interest (as only few apps handle descript.ion) but the potential interest is huge. As more and more people store more types of information on their computers (5 years ago - digital music? digital pics? rarely. today that's pretty common. Thik forward to movies, GPS,...), a need for metadata arises to keep track of the big bunch of data.

For example, a lot of image viewers like XnView, ACDSee etc. already use descript.ion to store comments without modifying images, as for JPEGs changing 8 times the comment would make the pic really bad - a no-no. Hence the need for sperated comments. Of course, this might also be done via EXIF and IPTC inside the image files, but that approach is a) limited to images (so how to do with executables or database files?) and b) slow to process (you've to open all the files instead of one single file).

Think of descript.ion as an extremely fast access to any kind of metadata, may it be comments, EXIF, tagging, descriptions,... and it becomes pretty useful for the broad mass -- unless the tools don't support it, eg. they don't move the metadata automatically when the file is moved, what means maintaining the metadata is a pain in the ass and noone will use it. Now think of a Salamander plugin offering you to extract the metadata out of pics, music,... in a convenient way, then you browse your pics with XnView and add some description (story behind the image, name of depicted people, place,..) and now Salamander's "Find" offers you an extremely fast access to all that stuff -- as it's nothing more than searching a text file. wow!

=> I'd love to have Salamander support decript.ion. I hate to create name files like "formula log of N divided by n_k" due to syntax restrictions and would prefer to write "formula log(N/n_k)" into decript.ion -- much better to read and quicker to write.
Using Salamander since v 1.52


Post by Georg » 12 Oct 2006, 19:20

Too lazy to log in,sorry . For Total Commander, they have a discussion about this subject, too, see Obviously, TC natively supports decript.ion but does not care about the full standard (cuts everything behind 512bytes length). A user wrote some add on supporting the full 4KiB length and line breaks. And BTW: XnView 1.9alpha is already very good with decript.ion, copy/delete/move/rename/... are supported, only minor-minor issues left (time of updating decript.ion next change to the file? on move? on program exit?).


Or NTFS alternate data streams

Post by Guest » 30 Oct 2006, 14:23

In case a proper support for descript.ion is taking a long time to implement, NTFS alternate data streams could be used - they're directly offered by the OS, so Salamander only needs to provide a means to display them, that's all. Moreover, they have multiple fields, support different stuff for different file types, and are used by desktop search engines.

The main downside: They're lost when the file is written to another file system, eg FAT for USB Sticks that are also used on *nix machines...that's why I'd love to have descript.ion AND the ADS used at once, so Salamander syncs the ADS comment and the descript.ion entry on the fly. That'd be great!

User avatar
Posts: 110
Joined: 10 Feb 2010, 04:39

Re: Descript.ion support

Post by otrov » 12 Dec 2010, 01:54

Sorry to bring such old topic to life, but that's what I meant to post about also. Explorer has trillion columns, TC supports various ways of adding custom columns, while some others like SC support columns available in Explorer. Seeing that this thread dates 4 years ago draw me back, but however I think I should post what I feel missing for a long time: simple descript.ion file support or whatever is handy to developers. IMHO descript.ion support would be easiest/fastest way for adding user defined column in known good old fashion.

Are there any plans for extending hard coded standard columns?

Post Reply