Good afternoon,
I was wondering if there is a list of all well known attributes, attributes in general use, or similar.
With a bit shell magic I found 141 unique attribute-type-pairs in use on my test system. However clearly this is in no way representative.
If anyone knows a list or is working on a list, would be happy to know.
You can explore them in the FileTypes preferences. A few types define common attributes, that Tracker then uses for the find dialog, the choice of columns in Tracker windows, etc.
Keep in mind that an app can define its own attributes, and you won’t know until you install the app. For example, MrPeeps defines new attributes for People files that don’t exist in the default People app.
I noticed that already. And I must say from a GUI perspective that is very nice. Is there any way I can export that list somehow?
Also naturally there is no documentation for each entry in the GUI. So I was hoping for something that at least had some short description. But maybe we can compile such a list from what is already in there.
Naturally. But given exactly that maybe a list somewhere in the documentation can ensure that we can make most out of them (so programs supporting other program’s attributes, but also avoiding any conflict).
As there seems to be no real list. Is there any place to start one? Otherwise I would just create one for my one need on some space that suits me.
You can access them through BMimeType. With the static methods GetInstalledSupertypes() and GetInstalledTypes() you can list the types and with GetAttrInfo() you can list the attributes defined for a type.
You can also script something for the shell to parse the output of catattr. For a taste of what to expect, try running catattr "META:ATTR_INFO" /system/data/mime_db/video. You have the system db in /system/data/mime_db/ and the user one in ~/config/settings/mime_db/.
CSV export of attributes in the MIME DB:
#include <MimeType.h>
#include <String.h>
#include <stdio.h>
BString escape(const char* text) {
BString escaped(text);
escaped.ReplaceAll("\\", "\\\\");
escaped.ReplaceAll("\"", "\\\"");
escaped.ReplaceAll("\n", "\\n");
return escaped;
}
void print(const char* mimetype) {
BMimeType mime(mimetype);
BMessage message;
if (mime.GetAttrInfo(&message) != B_OK)
return;
const char* name;
if (message.FindString("attr:name", 0, &name) != B_OK)
return;
char desc[B_MIME_TYPE_LENGTH];
BString short_description, long_description;
if (mime.GetLongDescription(desc) == B_OK)
long_description = escape(desc);
if (mime.GetShortDescription(desc) == B_OK)
short_description = escape(desc);
for (int i = 0; message.FindString("attr:name", i, &name) == B_OK; i++) {
const char* public_name;
message.FindString("attr:public_name", i, &public_name);
int32 typeCode;
message.FindInt32("attr:type", i, &typeCode);
char type[5];
type[0] = (typeCode >> 24) & 0xFF;
type[1] = (typeCode >> 16) & 0xFF;
type[2] = (typeCode >> 8) & 0xFF;
type[3] = typeCode & 0xFF;
type[4] = 0;
printf("%s,\"%s\",\"%s\",%s,%s,%s\n", mimetype, short_description.String(), long_description.String(), name, public_name, type);
}
}
int main(int, char**) {
printf("MIME,\"short description\",\"long description\",attribute,name,type\n");
BMessage message;
if (BMimeType::GetInstalledTypes(&message) == B_OK) {
const char* type;
for (int i = 0; message.FindString("types", i, &type) == B_OK; i++)
print(type);
}
return 0;
}
Nice!
Add to that the attributes added by applications that are not registered with the MIME db. Like be:caret_position that’s set originally by StyledEdit (I think) and is also used by Genio or Koder. You pretty much have to look at the attributes of files opened/edited by applications.
ArtPaint sets quite a few attributes on opened images, zoom, active layer, window size…
Not sure those wouold be of interest to other apps.
Koder e.g. also sets a “koder:bookmarks” that could be re-used by Genio, though here you’d have to first research what that flatteded BMessage all contains. Plus, you’d have to keep an eye out for changes in that BMessage contruction of any app that decides to share this attribute. Maybe the reason it starts with “koder:”, signalling a “private namespace”…
OTOH it’d make sense to share useful attributes like bookmarks across apps.
We’d need to resurrect “BeUnited” to create RFCs for common attributes that people can rely on (like be:caret_position). But who has the time and enjoys coordinating that sort of thing…? 
This will be a very important topic for SEN, too, so I’m all for a proper MIME types and attributes handling across applications.
As for the FileTypes settings, it would really be useful to add a “description” for attributes, so users can edit/view what this attribute means and what it is supposed to contain (format wise, not going into validity constraints just yet;-).
Another issue is that attributes will not be searchable when they are not indexed.
I think this was an oversight/time constraint issue in BeOS times, as users will run into this trap and wonder why their custom attribute is not working with queries.
Currently, you can only add them to the BFS index using a command line tool, which is not what the average user will want to/know how to do.
It would be quite easy to add an attr_info:searchable similar to attr_info:displayable and have the FileTypes app handle index creation/deletion upon change…
Thank you very much. That helped me some. It however seems the exported list is much shorter than I was expecting. Hm.
Still very helpful.
Also I noticed that some attributes (naturally) are defined multiple times. Specifically Media:Length seems to have two different definitions on my copy (however that just seems wording, not really conflicting data).
I mean I’m half way in that direction. However as there seems to be no common space for it I might end up with just my personal list that might be public in some form.
I think apps should document attributes they are using somewhere. An attributes.txt file? This way, it is possible to use the same portion of code, at least same logic, and same attribute in different apps. Caret position is a good example of what it can bring, indeed.
Are there rules for attributes naming? I mean a way to distinguish attributes that are private to an app and those that can be shared.
Maintaining a list would allow to know what attributes are already shared and avoid to use same attribute name for things that may differ even slightly. For now, checking what’s done in other apps is possible but when there will be more, it won’t be manageable.
maybe even go the Haiku native way using scripting and defining a message suite that returns the attributes used…