More indexed attributes by default

1

As the subject line says, really: for example, keyword, caption and copyright for jpeg files; title, artist, genre, etc for MP3s.

Anyone who’s played with attributes knows how powerful they can be, but it’s a fiddly business setting up new ones and getting them indexed and working. Much easier if they are already active by default.

Furthermore, Be attributes were always supposed to be the fundamentals of the sort of whizz-bang live search interfaces Mac and MS are now implementing. We’ve lost the initiative but catching up ought to be a priority. With the fundamentals in place, shouldn’t it be (relatively) easy?

2

FULL ACK.

there are all these great things one can do with the bfs and so on, but imo the most of the beos-users use only a few of these…
and these features will become more important with tiger and winfs…

one other thing i thought of when seeing the spotlight search on os x 10.4:
it displays the search results automatically sorted in categories like apps, pics, music, emails, etc. couldn’t this be done relatively easy for the haiku search ?
the live query result window just had to look at the mime-types of the files (which it does already as it displays the filetype) and sort them accordingly.

or am i wrong ?

anyway:

  • more indexed attributes from the beginning
  • sorted search results

i think this would be a immense progress in usability without to much developing effort (afaict)

bye,

b.

3

Is there some sort of GUI for selecting indicies yet? Are there any plans for one?

4
h_ank wrote:
Is there some sort of GUI for selecting indicies yet? Are there any plans for one?

Not exactly sure what you mean. There are add-ons that allow you to right-click a file and view all of its properties and attributes (QuickRes does this I’m pretty sure). You can also tell Tracker to display any attribute that a file in that folder has, and then you can sort by that attribute.

As far as sorted searches go, this is already possible, although not as pretty as in OSX. The query results box is just a Tracker view, and you can sort by any column, including mimetype. All Tracker would have to do is sort by mimetype (or supertype) and display a pretty header every time the mimetype of a file is different than that of the file just above it. This could be an additional feature to a future version of the Tracker, or this could probably be done as a separate app by looking at the API calls for doing a system query, sorting the results yourself, and drawing a custom Tracker-looking view that also incorporated labels and such. Currently there is a way to create Tracker query templates, which are used to display queries that match a certain mimetype. I have a custom template that is used when I search for email messages that displays receive date, sender name, subject, etc instead of the default filename, size, and whatnot. Making a template for mp3 files can give you nearly all of the search-and-sort power or a tool like iTunes. Playing around with these templates may provide a way to do this with what tools we have already.

I definitely think you hit the nail on the head with the attributes thing. BeOS has for the most part ignored the power behind attributes (among other things) and is now in the position of playing catch-up to the other guys. While there is humor in the fact that BeOS has enjoyed a database-like filesystem for years and the other guys are just now getting there, it is also rather sad that we have been sitting on all these powerful features and haven’t really begun to explore their depths…

5

What I meant would be for there to by GUI tools for adding new indicies or attributes. Right now many of the tools for working with attributes are terminal based.

6

When I started this thread I was enjoying myself importing lots of pictures from a new camera, and setting them up with caption, keyword and copyright strings in custom attributes. (And then setting up a collection of saved queries as “photo albums” , along with a custom zookeeper that uses the Slizer screensaver to present them as slideshows - but that’s another story …)

But I came across a few frustrations: first, if you edit a picture in ArtPaint then all custom attributes are lost when you save the edited picture.

I guess this is a limitation of the system jpeg translator (and would apply to any graphics program which uses said trasnlator): So, I think the Haiku jpeg translator ought to support and preserve file attributes.

Second is the problem of dovetailing with the rest of the universe, where Photoshop is the king and all that sort of information is carried in the IPTC fields embedded in the file. Can there be some way of automatically synchronising IPTC headers with BeOS attributes when both importing and exporting jpegs? So when you copy a jpeg to your system, the filetype sniffer which identifies it as a jpeg should automatically call on the translator to search the IPTC fields and write suitable attributes; and when attributes already exist, the translator should constuct suitable IPTC fields.

I am less familiar with the way non-BeOS systems handle MP3s but if I understand it correctly, the situation is identical, with ID tags embedded in the file. The same process should apply.

AS for Be queries, I think they have a serious limitation in that each one has to be based on a particular mimetype, so you can create “keywords” as a custom attribute of jpegs, and also “keywords” as a custom attribute of some other filetype - mail, PDFs, Gobe documents, etc - but a Be Query can only act on one base filetype, thus defeating the purpose to some extent. (If there is a way around that, I haven’t heard of it…)

The ability to search all filetypes at once (plus the ability to look for strings inside files) is what makes Spotlight so handy on OSX.

So perhaps Haiku could implement some sort of meta attribute system in which attributes can span multiple filetypes?

7

look at the skyos index feeder… I am interessting to write something like that for beos but in the moment I have al lack of time…

8

I was planning on making a post to explore this issue myself, looks like I don’t have to bother. :slight_smile:

From what I understand; without user intervention, embedded metadata will be ignored. This can be mp3s, jpgs pdfs, anything that has an embedded attributes convention. I somethimes think this is because of the era when BeOS was designed - the lone PC, “workstation”, where the artist/designer is the organiser and creator of all the data, and by extension, the metadata. However, in an era where media if flying around the place and the metadata is embedded into the files themselves, it seems tautologous to ask a user to enter data for a file(s) that already comes with the needed information. I’ve got 10,000 mp3s on a harddrive. Move them to BeOS and all that data is ignored, unless I use some third party addon. As they are stored on an external hard drive formatted with NTFS, the application of BeOS style attributes are moot. I don’t really want to copy music to different machines just so BeOS can show the files properly, when OSX, Linux, Windows can all read and handle the embedded data fine.

However, I think another real reason for this is the speed which the BeOS attributes offer over scanning the files individually. I personally believe that we should, by default, use the embedded metadata that media files often come with and not ask the user to apply it themselves. The issue lies in making this approach work fast enough with tracker and any other app that relies on attributes.

9
Malthus wrote:
AS for Be queries, I think they have a serious limitation in that each one has to be based on a particular mimetype, so you can create "keywords" as a custom attribute of jpegs, and also "keywords" as a custom attribute of some other filetype - mail, PDFs, Gobe documents, etc - but a Be Query can only act on one base filetype, thus defeating the purpose to some extent. (If there is a way around that, I haven't heard of it...)

I’m not 100% sure I understand fully what you mean, but I think you’re wrong. :slight_smile:
You can create a new index with mkindex -t string META:keywords and then add that in the FileTypes Preferences in the Extra Attributes section of all sorts of filetypes, e.g. JPEG, GIF, or MPEG, AVI, or HTML, TEXT.

Using that in queries is at the moment a bit awkward IMO, especially when using over different MIME types. You’ll have to string different Formulas together:
((META:keywords=="*[mM][oO][uU][nN][tT][aA][iI][nN][sS]")&&(BEOS:TYPE==“image/jpeg”)||(BEOS:TYPE==“image/gif”))
or something like that.

One thing that would be really handy, but doesn’t work at all in BeOS, is to include whole supertypes like BEOS:TYPE==“image/*” for all image types.

Let’s hope Haiku will offer a more complete solution and also one that’s easy to use. Stringing formulas together isn’t for the proverbial grandma…

10

i try to create an index BEOS:TYPE to do a querry over a mimetype like BEOS:TYPE==“image/*” But then crashes the tracker and the deskbar, so I delete the index. My idea is to reindex the BEOS:TYPE index with the bfs-tools. Is there a bigger reason why there is no default index? Why crash the tracker/deskbar when I create a BEOS:TYPE index? Because then the track can`t find the mime types any more(because the index is empty)?