Custom Replicant Titles

I’ve seen other threads where users request the ability to rename the title of a replicant instance. The response from DT support has always been that replicants are not copies; they are literally the same document attached to multiple parent nodes. Thus, the concept of changing the title of a replicant instance makes no sense, since that would change the title of all its instances. I get this, but there are ways around it. First, let me explain why this feature would be valuable.

As an example, I have a group called “SEO”, which contains all my documents and groups pertaining to SEO. I have another group called “Software”, which mostly contains bookmarks to websites of various software vendors. Finally, I have a group called “SEO Software”, which is a child of both the SEO group and the Software group. Within the SEO group, the title “SEO Software” is redundant and ugly. Since it’s contained within the SEO group, I know it’s related to SEO. Therefore, in this group, I’d like it to appear simply as “Software”. Likewise, in the Software group, the title is also redundant and ugly. I know it’s about software, since it’s in the software group. Therefore, in this group, I’d like it to appear simply as “SEO”. There are hundreds of examples in my database, where I’m forced to use redundant titles for replicants, instead of titles that make sense within the context of each group.

Again, I understand that replicant instances are all identical. However, that doesn’t mean they must all be displayed identically…

In the Info Inspector, there’s a dropdown called “Instances”, which displays the locations of all the instances of the document. This selector could be moved into a separate tab within the Info Inspector called Instances. Within that tab, instead of displaying a dropdown, there could be a two-column table. The left column would display the instance location and the right column would display the title of the instance at that location. If left blank, the instance would display the default title, as specified in the Name field. However, this would allow the user to manually enter a custom title for each instance. Thus, all replicant instances would contain the titles of all instances. For each instance, DT would display either the default title, or the custom title for that instance.

I can already anticipate one objection being that this would create more clutter within the Inspector pane. I disagree. Currently, there are three tabs within the Info Inspector: Generic, Custom, Properties. There’s plenty of room to add a fourth tab, Instances, and going from three tabs to four tabs would hardly make any visual difference at all. Considering that replication is one of DT’s signature features, I think it would be wholly appropriate for the Info Inspector to contain a dedicated Instances tab.

Another objection might be that this could add overhead, since DT would have to perform additional processing, rather than just displaying the default title. Again, I disagree. The additional overhead required to check if a custom title exists for the instance could probably be measured in nanoseconds. It’s insignificant, even across thousands of nodes, and well-worth it for the additional power and flexibility afforded by this feature. Nevertheless, if some users are concerned about overhead, there could be an option to disable the feature entirely. In that case, the Instances tab would be dimmed and DT would always use the default title without doing any further checking.

Within the SEO group, the title “SEO Software” is redundant and ugly.

You are describing merely cosmetic effects, not something that affects the performance or function of the database.

Have you considered using tags instead of replicants?

Of course, in a software application, form should follow function, but that doesn’t mean we should disregard form entirely. Clearly, form is important to the DT development team, because you often deny feature requests on the basis that they will cause more clutter. For me, having to look at hundreds of redundant titles in my database creates a sense of clutter. Also, clutter in the document tree is much more detrimental than clutter in the settings, because you work in the document tree all day long.

I do use tags for some things, but mostly I prefer to use replicants, because that’s just how my brain works. I like the idea of being able to drill down via multiple paths to find a document. I know that in DT tags are virtually the same as replicants, but for me, tagging adds another layer of complexity and requires more mental effort.

Replicants are already irritating enough for many users (as can be seen by the numerous posts asking “how to delete the original”. Giving them different names will add to this confusion. And adding a title property that will be empty in most cases simply because of a cosmetic effect seems a bit over the top.

And yes, @BLUEFROG is right (of course): tags might be the way to go here. Or a sensible name for the group.

If identical things appear different, how do you know that they are identical? Doesn’t identity mean (among other things) to look the same? In RL, I’d find it deeply irritating if an apple, which is identical with itself, were called “pear” by someone…

2 Likes

Context matters. That’s why we have hierarchies. Within the context of one hierarchy, one title may be appropriate. Within the context of another hierarchy, a different title may be appropriate. If you take the full path into account, each replicant already has a different name. I’m proposing to allow the user to display only the portion of the name that’s relevant within the context.

1 Like

Actually replicants do not have any properties at all, it’s absolutely the same instance (same document, properties, metadata etc.)

1 Like

Yes, I fully understand that. That’s why I mentioned that all custom titles would be contained within all replicant instances. The titles would be a property of the document itself, not a separate property of the instances, which would be impossible as you described.

1 Like

Groups, as in your example, do not even have a path.

Now I’m getting lost. If all “custom titles” were contained in “all replicant instances” … well, there is only one instance. So, this single instance contains all titles. And how do you decide which incantation (sorry, there isn’t even an incantation… how do we call this? a “pointer” perhaps?) of the identical thing displays what title?

Which seems to imply that there’s a “document” and “instances” and that these concepts are not one and the same thing. But what DT calls “instances” are merely identical views of the same document. Imagine you create an additional replicant of one that already has a “title” – would this new replicant get the same title? Or none, thus reverting to the name of the document? Why?

It all amounts to things that are identical while not being identical at the same time. Not possible.

What you want would be possible with objects in the file system: you could have a path and independent links to it, each with a different name but all pointing to the same object. But groups don’t exist in the file system.

Here’s a simple approach using tags and a local smart group…

Clearly a smart group functions as a group and can be named independently from any other group.

Groups have paths, though for whatever reason, DT doesn’t display them. But regardless, I was referring to document paths, not group paths.

Incorrect. You’re confusing instances with documents. There is one document, which can have multiple instances. The one document already contains a list of all its instances. That’s why when you view instances in the document properties, you can see all the instances, regardless of which instance you’re currently viewing. I’m proposing that alongside the path to each instance, we have the ability to specify a custom title. Thus, the one document, which already contains a list of all its instances, would for each instance, also contain a field where the user could enter a custom title. This list of custom titles would then be propagated to all instances.

When.viewing an instance, DT is aware of which instance you’re viewing. It would simply look up the title that corresponds to the instance.

That’s correct. They are NOT one and the same thing.

That’s correct. They are identical, but nothing prevents DT from displaying a different title for an identical object, depending on the context. I get that you’re not a developer, so we can debate the virtues of the feature, but there’s nothing technically difficult about this. It’s just a lookup table in the document object.

Thanks for that example. I did experiment with using Smart Groups, just as you described. However, I don’t think Smart Groups can display the entire group hierarchy starting from a given path. Please correct me if I’m wrong.

The Get Info inspector or popover displays the Instances of matches in smart groups…

No, what I mean is that you can’t navigate through the sub-folder hierarchy in a Smart Group like you would in a replicant group. For example, I could create a Smart Grouip that matches “Kind = Any Document”, but that would display a flat list of all documents in all subgroups. I could then add an OR clause to also include groups, but then I’d have both the flat list of documents and all the groups. I can’t think of how to create a Smart Group that would mimic the group hierarchy of a replicant.

In other words, start at a specified path, and display the files and groups in exactly the same structure as you would if you created a replicant of that path.

I tried “Kind = Any Document OR Kind = Any Group” and enabled the Exclude Subgroups checkbox, but it gave me a flat list of all groups through all levels of the hierarchy.

In that case, find <Database.dtBase2> -name 'groupName' should return a path. It doesn’t here. Does it on your machine?

Please stop. This is a silly debate, because obviously groups have paths. Otherwise, DT would have no way of knowing where to place a group in the hierarchy. Whether it displays the path to the user is a different matter altogether. It’s also silly because it’s irrelevant, since I was referring to document paths, not group paths.

To further clarify, the reason DT doesn’t display the path is that it only exists within the internal DT database, not in the file system. However, if you index the file system, rather than importing it, I’m pretty sure it would display the group paths, since those groups actually exist as folders in the file system. Either way, groups have paths within DT, though not necessarily outside of DT.

I can understand DevonTech just not wanting to support this feature, because they judge it to be niche and thus don’t think the userbase would justify the maintenance effort, or because they think it would end up causing more user confusion, increasing the support burden.

But the technical part of this discussion isn’t compelling to me (as a developer myself). Symlinks, hard links, and aliases in file systems do essentially what the OP is asking for. Presumably DT internally has some unique identifier for files and groups other than their name that acts sort of like a filesystem inode (which exists for both files and directories, the latter akin to groups). Linking multiple names to the same identifier doesn’t seem to me like a huge technical obstacle.

The caveat is the OP’s suggestion of making all names “a property of the document itself.” This would correspond to maintaining separate mappings, from a document to all its names, and from each name (location or path) to the document ID. Not hard to do, but it seems likely to be a maintenance headache. (In filesystems, typically the only way to get all names associated with an inode is to walk the whole filesystem.) But I didn’t get the sense that this was a crucial part of the request.

Every new feature does carry with it development, maintenance, and support costs that have to be justified. If DT has weighted this to their satisfaction already and judge that the utility doesn’t justify the development and support effort, I think that just needs to be stated. The partly technical aspects of this discussion do not seem to me to make a strong case that the request is technically challenging.