I’m extremely impressed at how active these groups are and how quickly people get back with answers. I wonder if I might ask another question?
I’ve now, thanks to help from this forum, got my 2,500 pdfs into DT Pro Office, most indexed, but those originally brought without text scanned using OCR and imported. I’m now organising the database.
Creating one group and putting files in is straightforward enough. What I normally do is create a smartgroup, then drag files from it into a new group as smart groups tend to bring too much stuff over and need pruning down to be relevant. Equally, DT Pro allows me to use AI to find additional relevant files that don’t come up the smart search, and that’s excellent.
The problem comes when I have files that belong to two groups. Now I gather the DT way around this is to use replicants. However, I find this pretty counter-intuitive to be honest and it requires me to be rather careful when allocating files to groups from smart groups as, when I drag files over to groups, any files that fit within two group classifications move from the first group I’ve created to the newest without warning me. So the PDFs, unless I notice that they’re already allocated to one group and I create a replicant, automatically go only the last group they’ve been allocated to.
I gather that DT will have flags in the next version, so will probably (I guess) behave in a similar way to Eaglefiler, who’s only advantage over DT is the ability to work seamlessly in dragging files into what might be called multiple flag groups without reallocating them away. Does anyone have a neat workaround for spawning replicants when adding them to multiple groups, or at least bringing up a dialogue box of warning automatically, until such a time as DT has flags?
Thank you - that’s great. Wouldn’t it be good to have this as a default option for those of us who like to file things in this way? Or am I the only one who likes things in lots of places at once…?
There are, in fact, already a considerable number of user-selectable option in Preferences.
But we have seen literally hundreds of requests for additional configuration choices. To honor a large number of such requests would make Preferences large and complex-- and perhaps bewildering to many users.
Once in a while, though, a new Preferences option does get added.
Indeed. At some point the Prefs will become so unwieldy that DT will need to implement an installation “wizard” that steps each new user through all the preference choices (with explanations and examples). We might even see a PHP-style settings script that users can run and select and save.
The lesson is that with a complex application like DTPO, a concomitantly detailed set of user-selectable options are provided almost to the point of overload.
Perhaps each Prefs tab could have the basic options displayed with an “advanced” sub-tab available.
Or D-Tech could, for two or three bigs, send Bill DeVille to personally set up your preferences.
What I guess I don’t understand is why you would want to drag an item to a folder and want to automatically remove it from whichever other folder it happens to be presently located in. What I don’t understand is why you’d only want items to be in one folder at a time - that doesn’t make sense to me. So I appreciate that I may appear to be asking for yet another option to the program, but that only really applies if the way things are presently being done makes more sense that the alternative that I’m proposing. Can anyone explain why you’d only want data to be in one folder at a time - perhaps I need to rethink my practice?
Ian, there are scenarios in which it is highly desirable to remove a file from the source as it is moved to a target location.
For example, the Global Inbox should be viewed as a temporary staging place for new content. Periodically, one transfers content from the Global Inbox to a working database.
Another scenario would be moving data between databases. For example, I might wish to split an existing database by moving some of its content to a separate database.
In both examples the procedure is not complete until the transferred items have also been removed from the source. Currently (as of public beta 5) there is no ‘Move To’ procedure that can do that; content is copied to the desired location, then must be manually deleted from the source.
Thanks. I can see that. But for everyday organisation of files, it seems to me that, for the example of pdfs, I want to be able to go into my pdf smart folder and drag things to whatever folders I want things to be subsequently present in. For most people, files are going to be in more than one folder - the world isn’t a neat place, and most things will have multiple classifications surely? This is certainly how most replacement file manager systems (Eaglefiler, for example), behave.
A smart group is by intent and definition a different kind of beast than is a group. The documents are not ‘located’ in smart groups, but elsewhere in the your organizational structure.
Within a database, if you select a document in the database Inbox, the database top level or a database group and use the ‘Move To’ command, the document will be relocated from the source and moved to the chosen group destination.
But the only way to remove the representation of a document from a smart group is to delete it from the database, or use the Smart Group Editor to modify the smart group filter criteria.
As a practical matter, when one drags content from the Global Inbox into a working database, the user probably has no further need to maintain that content in the Global Inbox, and would like to remove it.
This is a different issue from your observation that in many cases a document should exist in more than one group or database to suit the user’s needs and to reflect the way the information is organized. That is valid, and I often replicate material into more than one group.
I strongly disagree, if you mean saving copies of the same file in different folders (aside from backup purposes). Most people I know move files to/between different folders.
They might, although saving duplicate copies in multiple locations is a poor way to assign different classifications. The main problem is simple: If you modify a copied file you also have to locate and modify all the other copies to keep them synchronized. Keeping track of all the copies quickly becomes a logistical nightmare in file management.
Consider, instead, having only a single version of the file that appears in multiple locations. DEVONthink replicants (and Smart Groups, as Bill described) can serve that purpose. Or, think about how a single track in an iTunes Library can appear in multiple playlists.
Thanks - that what I meant. I wasn’t suggesting that it is necessary to create a new copy every time you place the file in a new folder - simply that the file appear in more than one folder simultaneously. A change to one would be a change to all. That kind of takes me to my point - an electronic filing system has an advantage over a manual one because of its ability to do this. So I’m wondering why it isn’t he default option to put a copy (or replicant) of a file into the folder it is being dragged to, rather than taking it out of the old folder and putting it in the new one. That is what Eaglefiler does. And I’m wondering why it wouldn’t be the default option.
Let’s agree that a copy means a distinct duplicate item, as most commonly defined/understood? It’s different than a replicant (to use DT terminology) so interchanging the two confuses the discussion.
A search for “implied replication” will find a few of my posts similar to what I think you’re suggesting. There’s been quite a bit of discussion in those and other threads related to this topic.
