It’s great that spotlight can find documents in the DTP2 databases, but it would be even better if spotlight could recognize the actual file format (i.e. kind:pdf). Also would it be possible to get the Quicklook and file icon to display properly in the finder? When I perform a spotlight search, it is difficult to see what the results are if they are in DTP2. I don’t necessarily want to open DTP2 to see if the search result is what I want. Thanks.
The “Kind” is available and searchable: just use the Inspector panel in the Finder and when you browse through our items you can see this info in the “More Info” part. You can also use it in Spotlight search queries to specify the type of documents.
As to the icons that is currently not possible due to limitations with Spotlight.
My Scans with OCR show up in the Finder as “kind:Devonthink Pro Document”, not PDF. When I get info on the file in DTP2 it says the kind if PDF+text. So spotlight is not seeing the document attribute that DTP2 is seeing.
How about the Quicklook view from the Finder? I’m just starting to use DTP again since the PB was released.
But that is exactly what I was saying. The Finder Search window is a different and very limited animal. The document you see there is a “Devonthink Pro Document”, it’s a small document that represents the metadata necessary to make Spotlight work with our databases. It is not the document it is referring to in our database! But in the Info/Inspector you can see what the “DEVON Kind” is.
Regarding QuickLook: again it is not feasible at this moment to do this. We have some ideas but currently there are more important fish to fry. We will look at this in 2.x where x > 1.
Thanks Bill.
Fair enough. I’m not sure the quicklook ability needs to be incorporated into the app. Could it be a Spotlight plugin like there are for MS Office docs and iWork docs? Not sure, but at least you would not have to touch the application code.
Also, I’m not clear on what you mean by “inspector panel” in the finder. Do you mean the info panel? I can not see any info through the finder that indicates the internal file type for a DTP2 document. When you do a spotlight search, the panel view disabled in the finder. At least it is for me.
Thanks again.
Oops. Sorry, I was also reading a response from Bill on another issue. Thanks Annard
Oh, I just remembered (sorry my brain was offline for two weeks): we decided to remove the display of the kind of document in the Finder Info panel but it had been visible in a development release. 
But in any case: we have too much information available for the Finder to display it. If you’re interested in a (somewhat technical) lament about using the Finder to display Spotlight results in Leopard I refer you to “Why Apple’s Finder Search Window Is Feature In Leopard Gone Wrong.”
Very interesting. Thanks for the link. I’m always interested in the nuts and bolts talk as well as the war stories with Apple services.
I am struggling a bit with how to use DTP2 now though. It seems like it is evolving into a Finder replacement (which the world desperately needs). Is that the idea? If that is the case, then why have your own DB? could you use your AI with the Finder instead? I guess that would be like just using linked files with DTP2.
Good post, Annard. Yet another grain of sand on the beach of reasons that I use DEVONthink.
Spotlight and Quicklook are great, but their current functionality seems to me to be little more than that of eyecandy. It’s great until you really need to savagely penetrate some data, and then you realize how limited the current filebrowsing mindset really is.
As sgmiller has rightly pointed out on multiple occasions, this current system we have is ridiculous. I understand the performance penalties of a database filesystem… but really, that’s what our home folders need to be right now. The current paradigm just no longer makes any sense.
I think the Finder should look a heck of a lot more like DEVONthink.
Have you seen Path Finder 5? The world has more Finder replacement than it could possibly handle 
I see DEVONthink as a first-rate (currently!) information manager that ideally would have the ability to integrate some Finder functionality (transparent windows on specified filesystem hierarchies, sort of like what you suggest) and piggyback on some of its code (Quicklook) while improving its capacity for dealing with raw information.
I don’t see it so much as a Finder replacement but as a file cabinet metaphor replacement. But then, I’m really a big fan of databases.
Actually Pathfinder 5 is my current finder. While it’s 10X better than Apple’s Finder, it’s still not all that intuitive. Now, if it had the DTP A.I. in it, then that would just about do it for me. Smart filing and quick & accurate file searching.
What I do like about Pathfinder is the built in terminal, shelf and the ability to see and edit Spotlight comments on the main view. Oh yeah, AND TABS!!!
Interesting discussions.
What I like about DEVONthink is that it pulls together into a working environment information content, tools to help me explore that content and simple but effective draft writing tools.
In that sense the user interface is far more cohesive and consistent than could be provided by any of the operating systems/applications in common use today. I know, for example, that whether I’m viewing a text, HTML, WebArchive, PDF or image, the same commands will result in zooming the view in or out. I can view any of those filetypes in the same pane of a view window, rather than jumping about among different applications. By contrast, under the parent applications that I use for those filetypes, I would have to remember four different command sets to zoom in and out – and all those programs were created by Apple! Don’t believe me? Check out what you have to do to increase/decrease viewing size in Safari, Preview, TextEdit, Pages and Aperture. And in some cases, to see larger text one actually changes the font size, which I prefer not to do.
DEVONthink 2 uses Quick Look to extend the number of document filetypes that can be displayed within a database. That’s great. But Quick Look (as well as the plugins supplied by some developers) is still in its infancy, and I want to see improvements. For one irritating thing, I can’t zoom a Quick Look display.
One poster asked, why a database? Why not an operating system with great search capabilities and built-in artificial intelligence features, that can work with all the contents of a drive (or multiple drives)?
But my own experience is that I can add value to my information content by segregating information into different databases. I’ve often talked about the improvements I gained by separating my main database on environmental science, policy and regulatory issues from another large set of content that deals with technical matters such as chemical analytical procedures, sampling and quality assurance protocols and data evaluation methodologies. Because those two databases use so many terms in common, the focus of searches and See Also operations for most inquiries in either database is greatly improved when they are segregated. Once in a while I may want to search across both; DEVONthink Pro 2 lets me do that.
In fact, I’m leaning more and more in the direction of creating more and smaller databases, for the reasons mentioned above. Disaggregation of information, with DT Pro 2, also allows me to aggregate chosen “blocks” of information for any purpose, rather like building something from a set of Leggo blocks.
Increasingly, I’m finding advantages in discrete databases rather than a single collection of files, as would be implied by the “smart operating system” approach. I can now very quickly spin off a new database that’s populated with search results from one or more of my existing databases, perhaps creating that new database only for a temporary purpose.
And all of my databases share a common interface and set of tools. Yes, there are user suggestions about UI issues such as changes of focus within view windows. Perhaps there are some UI warts. But think of the UI inconsistencies that would be experienced if one were constantly switching about among five or so different applications to manage and view the content for a project! That, of course, is the result if one depends on Spotlight.
As I never get tired of pointing out, one only needs to “segregate” information because of the outdated file system metaphor. I won’t bore everybody by repeating the explanation but if one was able to group the relevant info within the OS itself and not have to move/replicate/duplicate it , voila…instant segregation.
Maybe. 
In my example of segregating two databases to improve their utility, although both dealt with environmental matters, I had to be very familiar with the topics, content, and sources of the literature. And it took experimentation and experience to decide the appropriate database destinations of my “stuff” that worked best. Instant segregation? No.
Do the important distinctions that I made have much, if anything, to do with a file system metaphor? I’m not convinced of that. Primarily, when I was performing searches or See Also operations, I wanted to reduce the number of “outlier” results that were not relevant to my immediate interest, but took time to examine and discard.
That doesn’t mean, though, that those two databases are not rich and varied in content. I’ve previously mentioned a See Also result when I was viewing a paper about the effects of invasive species on the population dynamics of an ecosystem. The most interesting See Also suggestion pointed to similarity with a paper dealing with stoichastic chemistry, including analysis of factors that change reaction equilibria. That’s real, and, I think, insightful when it’s understood.
I’ve even got an article in my main database, which deals with environmental science, regulatory and policy issues, an article about mattresses in Victorian England. Sound strange? Yes, but if you were to read that article, it belongs in that database. It adds historical, social and economic perspectives about the ways we create, identify and respond to environmental problems.
What I meant was that with a proper OS file metaphor, you wouldn’t need a separate database to keep information segregated.
I’m not so sure about that. Part of what makes the DTP AI so powerful is its ability to find stuff “like this.” The user has a lot of ways to explain what “this” is: by creating groups within a database, by choosing what to put in the database in the first place, and by adding metadata. Similarly, general purpose web search engines work, in part, by collecting the web’s collective wisdom about what things belong together (as shown by links).
And then you have desktop searches like Spotlight, or like Google’s desktop search. In my experience, these generally don’t work as well as either DTP or web search, and I think the reason is the lack of user input. They just don’t have the information they need to make fuzzy contextual distinctions.
Now, theoretically, I guess there’s no reason why DTP’s algorithm couldn’t be grafted onto a file system. But given how few programs do anything like what DTP does, and given how closely the search engine companies guard their algorithms, I’m guessing the algorithm represents a very hairy, very proprietary piece of technological wizardry. Nor am I sure that you (the OS vendor) would even want to, given the amount of user re-education that would be required to get decent results. For a value-added product like DTP, sure, but for an OS I see it creating a programming and support nightmare without really being seen as a plus by the majority of users.
Katherine
Maybe I wasn’t clear. I wasn’t suggesting that the OS do everything only that if it was properly dealing with files, then it would provide hooks for others to come along with solutions such as AI, etc.
Failing that, I am arguing that DT adopt a proper file structure for all the reasons I have outline. Until it does, its just boxing itself in with the old "file cabinet metaphor.
Wow, this is a great discussion.
Even though this is the DT2 forum, I’d like to extend this discussion out to what feels like a continuing problem with 3rd party applications and Apple’s Finder. More and more I find applications using their own internal DB’s to store and reference files. Here’s just a quick list of apps lying around my Applications directory: Devonthink, Bento, Curio, Leap, Together, Evernote, Delicious Library and MailSteward.
I’m sure these all have valid reasons for having their own DB back end. The problem is that I don’t want to search each one individually to find the various bits of info I have (I have equally valid reasons for using each one of these). My opinion is that Apple promised a universal search and what seemed like should be universal Quicklook. That is far from where we are now. It only seems to get worse with every new shiny application.
Is there something fundamentally wrong with the file system that causes developers to use their own DB rather than the OS file system? I’m a budding mac developer, so I would definitely appreciate some insight into this. I also appreciate that each application will have it’s own set of problems with the OS.
Well, for one, pretty much all of the applications you mentioned rely upon databases. Database programming is not by any stretch of the word easy. OS X, with Core Data, made it significantly easier to create applications that store data with things like SQLite, boosting performance significantly and considerably reducing the programmer’s workload.
That’s pretty much it, from what I can tell.