Need a horizontal scrollbar for metadata

Hello, I really need a horizontal scrollbar to see more metadata of the files. Now the space is too limited to show more content. In fact, I want to show more metadata like filetype, author, etc. But finally I gave it up cuz it was too crowded. So I think a horizontal scrollbar would help a lot. I would appreciate it if you could consider my suggestion.

P.S. Please excuse any mistakes cuz I am not good at English.

1 Like

Welcome @betameta

Your suggestion is noted.

Do note you can see the tags for a selected file in the Tools > Info inspector or the View > Show Tags bar under the view/edit pane as well.

Thanks for your reply. I know the existence of Info inspector and tags bar. But the key point is a horizontal scrollbar needs no clicks and you can quickly browse and compare metadata of all the files at the same time.

I am curious why (and how) you have such long, concatenated tags.

These long and concatenated tags come from the file itself. All the files in the screenshot are academic journal articles and the PDFs include Keywords metadata. However, most of the time the Keywords are like this:

I have turned on Covert Keywords to Tags in the Preferences. Therefore, when these pdfs are indexed in DT, the Keywords become concatenated tags. It doesn’t matter, anyway. Because I will split the concatenated tags into independent ones including only one word, manually. I would appreciate it if you consider modifying the Covert Keywords to Tags feature and then DT could convert semicolon-separated Keywords metadata into separated tags.

Finally, I still need a horizontal scrollbar as I also want to display other metadata like the Year, Author, etc. I use DT as my reference management tool though my university provides Endnote for students. It is because DT is such a brilliant software!

Why not use a script for that?

1 Like

I haven’t tried Scripts before, but I am perfectly willing to learn how to use it. I’ll do some research on it. Thanks a lot!

Do that; but please be aware that changes made by scripts cannot be undone. I recommend testing your scripts on a limited set of test data.

Thanks for the nice feedback.

While I can’t make any promises, your suggestions have been noted. Cheers!

Currently, I do not have access to DT, so I can’t test. But something along these lines (JavaScript!) might work

(() => {
  const app = Application("DEVONthink 3");
  const records = app.selectedRecords();
  records.forEach(r => {
    const tags = r.tags()[0]; /* Assuming that tags is an array, and there's only _one_ tag! */
    r.tags = tags.split(';');

This works on the currently selected records. It takes the first tag, splits it at the semikolons and creates a new array of tags consisting of these split-up words.
Caveat: I do not know if tags is an array (or a list in AppleScript parlance). If it’s not, this code will not work. Also, if the record currently contains more than one tag, it will not do what you want. So be careful and test it on copies of your records first.


And on the subject - any chance you would reconsider and allow rendered HTML for custom metadata?

Yes, I know that means we can do things we would regret. But think of all the bad things that could happen from users writing their own scripts - yet how popular a feature that is.

I’d be glad to take the reponsibility for the risks of HTML custom metadata in return for what would be such clear benefits.

Even more amazing would be to allow Javascript to define the output of a custom metadata field based on access to the other regular and custom metadata fields for the item. That would let us write scripts to look up data, i.e. put a zip code in a metadata field and look up current weather in another field, put a PubMed PMID or a doi in a metadata field and have it display the direct URL to the item etc.

Care to elaborate? I don’t quite understand what it is you want to achieve here.

As to JS rendering another meta data field: While I see your point, I think that that way lies madness.

To put it differently: In order to do what you want (i.e. get a weather report or resolve a DOI), you’d need some way to execute a XHR from within DT (or a more modern fetch). Which in turn would only be possible if the window object were available within DT. Which it isn’t, because window is a browser global. So DT would somehow™ have to provide a window object with all its methods and properties (think history and addEventListener("DOMContentLoaded",...).
As much as the idea of a calculated meta data field seems to be appealing, I’m afraid I find it rather appaling after a I had a closer look at the implications.

Can you imagine the amount of traffic such a feature would generate here? There are already enough possibilities to shoot yourself in the foot with AppleScript and JavaScript in DT. Providing JS execution in meta data fields adds a very long rope to hang yourself to that…

1 Like

It’s already possible to execute a script to add or modify custom metadata.

any chance you would reconsider and allow rendered HTML for custom metadata?

What point would there be to have rendered HTML in custom metadata?
Custom metadata is for just that: metadata, like your name is a bit of metadata about you.

How is…

more beneficial than…
name: R. Kaplan


Color in particular can be very helpful to quickly interpret data

For example Green, Yellow, and Red Highlights for due dates

Or to extend the existing Labels feature - which is limited to one column with only a preset number of possible answers

Even better - you have a history doing graphic design so surely you can well appreciate the value of using CSS to alternate highlighting colors for even vs odd items - that can add immensely to the readability of columnar data

As to whether it is achievable, I will defer to you and others who are far more knowledgable in that regard than I do. Though I have a good bit of confidence that you could do it if you agreed it were desirable :slight_smile:

Yes DT3 is full of all sorts of automation tools - that is one of the best features by far for DT3. That said, there are infinite ways a JS-rendered metadata field could be useful to those organizing information. My examples of a a weather report or resolved DOI are just two simplistic ones - there are so many more possibilities I can think of and I am sure tons more even better that others here could think up - translated words, status of monitored equipment, reboot checkbox for a remote computer, smart investment dashboard which turns colors for various alerts, color change when a collaborative document has been edited by someone remotely - and a a billion other possibilities.

Getting back to the original poster’s thoughts, I think overall custom metadata is one of the best and rarest features found in DT3 but its potential has just barely been tapped so far.

What you’re describing sounds like the well-known German eierlegende Wollmilchsau. A pig, giving milk and wool and producing eggs, too.
In fact, Emacs comes very close to it: originally a text editor, it is programmable (in Lisp, which needs even more parenthesis then JavaScript). Nowadays you can view webpages with it, read your email, use it as a calculator etc etc.
However, it has not managed to replace tools dedicated to the tasks like browsers, email apps and calculators.

1 Like

It seems you are referring to using custom metadata columns in the item list, not the Custom info inspector.
That would likely require fundamental under-the-hood changes to the interface.


OK I guess I am in the minority. I love Rube Goldberg toys too :slight_smile:

Too bad there isn’t a modern GUI version of Emacs - I would be a huge fan!

And I would imagine if I were a farmer then a Wollmilchsau would be quite a dream


I use custom metadata in both places - they are both useful.

Agreed Javascript would be a huge reach to implement.

But I don’t think HTML rendering would require a massive effort to implement. Or at least some basic subset such as font color, highlight color, and bold/italics text.